[PD] [GEM-dev] Timing and PD....

[B. Bogart]

Hey all,

I'll try and work on some test patches, right now I'm trying hard to get
an installation ready, and these issues turned out to be a large
stumbling block.

I suppose I'm doing lots of processing that may be unusual, like:

Grab an image from video device
put the image in a buffer for each frame
send the image in the buffer to a second buffer on each bang from a metro.
pix_share the image in the second buffer
send a bang to tell second pd instance to pix_dump.
turn off the metro.
pix_dump (640x480 GRAY) to ann_som in a second thread
netreceive the winning BMU
use that BMU as the index in which the image has saved in a third buffer.
turn the metro back on.

I'm not thinking pix_share should do sync!! But I feel the need for some
infrastructure better than trigger for complex timing problems like
those I'm having.

I'm still debugging my patch, but adding a whole lot of arbitrary delays
(150ms) are being used to get PD to wait a little bit before accessing
the image in a buffer once it has been written.

Seems the safest way...

I remember Cyrille did mention needing to use these delays to make
things work. I had to use them in parts of pixelTANGO also (when a
message gets passed through many objects and many routes it takes time...)

As I have not noticed any render blocks with pix_buffer stuff, can I
assume it uses a thread like pix_image and so on? I think a "done" bang
would be really useful there.

I also had issues with things like pix_histo, where I would try and save
the hist, but the hist had not changed for the new pix_buffer_read
frame, just because the delay was slower than t b b delay.

Are cyrille and I the only ones seeing these kinds of issues?

Thanks for the comments.
.b.

chris clepper wrote:
> Internally, objects like pix_image and pix_film set flags for whether an
> image is new or not.  This tells other objects to update.  Perhaps a
> generic object (pix_info ?) can output when that flag is set.
> 
> pix_share is a little different than image loading as it just dumps a
> new image into the gemlist each frame.  It is not designed to do sync
> between instances of pd, but rather to be an asynchronous way to
> distribute processing.  Making it sync would remove the performance gains.
> 
> 
> On Thu, Oct 30, 2008 at 9:32 AM, Hans-Christoph Steiner <hans at eds.org
> <mailto:hans at eds.org>> wrote:
> 
> 
>     I agree.  I think for any indeterminate operation, like anything in a
>     separate thread, there should be a bang when that operation is
>     complete.  That way you can guarantee that things are ready when you
>     run a process.  If you want to make sure that things will be there on
>     time, then these threaded/indeterminate operations should run well in
>     advance.  Using guesswork and delays is not a real solution...
> 
>     .hc
> 
>     On Oct 30, 2008, at 4:25 AM, cyrille henry wrote:
> 
>     > helo,
>     >
>     > i'm also having this kind of problem.
>     > specially when loading a picture in pix_image.
>     > i think the best would be the have a bang when things are ready...
>     >
>     > C
>     >
>     >
>     > B. Bogart a écrit :
>     >> Hey all,
>     >>
>     >> I'm having more and more problems with sync in PD. By sync I mean
>     >> that
>     >> parts of my patches have processing delays that mess up timing. In
>     >> general I've been using buffers and delays to keep things working.
>     >>
>     >> This approach is not very scalable.
>     >>
>     >> I find myself using the "timer" object all the time to see if
>     >> there is a
>     >> processing delay I have to worry about. That is in cases where
>     >> there is
>     >> a bang saying an operation is done.
>     >>
>     >> Two examples I'm working on now (in Gem):
>     >>
>     >> First there is a delay between sending a message and the
>     >> pix_buffer to
>     >> store, and then again for pix_buffer_read to read the pixels. The
>     >> delay
>     >> is long enough that trigger does not work, there needs to be a
>     >> delay to
>     >> make sure the image in the buffer is the right one. (sometimes as
>     >> much
>     >> as 200ms)
>     >>
>     >> A second example is that I'm using pix_share and and second PD
>     >> instance
>     >> to offload some CPU usage. Making sure the image sent to that PD
>     >> instance and the image received later in the chain is difficult.
>     >>
>     >> I'm not writing for specific advice, hence the generalities, but
>     >> wanted
>     >> to start a discussion on the issue.
>     >>
>     >> What is the long-term solution for PD to solve these issues?
>     >> Should all
>     >> objects that introduce a delay send a bang when they are complete?
>     >> (for
>     >> example pix_buffer? Of course an additional delay occurs when when
>     >> the
>     >> pix_buffer is written to memory and when it gets to the gfx card for
>     >> display.
>     >>
>     >> I'm banging my head over these issues a lot lately and wonder if
>     >> there
>     >> is a better approach.
>     >>
>     >> Back to attempting kludging a solution.
>     >> .b.
>     >>
>     >>
>     >> _______________________________________________
>     >> GEM-dev mailing list
>     >> GEM-dev at iem.at <mailto:GEM-dev at iem.at>
>     >> http://lists.puredata.info/listinfo/gem-dev
>     >>
>     >
>     >
>     > _______________________________________________
>     > GEM-dev mailing list
>     > GEM-dev at iem.at <mailto:GEM-dev at iem.at>
>     > http://lists.puredata.info/listinfo/gem-dev
> 
> 
> 
>     ------------------------------------------------------------------------
>     ----
> 
>                       ¡El pueblo unido jamás será vencido!
> 
> 
> 
>     _______________________________________________
>     GEM-dev mailing list
>     GEM-dev at iem.at <mailto:GEM-dev at iem.at>
>     http://lists.puredata.info/listinfo/gem-dev
> 
>