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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
