On Sat, Mar 01, 2003 at 04:12:49PM +0000, Simon Jenkins wrote: > [EMAIL PROTECTED] 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
