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! _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list