Re: A modest proposal (regarding multi-I/O for AUs)
Re: A modest proposal (regarding multi-I/O for AUs)
- Subject: Re: A modest proposal (regarding multi-I/O for AUs)
- From: Stefan Gretscher <email@hidden>
- Date: Thu, 18 Nov 2004 03:10:48 +0100
Am 17.11.2004 um 01:32 schrieb Frank Hoffmann:
I agree with Glenn. The situation with I/O configurations of Audio
Units it not the best. [..] Something should be done.
I also fully agree with this.
At the same time I think Glenns proposal need to be rethought. I
wonder if a approach that can ask every bus about it's supported
channel format is more flexible.
This is not a new discussion, it comes up on a fairly regular basis,
but until now it didn't lead to a solution everybody was happy with.
Still I believe there is such a solution, so let's try to find it now!
:-)
But before starting the arguments on possible spec changes again, I
suggest we take a step back and try to sum up all typical plug-in
capabilities or restrictions we need to express with the new scheme.
Here's a try of that, please feel free to add/comment on this.
(Note that this list is not implying everything should be allowed by
the specs, I'm just trying to get a list of what we're looking at
before discussing what should be legal and what should be illegal and
how the capabilities should be described.)
(A) AUs will typically support several but not all possible channel
counts on its busses, some will e.g. only do mono and stereo, others
will only do stero and 5.1 surround, etc.
There's also AUs like Reaktor that can do any channel count per bus up
to a certain limit. (Note that it's entirely possible with these AUs to
e.g. use a 3-channel format on a bus, for which there is no channel
layout etc. which causes problems with other areas of the specs, but
that's to be discussed later when we're going about solutions.)
(B) AUs may have equal capabilities across all busses, others may e.g.
do surround only on the first bus, while the other busses can only do
stereo or mono. An example here is RM IV which has a fixed amount of
stereo outs followed by a fixed amount of mono outs
(C) AUs may very likely be limited in the total number of channels they
can do across all busses.
(D1) It is also possible that there is a limit in the bus count that an
AU can handle, or that
(D2) the bus count is fixed.
(E) A bus might have a special function, like in the case of DLS where
the first bus can output the dry signal and the second bus the reverb
signal. (Using this in plain stereo only will result in a different
behaviour, everything will be on the first bus then.) Thus, it is
important for an AU to know whether a bus is going to be used by the
host.
These restrictions can come in pretty much any combination, which is
why I listed them this way instead of trying to categorize the AUs into
groups.
Looking at this list (which may not even be complete yet, please add
what you feel is missing), I think it's pretty obvious that a solution
that allows for expressing all these restrictions will not be as easy,
and it perfectly explains why the CoreAudio team ended up with a spec
that many think is overly complex - it's in the nature of the problem.
I don't know if it can be made any easier, but my main gripe with the
current standard is that it doesn't even cover all of the above. For
instance, there's no reasonable way for expressing this requirement:
consider a sampler that is able to do
(A) mono, stereo and 5.1 surround,
(B) does offer these formats equally on all busses
(C) can do a maximum of 32 channels
(D) doesn't care about the bus count as long as (C) is ok
(E) treats all busses the same
This is basically a standard sampler, nothing fancy, but it can't be
expressed in the current specs.
Looking forward to your input on this,
Stefan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden