[gmpi] Re: Topic 7.3: Unconnected inputs/outputs
- From: Marc Poirier <fipnid@xxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 10 Jun 2003 11:19:08 -0700 (PDT)
> Topic 7.3: Unconnected inputs/outputs
> ------------------------------------------
>
> Q: How do we handle disconnected inputs/outputs?
>
> a) They are given a NULL buffer and must detect it.
>
> b) They are given a zero-filled (or SILENT) buffer.
>
> c) If a plugin supports disconnected inputs/outputs, they are flagged
> or negotiated at connection-time. If an in/out is agreed to be
> disconnected, no buffer is needed. Otherwise, the host must provide a
> zero-filled (or SILENT) buffer for logically disconnect in/outs.
Sorry for the maybe-late reply (my email server died a few weeks ago and I
guess I was unsubscribed at that point, so I've missed tons of GMPI
mails)...
I don't like any of the above options. Honestly, I kind of hate the
notion of a plugin having any particular array of inputs or outputs that
it uses. Why should a plugin maintain some fixed set of inputs and
outputs and then check to see if some are available or not? That's just
goofy and unnecessary. It's the sort of limited thinking and assumptions
that come from a hardware mindset, when we're dealing with software.
Why shouldn't a plugin just say "I can handle these i/o pairs" (providing
some list) and then the host says "right now, I want you to do this i/o
configuration" and then that's what the plugin does. Do we really want
plugins to be inspecting their inputs and outputs when rendering audio?
And additionally, I think that most plugins can be designed to handle an
arbitrary number of channels, so the idea of having some fixed quantity of
inputs and outputs is limiting.
Look at how AU handles this, for example. A plugin has a
SupportedNumChannels property. The host fetches the value of this
property and gets a list of i/o pairs:
struct AUChannelInfo {
int numInputs;
int numOutputs;
};
This list can be of any length, whatever is necessary, and the plugin can
also return NULL for the list. If the list is NULL, then this means that
the plugin can do any N-to-N i/o pair (i.e. as long as the number of
inputs are the same as the number of outputs, it's doable). In practice,
I think that the vast majority of plugins can be designed for N-to-N
processing and we would be severely lacking foresight to foresake that
option by using this whole notion of a plugin having a certain set of
inputs and outputs. But anyway, back to AU. The host then sees what the
plugin can do and sets the StreamFormat property to the number of inputs
and outputs that are desired. If the host tries some illegit pair, then
the plugin will fail to initialize. If it's okay, then the plugin can
initialize and then can take a look at now many ins and outs it will be
dealing with and behave accordingly.
Given that, with modern computers, it's trivial to create and destroy
stream buffers as needed, I just really really don't understand why anyone
wants this approach of a plugin having x inputs and y outputs and
connecting or disconnecting them...
Marc
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
