1 Mar
2003
1 Mar
'03
2:23 p.m.
On Saturday 01 March 2003 15.00, Simon Jenkins wrote:
[...]
"Sending the user there" means he/she could use the "parts" on their
own.
Either way, if there's a specific feature that allows plugins to have
multiple process() callbacks, how do we manage connections between
them? If they're not handled as ordinary separate plugins by the
host, the "multiplugin" has to have a way of providing it's own UI
for insert FX and the like, telling the host to instantiate and
connect plugins. Or they'd have to host the plugins themselves.
LOL :-)
Sure - but you're forgetting all the implications this brings. They
*are* essentially separate plugins, and have to be handled as such in
virtually every respect.
These cannot be
single plugins, unless a plugin can have multiple
callbacks. (And I don't think we want to go there.)
Its a straight choice between "going there" and sending the user
there. What you do is
implement them as bundled plugin sets. One "plugin"
actually becomes multiple plugins in the same binary; plugins that
are designed to be used together.
And rename it "XAPP" (XAPP Audio Plugin Pieces... Broken by
Design). Sorry, couldn't resist that one :)
Seriously:
Your proposed solution is already 90% of the way "there" (the place
you didn't think we wanted to go)...
AFAIK, it's already beed decided that you can have multiple plugins in
one binary, and most existing plugin APIs (including LADSPA) do it
that way already. This is very far from 90% of the way "there"...
For example, a
mixer with inserts would have to be split into an
input section and a strip section. You would hook the inserts up
in between these two sections.
...ie partition a mixer into separate components, each with its own
callback. If you're gonna fly across the ocean, why not land
the plane?
This feels more like flying a plane within a plane... ;-)
All
that's needed is to present this collection of components as a
ready-wired sub-graph instead of making the users wire them up
themselves every time.
Algorithmically its a solved problem: Amble's graph sort already
handles the most general case of graphs containing sub-graphs
containing sub-sub-graphs and so on as far as you like, executing
all the internal bits and pieces in just the right order. Thats
possibly a bit OTT for XAP(P?) but a single layer of
"this plugin is actually these plugins wired thus..."
This is a very high level concept, and has nothing to do with the
basic XAP API (callbacks, event queues, connections etc), I think.
There is absolutely no need to screw up the plugin API to handle
this.
would massively extend the range of plausible plugins
and it would
cost *nothing* in terms of runtime complexity. All thats required
is a simple, clean way to express it in the API.
Metadata. It may or may not belong in the actual binaries, but either
way, we're just not going to have plugins with multiple process()
calls and "internal" connections. On the lower levels (non-metadata),
they're just plain plugins, whether they have some kind of higher
level relations or not.
//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 ---