Multiple Inputs per Node

[sebastian pflügelmeier]

It would be nice to have multiple inputs per node so that things like filters with parameters controlled by more inputs can be done. I will also implement this if it is wanted.

[mitchmindtree]

Thanks a lot for the issue @sebastianpfluegelmeier!

This should currently be supported, however it's a bit of a pain to use atm as it simply means the audio_requested method gets called multiple times (once for each input).

It would probably be nicer if the audio_requested method took two args - &[(Id, &[F])] for the inputs and a &mut [F] for the output. Would be great to get your thoughts!

[sebastian pflügelmeier]

Thank you for your quick response @mitchmindtree.

Allright, suppose i have two Nodes A and B which send their output two distinct inputs of the Node C.
The output of Node A is a [f32; 2] but it only writes to the first position and the output of Node B is a [f32; 2] but it only writes to the second position and the input of the Node C is a [f32; 2]. Is this how you would do it right now?
I could try to implement the version you proposed. Maybe with the Id as an Enum if we want to make it perfectly safe. If we want to build it on top of the current implementation without chanigng a lot we could add an input_id: Option<Vec<String>> field to Node and add a function add_connection_with_ids(&mut self, src: NodeIndex, src_id: String, dest: NodeIndex, dest_id: String) to the Graph struct. What do you think?

[sebastian pflügelmeier]

Maybe the type of input_id should just be Option<Vec<T>> where T: Eq

[mitchmindtree]

Maybe with the Id as an Enum if we want to make it perfectly safe. If we want to build it on top of the current implementation without chanigng a lot we could add an input_id: Option<Vec> field to Node and add a function add_connection_with_ids(&mut self, src: NodeIndex, src_id: String, dest: NodeIndex, dest_id: String) to the Graph struct. What do you think?

Ahh sorry, to clarify - by Id I meant to refer to the NodeIndex for each node that is returned from the graph when a new node is added. There shouldn't be any need to add a new Id type or any new methods to the graph.

[sebastian pflügelmeier]

So you would recomend a node knows where each input is coming from? I would rather have multiple inputs per node and have a method
audio_requested_by_id(&mut self, buffer: &mut [F], buffers_by_id: &[(usize, F)])
with a default implementation

audio_requested_by_id(&mut self, buffer: &mut [F], _: &[(usize, F)]) {
    self.audio_requested(buffer);
}

So we would not break backwards compatability and can have multiple inputs which can be connected with a function

add_connection_by_ids(&mut self, src: NodeIndex, src_id: usize, dest: NodeIndex, dest_id: usize)

what do you think about that?

[Ales Tsurko]

Hi guys. I'm really interested in this library here in 2019 and particularly I need this feature. This would allow to modulate a node parameter (input) by the output of another node, right? If so, I should add, that it should be possible to make multiple outputs too. Using analogy with modular synth, you have many inputs and outputs, which you can modulate or use to modulate inputs of other modules. As I said, I'm extremely interested in this feature and you can count on me as labour force. I could implement it, just give me a direction.