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.....
Any pointers would be appreciated.... Thanks! -fred
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
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
-
Frank Barknecht -
Fred Smith