[PD] removing objects causes recomposing of the dsp graph

[Mathieu Bouchard]

> 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