Hey all, I'll try and work on some test patches, right now I'm trying hard to get an installation ready, and these issues turned out to be a large stumbling block.
I suppose I'm doing lots of processing that may be unusual, like: Grab an image from video device put the image in a buffer for each frame send the image in the buffer to a second buffer on each bang from a metro. pix_share the image in the second buffer send a bang to tell second pd instance to pix_dump. turn off the metro. pix_dump (640x480 GRAY) to ann_som in a second thread netreceive the winning BMU use that BMU as the index in which the image has saved in a third buffer. turn the metro back on. I'm not thinking pix_share should do sync!! But I feel the need for some infrastructure better than trigger for complex timing problems like those I'm having. I'm still debugging my patch, but adding a whole lot of arbitrary delays (150ms) are being used to get PD to wait a little bit before accessing the image in a buffer once it has been written. Seems the safest way... I remember Cyrille did mention needing to use these delays to make things work. I had to use them in parts of pixelTANGO also (when a message gets passed through many objects and many routes it takes time...) As I have not noticed any render blocks with pix_buffer stuff, can I assume it uses a thread like pix_image and so on? I think a "done" bang would be really useful there. I also had issues with things like pix_histo, where I would try and save the hist, but the hist had not changed for the new pix_buffer_read frame, just because the delay was slower than t b b delay. Are cyrille and I the only ones seeing these kinds of issues? Thanks for the comments. .b. chris clepper wrote: > 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 <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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] <mailto:[EMAIL PROTECTED]> > >> http://lists.puredata.info/listinfo/gem-dev > >> > > > > > > _______________________________________________ > > GEM-dev mailing list > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > http://lists.puredata.info/listinfo/gem-dev > > > > ------------------------------------------------------------------------ > ---- > > ¡El pueblo unido jamás será vencido! > > > > _______________________________________________ > GEM-dev mailing list > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > http://lists.puredata.info/listinfo/gem-dev > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
