[PD] Techniques for atomic/controlled variable updates
fbar at footils.org
Tue Jun 16 08:41:22 CEST 2009
Fred Smith hat gesagt: // Fred Smith wrote:
> The problem I'm having is that the single input parameter is processed
> to generate 4 control parameters for GEM - 2 indexes into the image
> list, and 2 gain scale factors used when blending the images. The
> issueis that when a control values enters the system, the 4 output
> parameters are updated in an order dictated by the messaging
> architecture of puredata - and, as the 4 output parameters are
> updated, they are momentarily inconsistent with each other.
> <pd mathematical what-have-you>
> | | | |
> <out1> <out2> <out3> <out4>
> So, an input value enters the system, and the outputs are updated
> based on the depth first traversal of the patch - out1, then out2,
> then out3, then out4. Meanwhile, GEM is rendering the output to the
> screen. So, suppose out1 then out2 get updated, and GEM renders a
> screen shot. At that point in time, out1 and out2 correspond to the
> new input parameter, and out3 and out4 correspond to the previous
> input parameter, and the resulting display shows artifacts of this
> I've managed to resolve my specific project's issue by rewriting the
> control algorithm such that the inconsistencies minimize the visual
> artifacts, but the fundamental update order problem remains unsolved,
> and I'm curious if others have dealt with this type of issue.
> Can anyone point me to techniques for managing this type of problem?
Without any precautions, <out1> ... <out4> are independent from each other.
If <out1> ... <out4> have to activate at the same time, you have to pack them
into a single list. If you need a certain order, like <out3> firing before
<out4> you have to use [trigger] objects to enforce that order, possibly chained.
Ideally you should try to make your own in- and outlets follow a right-to-left
activation order like almost everything else in Pd.
More information about the Pd-list