Re: [PD] Techniques for atomic/controlled variable updates
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 | | || out1out2out3 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
Re: [PD] Techniques for atomic/controlled variable updates
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 Barknechtf...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Techniques for atomic/controlled variable updates
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 | | || out1out2out3 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Techniques for atomic/controlled variable updates
--- On Tue, 6/16/09, Fred Smith fxsm...@gmail.com wrote: From: Fred Smith fxsm...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
