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 <[email protected]> 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 > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > -- fdch.github.io
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
