9 Dec
2002
9 Dec
'02
9:22 a.m.
On Monday 09 December 2002 13.29, Steve Harris wrote:
On Sun, Dec 08, 2002 at 11:43:07PM +0100, David
Olofson wrote:
But if you do them all at once - or say 4 at once, SIMD, for
something more realistically useful - it's one port per channel that
sucks. Well, you'll just have to sort merge a much of queues, but
still, that's overhead and complexity that *could* be avoided
entirely. (*)
So, just use a few bits of your "target IDs" for "subchannel index"
[0,3], and use one port for every 4 channels. Done!
(*) One example would be if all your channels are driven by the same
sequencer, which has only one internal loop for event output. Then
event ordering is guaranteed, no matter how many input ports the
synth has, or how things are connected.
//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 ---
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?
Well, it depends wether your synth resolves all the channels at
once or one at a time.
If you do them one at a time, then agreed, it sucks.