Re: A modest proposal
Re: A modest proposal
- Subject: Re: A modest proposal
- From: Robert Grant <email@hidden>
- Date: Mon, 15 Nov 2004 21:47:07 -0500
Here's a 3rd from a host perspective.
There are two reasons why multi-outs aren't supported in Rax. The first
is the complexity of figuring out and/or specifying the outputs of an
AU. The second is that most AUs are reporting two busses available when
really there's only one. (Though I'm sure the Rax killer in Tiger
handles all this with aplomb!)
I would love to be able to run through the available configs as
described in Glenn's proposal and choose the most appropriate one - or
easily reject an AU if it doesn't support what I need. It does seem
that most AU developers will want to support fixed configurations in
order for their UIs to be usable. Though some AUs like the Matrix Mixer
can get by with a flexible buss/channel configuration approach.
Actually this leads to an interesting question: how would the Matrix
Mixer fit with this proposal? Would it describe its default inputs and
outputs as {0, {0}}?
Robert.
On Nov 15, 2004, at 6:25 PM, Urs Heckmann wrote:
To be honest, I second Glenn's observation.
I don't know if Glenn's proposal is best or anything, but one thing
that holds me back from doing multi bus plugins is definately that I'm
not really sure how to handle it. I think I would need a week or two
to fully understand what to do with the current specs, or I would give
hosts a hard time with format negotiations ("after about 10 seconds on
an average machine, this plugin finally reports noErr on
Initialize()...")
A dead simple solution would be cool (which I think Glenn's proposal
is). I have the overwhelming feeling that any "negotiations" between
hosts and plugins are an expression of uncertainty...
Cheers,
;) Urs
Am 14.11.2004 um 16:27 schrieb Glenn Olander:
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.
_______________________________________________
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
_______________________________________________
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