All you need is the ability to detect when a signal cable is routed to an inlet.

A non-signal inlet of an object will receive a "signal" message when a signal cable is connected to it. A tapin~ object will output a "tapconnect" message when a signal cable is either connected or disconnected.

With a little logic, you can use this to route the signals to simulate a half-normal patchbay.

Here is a quick example I made.

It has two inlets.

The first is the normal inlet, and should remain connected to the output that normally feeds it.

The second is the insert inlet, and you should route into that to simulate plugging a patch cable into the input jack. The abstraction breaks the connection of the normal inlet to its output and passes signal from the insert inlet instead.

It has two outlets, but routing from the "insert" outlet does not disconnect (or in any way affect) the "normal" outlet.

This is what you want, yes?

The logic that you apply in your example is very valid, but the problem is located at the junction of editable patchbay, with logic connection. Since this must be reflected in the patchbay. Can not there are two cables coming out of a single output.

attached an example

THX.

I don't really follow what the problem is, or what I should be looking for in your example. Could you be more clear?

The patches you attached are ones that I made, but I still am not really sure what you are trying to use them for. Could you try explaining exactly what you are doing now, and exactly what you need the patch to do in different circumstances.

It would be quite easy to set up some sort of switching system using [selector~] to route audio around but a bit more work to make it happen automatically as is shown in EasyMac's example.

[gate~ 2]

Yes Luke is your example, as i explained the problem occurs when trying to standardize a half normalize patchbay.

A half normalize is when a patch bay has half-normal wiring, then with no patch cord inserted into either jack, the top jack is internally linked to the bottom jack via break contacts on the bottom jack; inserting a patch cord into the top jack will take a feed off that jack whilst retaining the internal link between the two jacks; inserting a patch cord into the bottom jack will break the internal link and replace the signal feed from the top jack with the signal carried on the patch cord. If a patch bay is wired to full-normal, then it includes break contacts in both rows of jacks.

this sistem is to try to simulate, a good example is the SIM-AV http://www.sim-av.com/

Thx for your patience

I know what a half-normal patchbay scheme is; I've wired plenty of "realworld" system patchbays myself. And the behavior you described above is what is emulated in the example I gave.

It may be confusing you that I have the put the inputs at the top and the outputs at the bottom, but that is because the abstraction emulates a patchbay-wired -device-, with inputs at the bottom row of one patchbay row pair, and outputs at the top row of another. It would be simple to separate the input and output mechanisms from my example if it's more intuitive or practical for your purposes.

It also may be confusing that I've given a single patchbay output "jack" two outlets and a patchbay input "jack" two inlets, but if you think about it, something like this is necessary, because you have to deal with the "normal" signal flow that happens within the bay as well as any patch cord connections you make. If you wish, you can hide these normals behind the scenes with [send~] and [receive~] objects so that they don't have visible inlets and outlets to more closely emulate the physical appearance of a patch bay (normals hidden), and this is possible, but a little more work than I was willing to do for an example this morning.

The problem Easy Mac's logic is create one "virtual cable" for output. In the example of Luke, you have multiple connections from one output. Furthermore, the bpatcher only accepts 16 outputs and 16 inputs and a conventional patch bay is 24 outputs and 24 inputs.

This is another example posted on the forum a couple of years ago it's from this thread: https://cycling74.com/forums/topic.php?id=15454

Are you trying to achieve these changes in edit or locked mode? The patchbay I created was done so you could achieve [matrix~]-esque routing with a visual cue while the patcher was locked to editing. If you don't need this then the other approach is ideal!

in locked mode. in the example of terry has the same problem as there should be only one restriction (for an exit must be a cable to an input), in both examples from an outlet I can go multiple innings.

How to achieve the logical communication of a patch bay half normalize with the UI?.

Insist the problem is create only one restriction, which allows the connection of output to input, and this output can not be used again until this not be disconnected.