It depends. If DSP is on, you get a bang. If it's off, you won't.
So, If I am expecting a bang because I saved and DSP is off, it just bugs me that no bang is sent :)
If, say, you want to send one and only one bang to [switch~] so as to graph tables when DSP starts, then [r pd-dsp-started] is only useful if you spigot-out future bangs/saves/etc, otherwise you are graphing tables on every save...
It's a feature if you use it for randomness, say, to randomize seeds according to when dsp on/off switching or graph redrawing falls, say linked with a [timer] object :)
Perhaps [r pd-dsp-started] should only send bangs when dsp starts or stops, and not when the dsp graph is redrawn.
In any case, I think it's the misnomer what's confusing me. I realize that saving redraws the dsp graph, but I don't see why the dsp would "start" if it was already switched "on", even though I do understand that, for a tiny moment, the dsp needs to be off behind the scenes.
On Tue, Feb 18, 2020 at 5:30 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
On 2/18/20 10:21 PM, ffdd cchh wrote:
The bug/feature with [r pd-dsp-started] is that you'll get a bang every time you save the patch,
it's neither a bug nor a feature. the DSP-graph is re-built when the patch is saved, and so the "pd-dsp-started" is emitted.
so it's not very useful while patching
how so?
(a [metro] will also send bangs while patching, and yet it is useful in live-coding contexts.)
gmsdtr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list