13 Dec
2002
13 Dec
'02
6:21 a.m.
On Friday 13 December 2002 03.07, Tim Hockin wrote:
[...]
Well, yes; that was a bad example, since you actually *have* to
either place the inserts before the mixer, or *host* them, since
otherwise, you'll have one buffer's worth of delay for each insert.
*heh* If you really need an input section for the mixer, it'll have
to be implemented as a separate plugin, so you can put the inserts
between that and the mixer plugin.
Ok.
I'm not sure about the "variable numbers of Bays" thing, but it does
cover things like adding extra inputs on a Channel, *even* when
inputs come in stereo pairs, 5.1 sets and the like. You'd have a Bay
Template for such a group of Ports, and then you can tell the plugin
how many you want, within the limits specified in the Channel
Template. (Most plugins will probably hardcode it, but here, it *can*
be dynamic - on a per-Channel basis.)
Anyway, I'll keep working on the event system, I think. (Although I
have to work some for money as well... *heh*)
Right now, I'm thinking about interpolation and ramp events. I have
an idea about something better than linear, that can be handled like
linear by the lazy receiver. Might work - or not; remains to see.
//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 ---
How about a
mixer with variable insert count? There are several
ways to implement that, but I can't think of one that doesn't
require either that dreaded "link" feature, or an extra level of
"grouping"...
I prefer not to tie the model to hardware like that: I prefer to
think of the insert effects as coming before the mixer in the
chain. I think it's just simpler. So, you
basically have a bunch of control channel descriptions
and a bunch of io channel descriptions, and then the host can
test for valid combinations of those when adding new channels?
That's what I was saying. I'm not sure it's really useful.
I need to digest the rest of this email. I'll have a new version
of the header with most of what we've been discussing in one form
or another hopefully tonight. Then we can keep banging out
details.