Hi,
I'd like to reflect actual dsp state in help patches. I know it is possible to send message 'dsp' via [s pd], however the result is only sent to Pd console, as 'dsp state 1' or 'dsp state 0'. State messages 'dsp 1 and 'dsp 0' are received from object [r pd], but only when dsp state is changed. Any way to get the status on demand in a patch, using Pd core objects?
Katja
On 11/01/15 21:39, katja wrote:
Any way to get the status on demand in a patch, using Pd core objects?
No built in object as far as I know (though there should be, given how often it is requested).
I can think of some ugly hacks, that have a slight delay (the time for at least one dsp block).
[bang~] doesn't output anything if dsp is off, so wait a few ms after loadbang to check if it did or did not output anything.
[sig~ 1]--[snapshot~] outputs 0 if dsp has never been turned on and computed a block, so wait a few ms after loadbang to check its value.
In either case, use [r pd]--[route dsp] in case the state changed before the result of the previous hacks arrived (and for updating later).
To be robust (eg user is running Pd at a low sample rate), maybe use [samplerate~] to work out how long you need to wait - probably relatively safe to assume block size 64?
Claude
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?
On Sun, Jan 11, 2015 at 11:39 PM, katja katjavetter@gmail.com wrote:
Hi,
I'd like to reflect actual dsp state in help patches. I know it is possible to send message 'dsp' via [s pd], however the result is only sent to Pd console, as 'dsp state 1' or 'dsp state 0'. State messages 'dsp 1 and 'dsp 0' are received from object [r pd], but only when dsp state is changed. Any way to get the status on demand in a patch, using Pd core objects?
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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)
fgmadsr IOhannes
On Mon, Jan 12, 2015 at 5:11 PM, IOhannes m zmölnig zmoelnig@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 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?
If the abstraction/patch is instantiated *after* DSP has been turned on then the [f ] object (within the respective abstraction) will not hold the correct value as it never received a change. I think this is case with respect to Katja's original problem when opening help patches.
On 12 January 2015 at 15:28, Alexandros Drymonitis adrcki@gmail.com wrote:
On Mon, Jan 12, 2015 at 5:11 PM, IOhannes m zmölnig zmoelnig@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?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, Jan 12, 2015 at 5:37 PM, Joe White white.joe4@gmail.com wrote:
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?
If the abstraction/patch is instantiated *after* DSP has been turned on then the [f ] object (within the respective abstraction) will not hold the correct value as it never received a change. I think this is case with respect to Katja's original problem when opening help patches.
Right, sorry. It was rather obvious I guess...
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@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
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@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@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@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/12/2015 04:47 PM, Roman Haefeli wrote:
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.
yes sorry, i was not very clear. joe (and you) already explained it: if you instantiate the [dspstate] abstraction after the dsp is turned on, it will have the wrong state (until you change the DSP-state again)
gfmdars IOhannes
-
Alexandros Drymonitis -
Claude Heiland-Allen -
IOhannes m zmölnig -
Joe White -
Jonathan Wilkes -
katja -
Roman Haefeli