On Sunday 08 December 2002 11.58, Steve Harris wrote: > > I had been assuming a single event-queue per instance. Two > > questions: why would a plugin (assuming not multi-timbral for > > now) have more than one event-queue? Assuming we do support > > multi-timbral synths, is there an advantage to having events > > per-channel event-queues? Do you envision each Channel getting > > the ->run() method seperately, or does ->run() loop? If it is > > looping anyway, is there an advantage to multiple event-queues? > > If we support multi timbrality a the API level then there is no > point having multiple queues (I think), you can just have "timbre" > and "voice" values in the struct (wow, multi-timbral really makes > no sense does it ;)
Well, if you actually want to implement multicannel synths, all you get with a single event queue is: * bigger events (more fields in the struct), and * lots of queue splitting/filtering overhead. * You also force senders to keep track of which Channel to send events to, *as well* as which Event Port. Where's the advantage to make up for this? //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---------------------------> http://olofson.net/audiality -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture | `----------------------------> http://www.linuxdj.com/maia -' --- http://olofson.net --- http://www.reologica.se ---