[PD] query dsp state

[Jonathan Wilkes]

Also, in Pd-l2ork:
[dsp(|[canvasinfo]|[print]
There is probably also an external somewhere in Pd-extended that does the same thing.
-Jonathan 

     On Monday, January 12, 2015 10:48 AM, Roman Haefeli <reduzent at gmail.com> wrote:
   

 On Mon, 2015-01-12 at 17:28 +0200, Alexandros Drymonitis wrote:


> On Mon, Jan 12, 2015 at 5:11 PM, IOhannes m zmölnig <zmoelnig at iem.at>
> wrote:
>        On 01/12/2015 09:49 AM, Alexandros Drymonitis wrote:
>        > Why not store what [r pd] -> [route dsp] outputs to [f ]'s
>        right inlet, and
>        > bang the left inlet whenever you want to know the dsp state?
>        
>        maybe because it reports the wrong value if you:
>        - start Pd
>        - turn DSP on
>        - query your [dspstate] abstraction (that implements your
>        suggestion)
> I don't understand how this will report a wrong value. If you start Pd
> and turn the DSP on, then [f ] will hold 1, right? If you bang it, it
> will output 1, which is the DSP state. And if you turn the DSP off, it
> will hold 0. How is that wrong? 

I am not entirely clear about what IOhannes meant exactly.  But assume
you set the DSP to on and only then you load the patch containing your
[dspstate] abstraction, the query will return a wrong result. Also it is
not always feasible to guarantee a certain patch (the one holding
[dspstate]) is loaded during the whole Pd session. The problem remains
that your [dspstate] abstraction depends on the user once turning DSP on
or off in order to reliably know the DSP state. 

Claude already mentioned some workarounds to query the current state
without knowing it beforehand.

Roman
 


_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150112/2af0fee9/attachment.html>