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?
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!
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!
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.
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.
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.
