Get rid of ksmps != 1? [WAS: Re: a-rate if]

[Michael Bechard]

I've often kind of wondered about the many issues that arise from the whole ksmps issue. What should it be, how does it affect the sound, etc. So many opcodes now seem to operate best (sometimes only) if ksmps = 1, so has any thought been given to making future versions of CSound always have ksmps = 1, thereby basically making it go away altogether? I understand it's there and configurable for performance reasons, but the (often minimal) performance gains seem overshadowed by the confusion the distinction often causes. If ksmps always equalled one, then there really would be no need to distinguish between k and a-rate variables at all. It would simplify things immensely.

Of course, I defer to the developers on this issue, and it would represent a fairly radical change. But it's at least an intriguing idea.

Michael Bechard



----- Original Message ----
From: John Lato <jlato@...>
To: csound@...
Sent: Monday, July 7, 2008 12:44:54 PM
Subject: [Csnd] Re: a-rate if

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
[phone]


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"



     


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Michael Gogins]

Thought has been given. However, in my experience Csound runs about 5 times faster with ksmps of 10 or more than with ksmps of 1. I wouldn't call that a minimal performance gain.

The basic cause of this performance difference appears to be mainly going into the innermost loop to compute ksmps samples and being able to keep all code and variables in local cache until the loop is done. If ksmps is 1, the inner loop exits immediately, and there is a cache hit to bring the outer loop code back into cache. This is of course an artifact of contemporary processor design, but it has been more or less like this for some time, and I don't expect it to change soon.

The same consideration applies to any DSP graph and for this reason, almost all software sound synthesis systems employ this distinction between control rate and audio rate. The only one I know of that does not is ChucK.

Regards,
Mike

-----Original Message-----

>From: Michael Bechard <gothmagog@...>
>Sent: Jul 7, 2008 3:07 PM
>To: csound@...
>Subject: [Csnd]  Get rid of ksmps != 1? [WAS: Re: a-rate if]
>
>I've often kind of wondered about the many issues that arise from the whole ksmps issue. What should it be, how does it affect the sound, etc. So many opcodes now seem to operate best (sometimes only) if ksmps = 1, so has any thought been given to making future versions of CSound always have ksmps = 1, thereby basically making it go away altogether? I understand it's there and configurable for performance reasons, but the (often minimal) performance gains seem overshadowed by the confusion the distinction often causes. If ksmps always equalled one, then there really would be no need to distinguish between k and a-rate variables at all. It would simplify things immensely.
>
>Of course, I defer to the developers on this issue, and it would represent a fairly radical change. But it's at least an intriguing idea.
>
>Michael Bechard
>
>
>
>----- Original Message ----
>From: John Lato <jlato@...>
>To: csound@...
>Sent: Monday, July 7, 2008 12:44:54 PM
>Subject: [Csnd] Re: a-rate if
>
>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
>[phone]
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@... with body "unsubscribe csound"
>
>
>
>      
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@... with body "unsubscribe csound"

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[David Akbari]

Most things where it is important to use ksmps = 1, for example doing
filter math using an equation are probably more efficiently done in
the UDO space using a local ksmps value than running the whole
orchestra at ksmps = 1. See the "setksmps" opcode for further
information ( http://www.csounds.com/manual/html/setksmps ) The manual
page is a nice supplemental read that branches off of what Michael was
saying about the performance loop, if you care to learn more about
what Csound is doing under the hood.

This is a good reminder to all of us, since local ksmps tends to be an
amazingly useful feature of the language. Multiple UDO's in the same
orchestra can be set to different ksmps values! Don't feel limited to
the global ksmps value, you just have to get creative.


-David


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Mark Van Peteghem-2]

I just tried the opposite, i.e. make ksmps higher in a UDO than in the
orchestra, but it seems that that is not possible, CSound gives an error
that says that an illegal value was used for setksmps. The manual
doesn't say explicitly that it is forbidden to make a local ksmps higher
than the one of the orchestra, but the explanation of how it works
actually implies it.

David Akbari schreef:

> Most things where it is important to use ksmps = 1, for example doing
> filter math using an equation are probably more efficiently done in
> the UDO space using a local ksmps value than running the whole
> orchestra at ksmps = 1. See the "setksmps" opcode for further
> information ( http://www.csounds.com/manual/html/setksmps ) The manual
> page is a nice supplemental read that branches off of what Michael was
> saying about the performance loop, if you care to learn more about
> what Csound is doing under the hood.
>
> This is a good reminder to all of us, since local ksmps tends to be an
> amazingly useful feature of the language. Multiple UDO's in the same
> orchestra can be set to different ksmps values! Don't feel limited to
> the global ksmps value, you just have to get creative.
>
>
> -David
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe csound"
>
>
>  

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



Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"