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
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 y
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
wrote:
On Mon, 2015-01-12 at 17:28 +0200, Alexandros Drymonitis wrote:
> On Mon, Jan 12
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
> 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
>
On Mon, Jan 12, 2015 at 5:37 PM, Joe White 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
>
> 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 *a
On Mon, Jan 12, 2015 at 5:11 PM, IOhannes m zmölnig 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 wro
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] abstra
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 wrote:
> Hi,
>
> I'd like to reflect actual dsp state in help patches. I know it is
> possible to send message 'dsp' vi
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
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.
11 matches
Mail list logo
