Csound Csound-dev Csound-tekno Search About

Re: ksmps Was: Re: cmusic Was: Csound and other synthesis systems

Date1999-06-17 05:18
FromRobin Whittle
SubjectRe: ksmps Was: Re: cmusic Was: Csound and other synthesis systems
I agree with what Larry Troxler wrote about how important it is for
ksmps to be 1 in some applications - particularly those involving
audio feedback.  

Ideally a system would enable some parts to be executed with various
ksmps rates.  It is a tall order, and the sort of thing I am
contemplating for "Topsy" which is pure vapour-ware at present and
likely to remain so for several years at least.


Larger ksmps values certainly does speed calculations!  

In one elaborate Csound piece I did in 1996 (admittedly this was on a
100MHz AMD 486) ksmps=10 was 2.1 times faster than ksmps=3.  Life is
too short to try this at ksmps=1, since it took 36 hours to cook at my
final rendering quality of ksmps=3.  The piece had a mix of general
simple Csound ugens and extensive use of a very large ugen of my own.

For me, there are enough things which can be done with ksmps > 1 to
make it worth the trouble.  It is easy to dream of complexities of
sound creation and reverberation which would tie up any amount of
computing resources - so processing speed directly translates into the
final sonic sophistication of the music and/or the ability of the
composer to run it time and again whilst refining it.

For instance I figured out how many paths of sound reach the head in a
rectangular room, from a single source, allowing for direct, single
wall, two wall, etc. up to six wall reflections.  Not counting the
sound hitting the same wall twice (and therefore not counting real
reverberation), there were about 1956 paths - each which would ideally
be processed by a CPU intensive binaural algorithm.  

The physical world is a very rich place, and if we want to do anything
of similar finesse on a CPU, it is worth finding the fastest way of
doing it.

- Robin



===============================================================

Robin Whittle    rw@firstpr.com.au  http://www.firstpr.com.au
                 Heidelberg Heights, Melbourne, Australia 

First Principles Research and expression: Consulting and 
                 technical writing. Music. Internet music 
                 marketing. Telecommunications. Consumer 
                 advocacy in telecommunications, especially 
                 privacy. M-F relationships. Kinetic sculpture.
                  
Real World       Electronics and software for music including:
Interfaces       Devil Fish mods for the TB-303, Akai sampler 
                 memory and Csound synthesis software. 

===============================================================

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

Date1999-06-17 05:56
FromTimo Tossavainen
SubjectRe: ksmps Was: Re: cmusic Was: Csound and other synthesis systems
On Thu, 17 Jun 1999, Robin Whittle wrote:

> I agree with what Larry Troxler wrote about how important it is for
> ksmps to be 1 in some applications - particularly those involving
> audio feedback.  
> 
> Ideally a system would enable some parts to be executed with various
> ksmps rates.  It is a tall order, and the sort of thing I am
> contemplating for "Topsy" which is pure vapour-ware at present and
> likely to remain so for several years at least.

This not actually very hard to do. Just solve the strongly connected
components of the signal flow network and at same time you get the order
of the update from the first DFS. You can use any ksmps in UG which form a
component by themselves and ksmps = 1 in components that have more UGs. In
code you have to handle the connections between the components as special
cases (ie. fill output vectors from the outputs from the components and
feed single input samples to the inputs leading to the component).
Doing this while the user dynamically alters the connections isn't
that easy. Possible ? probably.

Wouldn't it be best to implement a compiler, that compiles the UG
network to a single monolithic piece of code and then gets rid of the
function calls and unnecessary memory accesses, that are making the synth
slower at kr = sr. In that there would still be some use for using vectors
of data to keep the most of the data needed in calculations (for example,
filter coefficients) in registers. For instance have it generate C and
turn it into something like a DLL and then use that. Of course it would be
a lot easier in Lisp, since you can generate and compile code in memory
and don't need to invoke the compiler in a shell.

Timo