> Please correct me if I am wrong, but it is my understanding that both
> Music V and cmusic call the code for a unit-generator, and that code
> produces just one sample of audio output.  Csound's distinguishing
> characteristic is that it has a variable "ksmps" which tells the unit
> generator how many samples to calculate.  ksmps can be 1, but then
> Csound runs rather slowly, as would Music V and cmusic.  Generally
> ksmps is 5 to 25 or so - and so the overhead of running the central
> loops and calling unit generator functions is spread over the
> production of many more audio samples.
> 
> Csound therefore has "k" and "a" rate signals, with the orchestra file
> determining the ksmps rato between them.  This makes for some ugly
> complications trying to maintain and translate between two separate
> kinds of variable, but it makes Csound run ***lots*** faster.  This is
> particularly true in "draft" mode where you set ksmps rather high to
> test the composition out, albeit with lousy sound quality.  When the
> composition is complete, then set ksmps to 2 or 3 and leave the
> computer cooking overnight to produce the final rendering.
> 

Now this ksmps != asmps  issue is something that I've always wondered
about, as far as performance. My first question, would be how many orcs
and scores require ksmps == 1? Isn't it a lot?  The times I worked with
Csound, I often needed to set ksmps==1 to allow instruments that use
audio feedback to work properly. I don't mean cases where it just
wouldn't sound as good. I mean rather, any case where you use feeback,
in which case things won't work at all, unless you forget about multiple
ksmps per audio frame. Perhaps however, I am not enough Csound-aware to
know of all the work-arounds in certain situations to avoid having to
use ksamps==1. But it seems that *any* instruement in a composition that
uses audio feedback will require ksmps=1 to realize the entire
composition! (unless of course, Make or something similar is used,
togethre with audio mixer scripts, in which case Csound can be invoked
on a per-part basis, with the parts mixed together afterward)
 
I am actually quite surprised that use ksamps>1 results in "***lots***"
faster efficiency! Is this true for processors with tiny cache only
(this would make sense - run a tight, small loop in each ugen, which
will run entirely in cache) , or does it somehow also result in
improvements for situations where the entire audio chain can be cached? 

But to get to my point - assuming that there are indeed a lot of cases
where you need  ksmps==1, then doesn't this result in some serious
innefficiency for this common case? Don't all the audio ugens need to
use a loop to process all thee samples in one ksmps-size buffer? And for
the common case where ksmps==1, you would think that this would be
horribly slow compare to an implementation where the ugens would not
loop, but simply process one sample (or better yet, Csound would
generate C code to implement each instrument - ala CLM)

What am I missing here? Is it just accepted that Csound isn't exactly
built for speed, but is enticing to use because of its large opcode
seleection?


Larry


dupswapdrop: the music-dsp mailing list and website
http://shoko.calarts.edu/~glmrboy/musicdsp/music-dsp.html