Programmatically Hiding & Disconnecting Ports

I did some searching on this topic first, but please feel free to respond with a link if this has been answered in a previous thread.

I am working on a switch module that goes in two directions. That is, the hardware version is both a 1-to-4 switch and a 4-to-1 switch. So I am looking for ways to do this in VCV Rack that are not too clunky. One approach is to hide the 1-to-4 ports while the 4-to-1 ports are visible, and vice versa. But can you programmatically hide and unhide ports, and disconnect ports before hiding them?

Other approaches? Thanks for your insights!

Ports should not be dynamically hidden. Make two variants of your module, one 1:4 variant and one 4:1 variant.


You can do whatever you want. Your plugin can do anything VCV rack can do. Just go look at the rack code. I think Andrew is saying that he thinks it’s not a very good user experience to do something like that.


Thanks @Vortico and @Squinky for taking time to reply, I really appreciate it. I totally get where you are coming from, Andrew, and it is also the most straight-forward to code.

I also appreciate the vote for creativity from you, @Squinky. Your modules show tons of creativity! <3

I found with a little bit of testing that placing a port off the panel effectively hides it. I hope it works without crashing anything. Since it is not a module for release, nobody will be worse off whatever happens. So why do this at all? I am after emulating a particular hardware experience.

Anyway, that for your help, guys, and thanks @Vortico for making the VCV module development friendly to relatively novice developers. VCV Rack is an incredible thing!

1 Like

That’s even worse than hiding ports.


Problem with it is how do you deal with the cables. In theory you could remove the cables but then when it is switched back from whatever mode how do you deal with the cables. For instance if you save a patch and move a port then reopen that patch the port being in a different location will look extremely weird because the cable will still be in the previous location, not sure how this is handled in v1 but this was the case in v0.x.x. The cable relies on the port location no matter what so simply moving the port off the panel may hide location of jack also upon reopening so you will have a stuck in limbo cable or if a user clicks on the cable that is not hidden they will not be able to reconnect that cable to the off panel port and be left with no choice but to let go of the cable.

2 different modules one for input and one for output is the easiest and less time consuming way for what you want to do in my opinion also. I would not say it is impossible to get it to work the way you want though!


Catro has 1-8-1 switch.

1 Like

Logic is simple: you can’t hide ports in real life so don’t do this in here please


Have a look at my sequencer source, it has hidden ports:

1 Like

One implementation of dynamically hiding components is in For Four. It’s a very unexpected interaction pattern that completely breaks the hardware UI metaphor, so I’ll join everyone in suggesting against it.


@Vortico - Careful what you wish for haha :rofl:


“So why do this at all? I am after emulating a particular hardware experience.”

I’m confused about the wish to do this (port hiding) specifically to emulate a hardware experience?

What hardware module can dynamically hide ports?

1 Like

The hardware module does not dynamically hide ports. It is a possible work-around to emulate a module that can be used bi-directionally.

1 Like

Ah I see - a module whose outs can be ins and ins can be outs depending on how it is patched right? whereas VCV has fixed ins and outs.

Yes, that is it. I am thinking of it as a bit of a challenge to make is simple.

I was thinking about this in a similar context, specifically the Befaco Muxlicer port I’m working on (it’s an 1 in → 8 out, or 8 ins → 1 out switch). @Vortico had mentioned that he thought doing two modules (e.g. Muxlicer IO and Muxlicer OI) would be the way to go, and by default that makes sense to me and would be how I implement it.

For fun, I have experimented with the port hiding pattern, but being care to avoid unexpected behaviour. Specifically I have a menu item that selects the mode, and if you change it, it first disconnects all cables in the switch part and hide/shows inputs/outputs as appropriate. You can think of this part as similar behaviour to “Initialize” in the right click menu but just for a subsection of the plugin.

Example gif (note Befaco bananuts convention of black == input, red == output): here

This does have some advantages:

  • The state of rest of the module continues as is (e.g. you might have some interesting modulation dialled in, or a nice sequence - you wouldn’t be able to easily duplicate this state to a different Module)
  • Code is possibly a bit simpler (otherwise there’s some duplication, probably need to subclass the IO / OI variants)
  • Hardware equivalent is unpatching and switching your bananuts (which isn’t too much of a stretch?), rather than say a port disappearing in the middle of a module / the faceplate decals changing with time.

Any thoughts?

This is a subset of a long running controversy here, which boils down to “should VCV modules have a UI that is like a hardware module”? Some people say “absolutely not”. others say “sure, as long as it’s usable and understandable”.

I agree that if you don’t have to do it, deviating from the simple model is a bad idea. On the other hand, everyone loves “Palette”, and I believe that module changes UI on mode?

Most of my modules follow the traditional model, but some can’t. My Seq++ has popup menus, scrolling, a keyboard interface…

If it’s not already clear, my two cents is “go for it”. Other reasonable people may strongly disagree.

1 Like

This is a major reason why Palette is one of the best especially for a beginner.

But I also love plugins like Vult that have almost no context menu options but put everything on the faceplate.

1 Like