Re: Multiple Outputs/Busses question
Re: Multiple Outputs/Busses question
- Subject: Re: Multiple Outputs/Busses question
- From: William Stewart <email@hidden>
- Date: Tue, 14 Jun 2005 18:27:59 -0700
On 13/06/2005, at 2:38 AM, Urs Heckmann wrote:
Hiya,
I'm getting serious about multi bus & channels. Finally. So much
talk in the past, and now that it's due I'm totally puzzled - so
instead of wading through weeks of checking out stuff, maybe
someone experienced on the list has some quick pointers ;-)
I want to build a plugin that has the following options on the
output side:
Mode 1: 1 Output Bus stereo (all hosts savvy mode ;-)
Mode 2: 1 Output Bus with 4 channels
Mode 3: 1 Output Bus with 8 channels
Mode 4: 4 Output Busses, stereo each
In Modes 2 and 3, these multiple channels have equal meaning. There
won't be any preprocessing for some sort of center channels or bass
channels. They are just meant to be distributed evenly on a circle.
What would be the proper way to implement this close to AU specs?
An example would be highly appreciated 8-)
Which hosts support configurations like this at all?
Should *I* implement a switch for the modes or should my plug
listen to host set channel configuration and switch modes accordingly?
In Mode 4, is it true that the host will call the render proc 4
times, once for each bus? - My algorithm creates these 8 channels
in one go anyway, no matter what. So, do I have to store my output
buffers in order to fill the busses in subsequently passed target
buffers?
And Airy replied:
In Mode 4, is it true that the host will call the render proc 4
times, once for each bus? - My algorithm creates these 8 channels
in one go anyway, no matter what. So, do I have to store my output
buffers in order to fill the busses in subsequently passed target
buffers?
Yes. RenderBus will be called for each bus so you'll have to store
buffers if you internally render them all at once.
You can use Logic 7.1, Live 4 and AU Lab to test these configs.
So, this is the real crux. First time you are called for a given
render cycle, you create these 8 channels of data in one go.
Now given that that is the case, it *doesn't matter* to you how the
user buses the output channels of your synth; at least from the
purely technical point of view.
So, the best configuration for you to publish is:
{ 0, -8 }
Your output scope must also be writable, and a user is free to
configure you to any number of output buses as long as the total
channel count does not exceed 8. Simple: your initial configuration
can be Mode 1 too of course.
Then- you should always describe of course to the user what your
intentions are - the user can do what she wants; sometimes the best
things are those that we don't plan for - so, let go; feel free!!!
Bill
ps - I just had a thought about this... If we could get enough people
to support this mode of operation (the dynamic I/O configuration), we
could add a property which would be "Preferred Configurations" - this
would then give a host and an AU a way to just present a limited set
of easily configurable choices, but without the headaches of trying
to describe or enforce limitations, or even being too flexible in the
config choices. This wouldn't be a hard limit, just a suggestion to
the host/user...
What kinds of configurations are users used to? What's common?
What's the normal way to provide Quattro/Surround these days?
Thanks,
;) Urs
urs heckmann
email@hidden
www.u-he.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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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