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