feature proposal for bridging cables in VCV Rack

Hi, I would like to propose a feature that could be discussed in this forum so it make sense, I’m not a developer so it might be a big nonsense, or it might need to be though further with more minds

  • In Rack we cannot connect input together and we cannot connect output together
  • In hardware we can do it… but we’ll burn the thing if we do :slight_smile:

Yet one thing we do a lot in hardware (tiptop cables and banana) is bridging: connecting a few inputs together (nothing wrong with that) and just plug one cv signal into the network of cable to control everything at once. It’s super powerful and super fun. Maybe it could be done in Rack

Right now the rule is:

  • inputs CAN be connected to outputs
  • outputs CANNOT be connected together
  • inputs CANNOT be connected together
  • more than one cable at output port ALLOWED
  • more than one cable at input port NOT ALLOWED

To allow bridging operation, the rules should be

  • inputs CAN be connected to outputs
  • outputs CANNOT be connected together
  • inputs CAN be connected together
  • more than one cable at output port ALLOWED
  • more than one cable at input port ALLOWED IF one cable or less is connected to an output port for the complete bridged network

What do you think? does it make sense?

here is an example: the orange cables are bridging the paning modulation of all track so sending a single cv signal into this turns the whole thing alive

2 Likes

I like the idea since I think it will allow more compact cabling for patches, and could be of particular good use for clocks and resets, but I’m worried that it adds a small layer of complexity both for the code that Andrew would have to change and for the ease of comprehension for less experienced users.

For example, say we make the pan chain like you indicate, and then consider the last cable in that chain. It goes from an input to a final input, which is ok by the rules, but now say we unconnect the final end of that cable and connect it to an output; this immediately voilates the property you have stated since now there are two outputs going into this chain (this new output and the original output at the beginning of the chain). So the code has to detect this and somehow do something to bring it back to an acceptable situation. It would either have to auto-delete that cable as we connect it (having a cable disappear might look weird and puzzling for beginners) or detect the situation and not allow us to make the connection at all.

In sum, I see the value in this, and I would definitely use it, but it does come at a small price that requires code changes to Rack and perhaps slightly more complex cable understading for new users.

I think this proposal can be approached like usability problem that can be solved in UI layer without changing engine rules about cables. Like Syntactic sugar in programming languages, they add less verbose or cluttered syntax to do something like before, but behind the frontend it is doing the same thing as before.

Currently, there is ability to Cmd click and drag on the end of an existing cable, it will create a new cable that is starting at the same port as the previous cable. It is cloning cable and drawing just that. But user really dragging mouse from one port to the other. UI layer could be smarter about this and instead draw cable between points user has been dragging cables, but only for this particular example. The engine would still create and keep cables like before this change. We would need to keep information in some way about the result of this user interaction to recreate on next launch how these cables should look. And there are more questions about interaction with these cables, highlighting on hover, removing etc.

1 Like