> There seems to be a (linear?) relationship between the number of
> objects(connections?) in a patch and the time it takes for the dsp graph
> to be redrawn. At least I think the drop outs are related to the dsp
> graph redrawing because of the following observation:
This is because Pd doesn't wait for the next DSP tick to recompile... It
doesn't even wait for the end of the current logical instant (imagine
[delay 0]). Therefore it has to redo the job for each deletion. Also,
nothing is done in the form of a diff, so, Pd has to recompile the whole
graph each time, nothing like incremental compilation. This can often lead
to O(n^2) running-times.
> Is there a way to 'manually' control the redrawing of the dsp graph and
> also to suppress it, when not necessary?
you are already doing it, using «dsp 0» and «dsp 1» messages. just make
sure you are not turning on a dsp that was already off before you deleted.
You do that by using [r pd] with [route dsp] and storing that value in a
[f].
then canvasdelete.c could also be making a clock_delay(self,0) to resume
the dsp a bit later, but I wonder whether that's actually tricky to do. I
can say, at least, that it's dangerous to make this delay any longer than
0, because the dsp could be using objects that don't exist anymore.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801