[gmpi] Re: Topic 7.3: Unconnected inputs/outputs
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 11 Jun 2003 00:27:31 +0200
On Tuesday 10 June 2003 23.34, Marc Poirier wrote:
> > > I don't like any of the above options. Honestly, I kind of
> > > hate the
> > >
> > > Why shouldn't a plugin just say "I can handle these i/o pairs"
> > >
> > > 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
> >
> > Because I fully expect to be able to configure plugins and wiring
> > on the fly. I should be able to yank a wire WHILE THE GRAPH IS
> > RUNNING and plug it somewhere else, and not worry about
> > initializing plugins.
> >
> > Connecting and disconnecting should be a realtime-safe operation.
>
> Okay, well that at least is a reason, but in my opinion not a good
> reason.
>
> First of all, it can be very inefficient. It requires the plugin
> to always create all of the resources that it would need for
> maximum number of channels that it might process.
The ability to instantiate plugins with different channel counts and
layouts and unconnected ins/outs are not mutually exclusive, are
they? I think they're different things, with only some overlap.
Maybe there is a third system, that covers it all?
[...]
> But probably most important is the fact that changing i/o
> configurations can't be realtime-safe in some contexts. Depending
> on the plugin, it may have to reconfigure things dramatically for
> one i/o config vs. another, and the assumption that such a
> reconfiguration will always be realtime-safe is just going to make
> things a lot harder (or impossible) for some plugin authors.
So, just don't worry about it in relation to connections. Only
consider allocating and precalculating stuff during instantiation.
> But with all this said, there's still no reason why we can't do
> things the right way (real stream count negotiation) and still
> allow some connecting and disconnecting in realtime. Connecting
> and disconnecting while the graph is running isn't even something
> that most hosts can or will do, but for those that do, I don't
> think that it would be ridiculous for them to just configure the
> plugin with the max number of channel that might be needed and then
> send silence through the unused channels if they get disconnected,
> and then when the opportunity is available, really reconfigure and
> re-initialize the plugin, or something like that.
Right.
Though, I'd like to point out that it's not *only* about real time
(dis)connection. For any plugins where inputs and outputs aren't two
groups of identical channels, there either has to be some way of
leaving ins and outs unconnected, or the instantiation scheme will
have to be *very* elaborate. You can't just assume that
reinstantiating with N-1 inputs is equivalent to disconnecting any of
the N inputs.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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:
