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