--- On Tue, 6/16/09, Fred Smith fxsmith@gmail.com wrote:
From: Fred Smith fxsmith@gmail.com Subject: [PD] Techniques for atomic/controlled variable updates To: pd-list@iem.at Date: Tuesday, June 16, 2009, 1:21 AM Hello all -
I'm currently building a simple video project using PD and GEM that creates a video stream by combining a series of images in various ways based on a single input control signal. Simply put, the input signal is processed to produce indexes into arrays of images, and to provide some parameters for blending those images to produce the visual output.
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? I'm considering writing an external that would pass a set of values through, but only update the outputs when a specific mathematical condition is met (some consistency check on the input parameters) - but, it seems like there may already be techniques for doing this.....
It's hard to know without an example patch, but why not use
<pack f f f f> | | | | <unpack f f f f> after your "mathematical-what-have-you" abstraction? I'm assuming your abstraction follows the same right to left output standard of most Pd objects, but even if it doesn't you can still use <t b a> to trigger the hot inlet of pack.
-Jonathan
Any pointers would be appreciated.... Thanks! -fred
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list