[PD] Techniques for atomic/controlled variable updates

Jonathan Wilkes jancsika at yahoo.com
Tue Jun 16 04:26:38 CEST 2009




--- On Tue, 6/16/09, Fred Smith <fxsmith at gmail.com> wrote:

> From: Fred Smith <fxsmith at gmail.com>
> Subject: [PD] Techniques for atomic/controlled variable updates
> To: pd-list at 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 at iem.at
> mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 


      




More information about the Pd-list mailing list