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
On Thu, 2010-04-08 at 20:13 -0400, Mathieu Bouchard wrote:
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
Yeah, suppressing works as long as DSP is turned off. However, when I turn it on again after having deleted some objects, the dsp graph will be redrawn. Is there a way suppress that last single redraw as well? I don't get why it does redraw always on deletion but only sometimes on creation.
Roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Fri, 9 Apr 2010, Roman Haefeli wrote:
Yeah, suppressing works as long as DSP is turned off. However, when I turn it on again after having deleted some objects, the dsp graph will be redrawn. Is there a way suppress that last single redraw as well? I don't get why it does redraw always on deletion but only sometimes on creation.
Well, the graph ought to be recompiled always on deletion like it ought to be recompiled always on creation. However, for creation, if you skip recompilation, all you get is that the new objects have dsp off while the old objects have dsp on. Whereas for deletion, if you skip recompilation, then there are deleted objects that have dsp on, and that causes a crash because pd tries to use a dead object.
To get out of this, you'd need a dsp compiler that could setup the output of the compilation so that it becomes modifiable at runtime, or so that it is broken down into pieces that are not too big, in both cases to make recompilation take less time.
In any case, if anything like that takes as much as 100 ms, perhaps there are some dsp-methods involved that do too much stuff during the compilation phase.
How many dsp-objects do you have at once, in your patch ?
Then, I also know of a problem in the dsp_add command, that causes it to display O(n^2) behaviour sometimes, but only sometimes. It's really abusing resizebytes() (that is, realloc()).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Mathieu Bouchard -
Roman Haefeli