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.) 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. 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. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! --------------------------------. | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `-----------------------------------> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se ---
