Re: A modest proposal
Re: A modest proposal
- Subject: Re: A modest proposal
- From: Frank Hoffmann <email@hidden>
- Date: Wed, 17 Nov 2004 01:32:58 +0100
I agree with Glenn. The situation with I/O configurations of Audio
Units it not the best. The current system has too many redundancies,
is too complicated and doesn't cover all possible ways to setup busses.
Something should be done. 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.
Frank
On 14.11.2004, at 16:27, Glenn Olander wrote:
AU I/O configuration has been a persistent source of trouble with AU's
from the beginning. The list archives contain many posts from
developers who are confused by the topic. After 2 years, nobody has
succeeded in fully implementing the multiple output design proposed in
the spec. Flexible I/O configurations is one of the most significant
advantages AU has over VST, but if this advantage exists only on
paper, then what have we achieved? I humbly suggest that the problem
isn't with developers, but with the spec itself, and the solution is
to change the spec. Since it hasn't yet been fully implemented anyway,
now seems like an opportune time to make such a change. The following
is a proposal for such a change, and is in the spirit of some changes
Bill proposed a while ago, but addresses the complexity problems Marc
and others identified in Bill's suggestion.
I believe the problem with multiple outputs in the current spec is
two-fold:
1) The design proposed in the spec is overly complex.
The byzantine nature of the way a plugin describes its bus
configurations and channel configurations has been a source of trouble
from day one. The lack of coupling between busses and channels, the
negative numbers, the obscure way the supported bus count is described
to the host, etc. have led to a great deal of confusion.
2) The design proposed in the spec does not match the needs of
users/host developers/plugin developers.
Those few people who have overcome the complexity of the spec to
understand I/O configurations, are then confronted with the
realization that
the semantics used by the plugin to published its supported I/O
configurations do not match the way plugin developers think of their
I/O configurations, nor does it match the way users think of their
choices of I/O configurations.
I propose we change the spec as follows:
A) A plugin publishes its supported I/O configuration in a simple and
unambiguous fashion. It should describe:
- The number of supported configurations.
- The number of input and output busses in each configuration.
- The number of channels in each bus.
For example, an output-only plugin which supports 2 configurations,
one with a single stereo out, and second with three stereo outs and
one mono out would publish the following information via GetProperty:
Number of Configurations: 2
Configuration 1 (1 bus):
Output Bus 1: 2 channels
Configuration 2 (4 busses):
Output Bus 1: 2 channels
Output Bus 2: 2 channels
Output Bus 3: 2 channels
Output Bus 4: 1 channel
For example, the AU code would look something like this:
static AUIOConfigInfo info = {2, {1, {2}}, {4, {2, 2, 2, 1}}};
This is much more explicit than the current spec and makes it possible
to understand what configurations are supported, especially when
trying to see how many channels are on each bus. If you have a
large/dynamic set of configurations you can support, the first choice
should be to explicitly list them all. If that is not possible, the
spec could be expanded to include wildcarding (e.g. 0 channels means
any number).
B) A host selects from the set of configurations published by the
plugin.
By default, the host/plugin use the first configuration published by
the plugin. However, while the AU is uninitialized, the host may
select, presumably on behalf of the user, any of the published
configurations by simply specifying the configuration index number via
SetProperty.
For example, a new property (for example, call it
kAudioUnitProperty_IOConfig) would have an integer datum. In the above
example, sending 0 to the AU would select the single stereo output
configuration. Send 1 would select the four output configuration. This
gives the AU a clear indication, outside of Render(), of what
configuration the host expects.
I believe this proposal is the best way to jump start support for
multiple outs in AU's. Also, it is easy to transition to this model:
if the AU doesn't support the new configuration property, then the
host can simply fall back to whatever it does now.
- Glenn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
------------------------------------------------------------------------
-----
frank hoffmann mailto: email@hidden
ableton ag http://www.ableton.com
_______________________________________________
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