Subject: Re: [linux-audio-dev] meterbridge 0.0.4
From: Tom (stillone_AT_snowcrest.net)
Date: Mon Oct 07 2002 - 10:26:45 EEST
> > To me, serial metering is a kludge. Taps are the way. Metering is a
> > visual form of monitoring. I would like to see jack provide the ability
>
>
> Uggh. There should be no special purpose taps IMHO.
In the most generic sense, a tap is simply a read. I would define your
alternative drawing as a tap.
> I don't have a real problem with connecting to inputs (as long as it
> doesn't complicate the graph code too much), but there only needs to be
> oneclass of connection.
There are already two kinds of connections. If a client's input port is
connected to only one output port, the connection is a read. If the
client's input port is connected to more than one output port, the
connection is a write. This kind of connection, many to one, is where
the problem is. I agree that JackPortIsTerminal has nothing to do with
this.
> > the port reconnection code is evil. i think its completely the wrong
> > approach. its just a kludge to avoid using a patch bay.
>
>
> I disagree, its only a kludge because there is no clean way to implement
> it with the current API.
>
>
> The insert connection mode is a feature people want (without dicking about
> with patchbays) and the reconnection code is a logical extension of that.
Insert connection mode for metering is the kludge, metering is
parallel. I don't want to use a patch bay (ever), I think that this
problem indicates that an api change is called for, and I think that
this problem is indicative of a greater general problem regarding the
lack of comprehensive monitoring functionality in jack.
If Client A's input port is connected to only Client B's output port,
then a meter client can effectively monitor A's input port by reading
from B's output port. Reading from an output port is allowed so no
insert connection is necessary. If A's input port is connected to B and
C's output ports, then jack sums B and C's output ports and then writes
the result to A's buffer before A begins its process. It is this moment
after jack has written and before A begins its process that this buffer
could be treated like an output port, and the meter client could read
from this port. Of course jack would need to be modified to allow this.
The larger issue is this. In a jack client/server network the recording
engineer (system administrator) would benefit greatly from having tools
that allow monitoring of data traffic at any node in the network,
visually and audibly. Not just input or output ports, but any node
including different stages of a client process (such as if two plugins
are connected in series in an ardour route and I want to monitor the
output of plugin 1). The connections to these monitoring tools are made
and broken in real time and don't interrupt the graph, as they are
terminal. These tools are Solo, Control Room Out, and Meter.
Tom
This archive was generated by hypermail 2b28 : Mon Oct 07 2002 - 11:29:03 EEST