Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support side-chaining: Use Edge to represent connection kinds. #111

Open
mitchmindtree opened this issue Jun 5, 2015 · 1 comment
Open

Comments

@mitchmindtree
Copy link
Member

We could create an Input type to use as the Edge type for our petgraph::Graph. Something like:

pub enum Input {
    Regular,
    SideChain(Buffer),
}

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.

@mitchmindtree mitchmindtree changed the title Support side-chaining: Use Edge to represent whether connection kinds. Support side-chaining: Use Edge to represent connection kinds. Jun 5, 2015
@defuse
Copy link

defuse commented May 3, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants