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 Barknecht 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. >> >> >> | >> | >> >> | | | | >> >> >> 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, ... are independent from each other. > If ... have to activate at the same time, you have to pack them > into a single list. If you need a certain order, like firing before > 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
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. > > > | > | > > | | || > > > 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, ... are independent from each other. If ... have to activate at the same time, you have to pack them into a single list. If you need a certain order, like firing before 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
--- On Tue, 6/16/09, Fred Smith wrote: > From: Fred Smith > 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. > > > | > | > > | | > | > | > > > > 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 | | | | 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 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
[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. | | | | || 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
