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

Simon Jenkins sjenkins at blueyonder.co.uk
Sat Mar 1 08:11:01 UTC 2003


David Olofson wrote:

>On Saturday 01 March 2003 04.03, Simon Jenkins wrote:
>[...all good points...]
>  
>
>>That's easily solved... but here's a problem that's not:
>>
>>A general solution to the graph sorting problem would have to know
>>about the I/O dependencies *inside* the nodes. This isn't usually a
>>problem on the  scale
>>where a node represents, for example, a simple filter or
>>oscillator. But what about
>>the scale where a node represents a quad noise gate or a reasonably
>>well-featured
>>mixer (ie with inserts etc)?  Nodes like that aren't just difficult
>>to place correctly
>>in the execution order... they can be *impossible* to place
>>correctly in a very large
>>number of perfectly reasonable graphs: Different parts of their
>>internals need to
>>be executed at different times!
>>    
>>
>
>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)...

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

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.

Simon Jenkins
(Bristol, UK)





More information about the Linux-audio-dev mailing list