IOhannes m zmoelnig a écrit :
cyrille henry wrote:
IOhannes m zmoelnig a écrit : ...
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 think nothing should block the render cycle.
currently, loading images is done on an other thread, but there is still a small time where rendering is stop. this mean that i need to load all media before the beginning of a performance.
i'm not sure. i think i agree with miller that everything should be strictly deterministic (the problem ben is describing is a problem because some things are non-deterministic).
yes, i do strongly agree with this. but some things can simply not be made in realtime. So it need to be done on an other thread. and a synchronization mechanism must be provide (a bang when finished).
cyrille
obviously this does not solve your problem, but do not despair!
i think it should be handled outside of the render-chain, e.g. by using [pix_buffer] (which could have threaded - bang-terminated - loading as well)
mgfasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev