[PD] Techniques for atomic/controlled variable updates
fxsmith at gmail.com
Tue Jun 16 22:39:31 CEST 2009
Thanks to both Jonathan and Frank for your replies.
Took me a bit, but I now understand the pack list suggestion. I still
fear I may have issues once I unpack the list (as, it will resume the
right-left propagation of those values into the rendering piece of the
patch), but this gives me a better understanding of the tools to use
for ordering messages.
On Mon, Jun 15, 2009 at 11:41 PM, Frank Barknecht<fbar at footils.org> wrote:
> 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.
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list