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

[torbenh at gmx.de]

On Sat, Mar 01, 2003 at 08:15:42PM +0000, Simon Jenkins wrote:
> David Olofson wrote:
> 
> >On Saturday 01 March 2003 17.12, Simon Jenkins wrote:
> >[...]
> > 
> >
> >>>then these components must be built of other components...
> >>>i dont see a reason why one wants a big complex component
> >>>if it could be built from smaller components...
> >>>(other than performace)
> >>>     
> >>>
> >>Absolutely they must be built out of other components. The question
> >>is: who does the building? I'm saying that the plugin designer
> >>should be able to present a complex "plugin" which is actually a
> >>ready-connected graph of simpler components. The alternative is for
> >>the plugin designer to present a "bag of bits" for the user to
> >>connect together.
> >>   
> >>
> >
> >If we do this on the right level, we can have both. We definitely 
> >should have a standard graph description (and preset) file format 
> >anyway, and all we need is a way for plugin authors to provide useful 
> >subgraphs with their plugins.
> >
> I'm thinking that if its done on the right level we can have both very
> nearly for free... and only incur whatever administrative overhead
> there might be when the additional functionality is actually used.
>
>
> In terms of its inputs and outputs a subgraph is indistinguishable from
> a real plugin. All thats needed is a very thin code wrapper around
> the administration of the subgraph: A virtual plugin which, when
> you instantiate it, would instantiate all of the real plugins that
> made up the subgraph. Which, when you connected to or from it,
> would cause the connection to actually be made to the appropriate
> real plugin within the subgraph. Which, when you removed it, would
> cause the removal of all the real plugins within the subgraph.
> 
> I'm not up-to-date enough with the XAP spec to know how
> much hassle this would all be, but its all *administrative*
> hassle and doesn't affect the runtime API in any way: The
> virtual plugin never appears in the actual processing graph,
> and the real plugins are perfectly ordinary plugins, connected
> into a perfectly ordinary graph, sorted and called (independently
> of each other) just like any other plugin in the graph.

exactly... in galan a plugin is called generator...
the subsheets are handled on the component level.

i found this to be more elegant then implementing a generator which
in fact is many generators.


> 
> Simon Jenkins
> (Bristol, UK)
> 
> 

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language