Hello again list,

I really want to do something like this:

	if		a1>a2	then

	; some stuff

	endif

But if-statements don't work with a-rate variables.

I'm doing non-real-time stuff with ksmps=1, and I even tried changing 
all variables to k-rate and then using a(kout) at the end but ended up 
having all sorts of other difficulties, which I haven't got to the 
bottom of yet.

The only workaround I have so far is to copy the arate to krate using 
max_k (which is the only opcode I could find to do this) and then 
compare them, but I feel like I'm going round the houses a bit, so:

1. Is there a simpler / more elegant solution?

2. Is there another opcode which I've overlooked? Like the 'a' opcode, 
but in reverse; something which simply copies the a-rate variable to 
k-rate every ksmps, without averaging or finding the maximum.

3. Is there any reason why 'if' can't be made to accept a-rate variables 
in the (near!) future?

Yours gratefully,

Joe

Hi Andres,

OK that's good to know. I'll do my best to nail it down, I imagine it's 
a typo somewhere - I'll let you know if not. Right now it's making my 
head hurt so I'm going to bed.

Joe

Andres Cabrera wrote:
> Hi,
> If you are using ksmps=1 then k-rate variables are the same as a-rate 
> variables. If something is amiss, it's a bug. If you can nail it down, 
> please report it.
> 
> Cheers,
> Andrés
> 
> On Mon, Jul 7, 2008 at 9:12 AM, Joseph Sanger  > wrote:
> 
>     Hello again list,
> 
>     I really want to do something like this:
> 
>            if              a1>a2   then
> 
>            ; some stuff
> 
>            endif
> 
>     But if-statements don't work with a-rate variables.
> 
>     I'm doing non-real-time stuff with ksmps=1, and I even tried
>     changing all variables to k-rate and then using a(kout) at the end
>     but ended up having all sorts of other difficulties, which I haven't
>     got to the bottom of yet.
> 
>     The only workaround I have so far is to copy the arate to krate
>     using max_k (which is the only opcode I could find to do this) and
>     then compare them, but I feel like I'm going round the houses a bit, so:
> 
>     1. Is there a simpler / more elegant solution?
> 
>     2. Is there another opcode which I've overlooked? Like the 'a'
>     opcode, but in reverse; something which simply copies the a-rate
>     variable to k-rate every ksmps, without averaging or finding the
>     maximum.
> 
>     3. Is there any reason why 'if' can't be made to accept a-rate
>     variables in the (near!) future?
> 
>     Yours gratefully,
> 
>     Joe
> 
> 
>     Send bugs reports to this list.
>     To unsubscribe, send email sympa@lists.bath.ac.uk
>      with body "unsubscribe csound"
> 
> 

No, it's not that easy. When ksmps=1, opcodes that require either k-rate 
or a-rate for a certain argument, still don't accept the other. E.g.

    afil butterlp asig, afreq

doesn't work. You continuously need upsamp (or interp) and downsamp to 
switch between the two rates.

Andres Cabrera schreef:
> Hi,
> If you are using ksmps=1 then k-rate variables are the same as a-rate 
> variables. If something is amiss, it's a bug. If you can nail it down, 
> please report it.
>
> Cheers,
> Andrés
>
> On Mon, Jul 7, 2008 at 9:12 AM, Joseph Sanger 
> > wrote:
>
>     Hello again list,
>
>     I really want to do something like this:
>
>            if              a1>a2   then
>
>            ; some stuff
>
>            endif
>
>     But if-statements don't work with a-rate variables.
>
>     I'm doing non-real-time stuff with ksmps=1, and I even tried
>     changing all variables to k-rate and then using a(kout) at the end
>     but ended up having all sorts of other difficulties, which I
>     haven't got to the bottom of yet.
>
>     The only workaround I have so far is to copy the arate to krate
>     using max_k (which is the only opcode I could find to do this) and
>     then compare them, but I feel like I'm going round the houses a
>     bit, so:
>
>     1. Is there a simpler / more elegant solution?
>
>     2. Is there another opcode which I've overlooked? Like the 'a'
>     opcode, but in reverse; something which simply copies the a-rate
>     variable to k-rate every ksmps, without averaging or finding the
>     maximum.
>
>     3. Is there any reason why 'if' can't be made to accept a-rate
>     variables in the (near!) future?
>
>     Yours gratefully,
>
>     Joe
>
>
>     Send bugs reports to this list.
>     To unsubscribe, send email sympa@lists.bath.ac.uk
>      with body "unsubscribe csound"
>
>

-- 
  Mark
  _________________________________________
  When you get lemons, you make lemonade.
  When you get hardware, you make software.

Joseph Sanger wrote:

 > 2. Is there another opcode which I've overlooked? Like the 'a' opcode,
 > but in reverse; something which simply copies the a-rate variable to
 > k-rate every ksmps, without averaging or finding the maximum.

In general this isn't possible.  Since an a-rate variable is an array of data (with 
length ksmps), it's clear that to convert from a-rate to k-rate you need some sort of 
aggregating function (e.g. calculate the average or maximum).  In the special case of 
ksmps=1 aggregating is unnecessary, but both averaging and taking the maximum would 
return the same value then anyway, so it doesn't make any difference.

I agree this can seem inelegant to many csound users, but if you think of how the 
orchestra is interpreted by csound it should be clear.

 >
 > 3. Is there any reason why 'if' can't be made to accept a-rate variables
 > in the (near!) future?
 >

I can think of several.  Again, understanding that an a-rate variable is really an 
array should make it clear.  Csound operates at the k-rate.  'if' accepting a-rate 
variables only makes syntactic sense in the case of ksmps=1, all other values would 
mean creating separate execution paths within a single a-variable array.  I doubt 
that could be implemented in any fashion that doesn't defeat the purpose of the 
k-rate (which means that ksmps=1 is what you really want anyway).

Working at ksmps=1, I would use max_k as you are already.  Downsamp and interp are 
other options.

John W. Lato
Sarah and Ernest Butler School of Music
The University of Texas at Austin
1 University Station E3100
Austin, TX 78712-0435
(512) 232-2090

Thanks everyone for all of your replies, they've clarified matters 
considerably (and given me a more in-depth knowledge of csound's 
internals!). I'll check out downsamp and interp as well, to see if they 
seem more appropriate.

Thanks again,

Joe

John Lato wrote:
> 
> Joseph Sanger wrote:
> 
>  > 2. Is there another opcode which I've overlooked? Like the 'a' opcode,
>  > but in reverse; something which simply copies the a-rate variable to
>  > k-rate every ksmps, without averaging or finding the maximum.
> 
> In general this isn't possible.  Since an a-rate variable is an array of 
> data (with length ksmps), it's clear that to convert from a-rate to 
> k-rate you need some sort of aggregating function (e.g. calculate the 
> average or maximum).  In the special case of ksmps=1 aggregating is 
> unnecessary, but both averaging and taking the maximum would return the 
> same value then anyway, so it doesn't make any difference.
> 
> I agree this can seem inelegant to many csound users, but if you think 
> of how the orchestra is interpreted by csound it should be clear.
> 
>  >
>  > 3. Is there any reason why 'if' can't be made to accept a-rate variables
>  > in the (near!) future?
>  >
> 
> I can think of several.  Again, understanding that an a-rate variable is 
> really an array should make it clear.  Csound operates at the k-rate.  
> 'if' accepting a-rate variables only makes syntactic sense in the case 
> of ksmps=1, all other values would mean creating separate execution 
> paths within a single a-variable array.  I doubt that could be 
> implemented in any fashion that doesn't defeat the purpose of the k-rate 
> (which means that ksmps=1 is what you really want anyway).
> 
> Working at ksmps=1, I would use max_k as you are already.  Downsamp and 
> interp are other options.
> 
> John W. Lato
> Sarah and Ernest Butler School of Music
> The University of Texas at Austin
> 1 University Station E3100
> Austin, TX 78712-0435
> (512) 232-2090
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"
>