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

[Roman Haefeli]

hello all

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.

roman

  

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...
> 
> .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


		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de