In the most generic sense, a tap is simply a read. I would define your alternative drawing as a tap. 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. 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