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 Barknechtfbar@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list