Open mitchmindtree opened 9 years ago
Ideally, devices should be able to accept an arbitrary amount of "named" inputs, where those names depend on the kind of device. For example, a simple compressor would have two stereo inputs ("input signal" and optionally, "side-chain") and some mono inputs (ratio, attack, release, threshold). The reason you want those to be mono inputs and not just fixed values is because you may want to automate them. If they're mono signal inputs, then you can have an "AutomationLane" device which provides a mono signal to the parameters its modifying. If you want them to be fixed values, then use some "ConstantValue" device that just always outputs the same value. Same thing for frequency of an oscillator (you can do pitch bend and FM by sending different kinds of signals to the frequency input), etc.
I started writing a DSP library for fun and what I ended up doing was I had two traits MonoEmitter
and StereoEmitter
, and you build the graph by giving each device its inputs as either an Rc<MonoEmitter>
or Rc<StereoEmitter>
, which it saves internally and uses whenever it needs to calculate its output signal. There's a global clock, and each devices calls its input devices' .output()
method to get their output at the current time, and then uses that to fill its own output buffer for the current time. That needed some really ugly/hacky interior mutability stuff and the global clock would make it really hard to parallelize, so I'd be curious to see if there's a better way to get that kind of generality except with an explicit graph.
We could create an
Input
type to use as theEdge
type for ourpetgraph::Graph
. Something like:I'm still not clear on how to add support for this to the
Node
API - will have to do some research and come back to this. Any ideas appreciated!See side-chaining's wikipedia entry.