Roman wrote:
correct me as well, if i am wrong, but there shouldn't be a need for rebuilding the dsp tree when loading a soundfile using [sndfiler], since it just copies data from disk/soundfile to memory/table. the dsp tree should stay the same. perhaps the same approach would work for [textile] and other harddisk accessing objects as well?
The problem is that when you compile the dsp you put a pointer directly to the buffer that is used by [table], but a [table] may change to a different buffer, and when it does, pd takes the easy way out and just recompiles the whole dsp.
I remember writing in private about this some months ago, but it wasn't fully understood, so I'll give more details this time. Here's what I wrote back then:
it's possible to hack around the need for recomputing the dsp chain, if you keep an index into the only entry of the dsp chain that would need to updated, and update that index each time that the dsp chain has to be updated anyway; then you can deref the main pointer of the dsp chain using that index, to change the pointer to the table. You can't store the pointer to your dsp chain entry because it is possible that it will be changed before the dsp chain has finished building, if dsp_add() calling realloc() causes realloc() to return a different pointer.
what I didn't say: this involves two hidden global variables in d_ugen.c that need to be communicated to the [sndfiler] objects so that they can patch the dsp-chain. Those two variables are:
static t_int *dsp_chain; static int dsp_chainsize;
you get the index from the latter, as dsp_chainsize's value is always the index used by the next value that is going to be added by dsp_add.
If there's anything else to say then I don't know what's not understood so people interested should ask me questions.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada