Subject: Re: [linux-audio-dev] XAP spec - early scribbles
From: torbenh_AT_gmx.de
Date: Sat Mar 01 2003 - 14:38:12 EET
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
This archive was generated by hypermail 2b28 : Sat Mar 01 2003 - 18:03:53 EET