Re: Multichannel configs etc.
Re: Multichannel configs etc.
- Subject: Re: Multichannel configs etc.
- From: William Stewart <email@hidden>
- Date: Fri, 12 Nov 2004 11:19:20 -0800
On 12/11/04 3:16 AM, "Michael Kleps [reFX]" <email@hidden> wrote:
>> To be honest I think the best solution is the following.
>>
>> Publish your AU with multiple outputs, each being stereo. We've been
>> pretty
>> clear for a considerable time that particularly with an AU Instrument
>> this
>> is entirely expected (and recommended) for AU's that have a static
>> config
>> capability. (An example of this is Art's Phatmatic Pro - its been out
>> like
>> this for over a year or more)...
>>
>> Then, hosts that are not supporting this will still at least give you a
>> single stereo output.
>>
>> I realise that this is not good for you in the short term - but its
>> been
>> acknowledged (graciously I might add) that this is a problem in Logic
>> that
>> will be fixed.
>
> OK. Now only THREE questions arise:
>
> 1) How do I detected how many buses have been created/are supported by
> the host? Is there a function I can call in Render (or elsewhere) to
> detect it? Please name it.
You can always know the bus count - its the number of elements on a given
scope (input/output)
But, there's a problem currently... We're going to introduce a new property
called ElementInUse (EIU) that a host can set on these buses... The problem
is that for an input you know whether you have a connection or not, but for
an output you don't, until you are called for the first time! So, you have
to assume currently that all of your outputs are in use.
So, the idea would be this. We'd default the implementation (for
compatability reasons) of this EIU to true for each bus. A host can go
through and enable/disable elements as the AU is configured...
The host can only enable/disable elements when the AU is not going to be
asked to render on that bus. Then, the AU can do any
allocations/deallocations in response to that call. Calling for audio on a
disabled element would return an error.
> 2) I understand that Render() is called for each bus seperatly. How do
> I detect for which bus the current Render() call is? Which function
> should I call to find out?
RenderBus in the AU base classes tells you - the caller of Render tells the
AU which bus its rendering for - and this is propogated down to the AU's
internal rendering code...
> 3) Since I have a VST-style instrument beneath the AU functions (it's a
> small wrapper), I can't support real rendering of seperate output
> buses, hence I plan to render all outputs into internal buffers when
> the timestamp changes and copy the buffer into the AUs output buffer
> when Render() is called with an identical timestamp. Is this a sensible
> approach and how do I find out the timestamp (sample-position would be
> nice) for the current Render() call?
This brings up an interesting suggestion... You are basically doing ALL of
the work that you need to do in order to support the dynamic output logic.
Instead of publishing a static configuration of buses, why don't you publish
your AU's outputs as dynamic?
For instance, you can do up to 16 channels. So your SupportedNumChannels is
published as { 0, -16 } (BTW, that's ALL you need to publish!)
Then the host will go and configure some number of combinations of buses and
channels (your AU doesn't really care!!!) as long as that total channel
count is <= 16
Then (just as you describe above) you'll do your rendering into your
internal channel array the first time one of your outputs are called with a
new time stamp. Then you just count from output num up to figure out which
or your 16 channels goes into that output element's buffers.
(In some respects its like the way Logic was doing the "multi-bus" synths,
except that we wanted to provide a facility for the host to have the AU
split up its channel array into separate buses).
We've an example of this style of AU Synth if anyone wants to look at the
code for this - send me an email and I'll post it off to you.
Bill
(oh, and if you are on Tiger seeds, there's a nice little utility developer
app we wrote that supports both the dynamic config and multiple "static"
output configs too)
>
> Thanks,
> Mike
>
--
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
__________________________________________________________________________
_______________________________________________
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