On Tue, 2013-10-01 at 15:09 +0200, David Henningsson wrote: > On 10/01/2013 02:51 PM, Tanu Kaskinen wrote: > > I did not plan to allow dual-direction nodes. If you want to represent > > sinks as dual-direction nodes in a UI, I'm fine with adding information > > to the nodes that allows the UI to do the correlation. I'm less > > enthusiastic about doing the merging in the core. That said, I don't > > have better arguments for this than that "allowing dual-direction nodes > > may cause complications", and I don't have good examples of such > > complications at this point, so I may change my opinion. > > So a filter sink, which both consumes and produces audio data, would > then have two nodes instead, one for input and one for output? Could you > elaborate on this, i e, how these two nodes (belonging to the same > filter sink) are connected to each other? The filter sink creates a sink and a sink input as before, and requests that a node is created for both. There's no need to explicitly connect those two nodes - they will be connected by the fact that the filter sink forwards the audio from the sink to its sink input, as it has always done. To allow a nice graph in a UI, the sink input node can indicate with an extra pointer that it's really part of the same node as the sink node and vice versa. I do see the point of dual-direction nodes, and I'm starting to think the idea should be tried out before committing to the solution of adding the extra pointers between e.g. filter sinks and their sink inputs. I added Janos to CC, in case he has some opinions about this. -- Tanu
