1 Mar
2003
1 Mar
'03
7:40 a.m.
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 ---