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

[chris clepper]

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>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
> >> http://lists.puredata.info/listinfo/gem-dev
> >>
> >
> >
> > _______________________________________________
> > GEM-dev mailing list
> > 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
> http://lists.puredata.info/listinfo/gem-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20081030/424a724f/attachment.htm>