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 > >> [EMAIL PROTECTED] > >> http://lists.puredata.info/listinfo/gem-dev > >> > > > > > > _______________________________________________ > > GEM-dev mailing list > > [EMAIL PROTECTED] > > http://lists.puredata.info/listinfo/gem-dev > > > > ------------------------------------------------------------------------ > ---- > > ¡El pueblo unido jamás será vencido! > > > > _______________________________________________ > GEM-dev mailing list > [EMAIL PROTECTED] > http://lists.puredata.info/listinfo/gem-dev ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list