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


--
fdch.github.io