[PD] Techniques for atomic/controlled variable updates

[Fred Smith]

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.

Thanks again,
-fred


On Mon, Jun 15, 2009 at 11:41 PM, Frank Barknecht<fbar at footils.org> wrote:
> Hallo,
> 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.
>>
>> <input_value>
>> |
>> |
>> <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
>> inconsistency.
>>
>> 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.
>
> Ciao
> --
> Frank
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>