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: "email@hidden" <email@hidden>
- Date: Thu, 18 Nov 2004 06:53:01 -0500
Hi,
Stefan is right about the complexity of connection-negotiation. Inevitably
there will be some complexity; the best we can do, I think, is to limit how
far across the code it spreads.
I believe we can win some simplicity of implementation by decoupling the
semantics of format-negotiation from the buffer-delivery and rendering
mechanism. Even VST's super-simple render architecture (here is an array of
float buffer pointers, please write to them) is perfectly adequate; it's
the process whereby connection-meaning is assigned to the individual
buffers that's problematic (or rather, in the case of VST, completely
lacking).
A plug-in knows which formats it supports, and oftentimes it will support
only one format with any given configuration. So, by having the plug-in,
rather than the host, lead the format-negotiation "dance", we can make
things considerably simpler.
Something like this:-
HOST: Begin negotiation. I have support for a max. of A buses, please don't
bother trying to connect buses beyond that.
PLUG-IN: Here is my first output bus, I would like to connect it in format X
HOST: (answers yes or no; may say yes but return a preferred format. The
host should not ask for that preferred format again if the plug doesn't
request it on the next pass. This way, the host can fall back through a
list of preferred formats, but without unnecessary calls.)
PLUG-IN: (can then either make another connect on that bus with a different
format, or move on to the next bus)
PLUG-IN: (if there has been agreement on a format for the bus, complete the
connection for this bus)
Once the plug has tried to connect all its buses, it call the host again
and gets a render-buffer index for each channel of each bus, so as to find
out where in the render-buffer frame the channel will be located, if at all.
Finally, the plug returns to the host whether or not it has been able to
obtain a valid connection setup through this process.
A plug-in must be able to request a renegotiation of this process at any
time, because you want plug-ins to be able to change their I/O
configurations on settings-restore or if the user changes the number of
outputs in the plug-in's UI. However, the host must be able to refuse.
I know this system is not *much* simpler than what exists at the moment,
but it has two advantages:-
-- Limits complexity to a single area of the code, rather than having the
complexities of connection-negotiation exposed in multiple places.
-- The plug-in has better knowledge of what it can/can not do than the
host, so this removes a lot of blind guesswork by the host as to what the
plug can / can not do.
Original Message:
-----------------
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.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