Hi,
I am working on a control rate object which outputs a value, only when a variable local to each instance is modified by another thread.
Having not known how to achieve this, the object works fine, but only with a [metro] connected to it, polling for a variable change on each bang.
I've looked into [metro] and [netreceive] which also output values without an external factor (inlet wise), but I kind of got lost in the code.
Is there a simple way of achieving such an effect (i.e. by registering a callback), or does this require a reasonable understanding of the time scheduling mechanism inside Pd?
Any advise is appreciated.
Thank you.
PSPunch wrote:
Hi,
I am working on a control rate object which outputs a value, only when a variable local to each instance is modified by another thread.
Having not known how to achieve this, the object works fine, but only with a [metro] connected to it, polling for a variable change on each bang.
I've looked into [metro] and [netreceive] which also output values without an external factor (inlet wise), but I kind of got lost in the code.
Is there a simple way of achieving such an effect (i.e. by registering a callback), or does this require a reasonable understanding of the time scheduling mechanism inside Pd?
have a look at the "clock" functionality.
a clock is basically a scheduled callback. if you want it to happen repeatedly (like metro), you have to reschedule the clock within the callback.
apart from that: why don't you just use [metro]? thus nobody has to learn how to start/stop the polling and to set the polling interval; instead they can just use an object which they already know (and if not will find that they should already know :-))
fgmnasdr IOhannes
Hi IOhannes,
(2009/12/23 0:19), IOhannes zmölnig wrote:
have a look at the "clock" functionality.
Ok, so I figure I do need to dive in to code related to time management. Will do so.
apart from that: why don't you just use [metro]? thus nobody has to learn how to start/stop the polling and to set the polling interval; instead they can just use an object which they already know (and if not will find that they should already know :-))
You have a point. However, since I could not think of any other object where the user had to connect a metro specifically for polling, on the surface it seemed like a lame, not elegant design.
If an experienced user like yourself thinks it is a valid option, I may stick to what I have now..
Thank you for the ideas.
Hallo, PSPunch hat gesagt: // PSPunch wrote:
However, since I could not think of any other object where the user had to connect a metro specifically for polling, on the surface it seemed like a lame, not elegant design.
There are some examples for this approach in the msd and pmpd physical modelling objects. Here it makes sense as you can change the polling rate and you can sync to other schedules like the Gem bang instead of to a metro.
Ciao