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

torbenh at gmx.de torbenh at gmx.de
Sat Mar 1 11:19:01 UTC 2003


On Sat, Mar 01, 2003 at 04:12:49PM +0000, Simon Jenkins wrote:
> torbenh at gmx.de wrote:
> 
> >On Sat, Mar 01, 2003 at 03:03:37AM +0000, Simon Jenkins wrote:
> >
> >>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!
> >>   
> >>
> >
> >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.

well... galan supports a mesh consisting of multiple sheets you can
load from a library (not very refined yet but already extremely useful)

but i think something like this is considered a host issue here.

But i would like that to be part of the SDK as i would like
the graph ordering also...


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



More information about the Linux-audio-dev mailing list