Swapping the DSP perform function at runtime?
I’m curious to know whether anyone has ever used dsp-add() from a
dsp_perform() function to change which dsp perform function is being
I’ve seen Supercollider plug-in code (the comb filters, I believe) that
does such a thing with a SETCALC() macro. There, one dsp perform
routine is used while the buffer is filling up the first time, and when
full, switches to another perform routine at the end of the dsp loop.
As a result, a different set of logic gets swapped out rather than
having overly complex (and slow) decision making in a single perform
I’m sure c74 will correct me if I’m wrong but I don’t think the method you describe would work like that in MSP. Though perhaps the new SDK … (ahem)
You could have several dsp perform functions that take the same number of args and a master dsp_perform() function – that is added using dsp_add() – which in turn calls one of these several dsp perform functions. You could do this without switch or if/else by storing a pointer to the perform function to be called in your object and just calling that in your master perform function (and returning the appropriate value of course). Of course in dsp_add() you’d need to set the default perform function but you could then change it at any time on a vector by vector basis, by changing the function pointer variable in your object.
I think this is pretty much what the SC SETCALC macro does:
#define SETCALC(func) (unit->mCalcFunc = (UnitCalcFunc)&func)
.. although there will be one additional function call using the method I describe above whereas I guess unit->mCalcFunc will be called directly.
..actually, I was curious so I tried it and it works. Not sure about efficiency but it probably is faster than a switch or if/else with many cases. Here’s an example that can be switched between multiply and add operations on two signals.
On Wed, 13 Aug 2008 08:33:13 +0100, Martin Robinson wrote:
> ..actually, I was curious so I tried it and it works. Not sure about
> efficiency but it probably is faster than a switch or if/else with
> many cases.
Hey cool! I’ll try it with my project, and let you know the results.
For me, it would do away with some of the complexity of the code in the
DSP loop, and make it easier to understand/manipulate the logic.