[PD] query dsp state

[katja]

Hi, thanks for all your responses. Indeed the issue was how to reflect
dsp state right away when a patch is loaded. I want a thing like
[output~] for help patches which are supposed to work with all Pd
flavors vanilla, extended and L2Ork. Claude's trick with [sig~ 1] and
a delayed [snapshot~] seems to do a good job, see attached. Thank you
Claude.

Katja

On Mon, Jan 12, 2015 at 6:26 PM, Jonathan Wilkes via Pd-list
<pd-list at lists.iem.at> wrote:
> 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
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vanilla-output~.pd
Type: text/x-puredata
Size: 2334 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150112/22561c58/attachment.bin>