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

IOhannes m zmoelnig zmoelnig at iem.at
Fri Oct 31 12:40:00 CET 2008


hi

B. Bogart wrote:
> 
> 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.

i agree to hans that this is the worst imaginable way to solve the
problem (in theory)

> 
> 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 said before: it takes 0 logical time! (it takes real time of course)

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

iirc, my goal was rather to be in sync with the gemchain.
so if you send an "open" message to [pix_image] you should be
guaranteed, that in the next render cycle the image is loaded.
the object might block this render cycle untill it has finished loading
the image.
i think this is better than adding another outlet.

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

afair, neither [pix_buffer*] nor [pix_histo] do _any_ threading.
(threading is used very sparingly and only when system i/o is involved)

> 
> Are cyrille and I the only ones seeing these kinds of issues?
> 
probably not.
i just find it hard to believe without any proof :-)

fgmrad
IOhannes




More information about the GEM-dev mailing list