[PD] [GEM-dev] Timing and PD....
reduzierer at yahoo.de
Thu Oct 30 17:27:02 CET 2008
i just ran into a similar problem. for the logic of some video players
we used the end 'bang' of [pix_film] for triggering some other
filmplayer. as soon, as the movie should be started again, we first set
the frame number to 1 and then in zero logical time we started the
according [gemhead] to start film playing / rendering of the gemchain.
by doing this, [pix_film] sent the end bang, although we've set the
frame number to 1 before. it took me some time to figure out, that this
is probably related to what you're discussing here. after i added a
delay between setting frame no to 1 and starting [gemhead], it worked
well (no bogus end 'bang' from [pix_film]).
don't know how this could be solved in an meaningful and understandable
way. however, i think that having to use a [delay] is the worst
imaginable case. in this particular case, we found a clean solution by
setting the startframe number on filmend instead of filmstart.
a generic solution to achieve something like that within 'pseudo-zero'
logical time would be good, i think. by 'pseud-zero' logical time i
mean, that instead of waiting to the left bang of [t b b], one could
wait on the 'ready' bang from the [pix_[film|image|etc]] object.
On Thu, 2008-10-30 at 10:32 -0400, Hans-Christoph Steiner 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...
> 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
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
More information about the Pd-list