On Sun, 17 Jul 2005, ClaudiusMaximus wrote:
The only problem is that I have to set the audio buffer size very high (370ms) to avoid clicks when each frame is generated. I don't know if using [any] and [delay] to stagger the computation through time would work - ie, not crash ;) - I guess I'll have to try it.
It will crash because, in GridFlow, a grid message expires just after the sending of the message returns. At the moment it expires, the transmission starts. The transmission ends before the sender of the grid message returns. Whenever a t_clock is triggered (by [delay] or [metro] or whatever), it's waaaay too late.
The streaming in GridFlow was not designed to allow smaller latencies. It was designed only to make it easy for a chain of objects to develop some kind of cache affinity. That was in the original design (April 2001 or so). Maybe it could change in the near future, but then, it wouldn't magically solve everything.
Individual object classes may be guilty of further problems. E.g. all image decoders supported by [#in] will decode all of the frame at once and all of that in the main thread too (GF doesn't use threads).
,-o--------o--------o--------o-. ,---. irc.freenode.net #dataflow | | The Diagram is the Program tm| | ,-o-------------o--------------o-. `-o------------o-------------o-' | | Mathieu Bouchard (Montréal QC) | | téléphone:+1.514.383.3801`---' `-o-- http://artengine.ca/matju -'