Re: [linux-audio-dev] XAP spec - early scribbles

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] XAP spec - early scribbles
From: David Olofson (david_AT_olofson.net)
Date: Sat Mar 01 2003 - 20:15:14 EET


On Saturday 01 March 2003 15.00, Simon Jenkins wrote:
[...]
> >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.

"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.

> >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).

LOL :-)

> 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.

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.

> 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 ---


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Mar 01 2003 - 20:08:49 EET