I am with you on that. What irks me is not the deviation from hardware (I use and love polyphony in VCV for instanceā¦) it is more than this particular deviation is not something I see the point of, and it complicates patching when you just want to ignore it by taking the default behavior of CMD+drag over the cable copying mechanism.
Anyway, Iāll get use to it, I am sure, but Iāll have to make clear when using VCV in class that this is weird and not something you want to do on hardware.
Iāll tell you one thing I will love about this (once I update after an important show next weekendā¦).
Not needing a silly summing mixer to patch start/stop/cont into the same thing to control transport when running the plugin in Reaper.
Of course, I wouldāve rather just had a way to keep a gate high while transport plays. 
Itās strange that DAW transport state isnāt in the rack APIā¦ but this change is very welcome and at least alleviates one nuisance.
And there are definitely some other situations where I just want to sum two things, this will help with those.
Me too, but I chalk it up as one of those āFirst World Problemsā.
Then again, there have been times Iāve wished for stackable inputs in addition to stackable outputs. It has origins in real-world stackable banana plugs such as Iāve used on an ARP 2600 and various electronics test gear.
The key command is correct. Click-drag on the menu item to create a new cable.
In previous Rack versions, Ctrl+dragging an output port created a new cable. Now this key command works on both inputs and outputs, which is the only consistent behavior.
Scaling/offsetting is usually only useful for CV. You typically donāt need to scale/offset other signal types like audio, 1V/octave pitch, gates, and triggers.
Should I change VCV Rackās slogan to āBetter than Eurorackā?
Rackās plugin API allows modules to receive MIDI transport messages. This data includes Start, Stop, Continue, and Clock events, as well as Song Position messages. Contact VCV Support if you have ideas for more DAW events/information.
Right! Will do, thanks.
How about MIDI 2 (arriving soon on Windows, in beta now).
Iām confused. I pointed out that the menu says āDuplicate top cable ctrl-dragā.
Nowhere in the context menu is ctrl-shift-drag even mentioned as a key combination.
Did you perhaps misread my post or has it been a much longer and tiring day for me than I thought?
Both Ctrl+Drag and Shift+Ctrl+Drag duplicate the top cable - it is just a question as to where the duplicate is anchored - from the port that you dragged from? or the port on the opposite end of the cable?
Definitely the context menu should mention both options, with a more clear description of what each key combo does. I think most of us (all?) agree it is unfortunate the Ctrl+Drag behavior was changed. But I imagine we will get used to it. An unnecessary inconvenience to learn the new interface, but not the end of the world.
I donāt know if anyone besides me formally requested going back to old behavior via a support email after the 2.5.0 pre-release. I imagine if more people had, it might have been addressed. I think sharing info on the forum is critical for the community at large, but if we want changes it really needs to be also sent to the official support. I suspect multiple formal requests is more effective than a single request.
I know not all requests are implemented, but I also know that some of my requests have been implemented. Case in point - the 2.5.1 change where the last cable color is remembered and used when color auto-rotate is off.
Now that 2.5.1 has officially been released, I think it may be too late to revert Ctrl+Drag behavior - the cat is out of the bag.
New ergonomics aside, there is a small technical advantage, which is only going to matter for some patch types (and then only sometimes)āno one-sample delay for summing at an input. So if I have two copies of voltage A and I want to add voltage B to one of them while keeping them exactly phase-coherent, I no longer need to pass voltage A through a dummy module in order to keep it locked with voltage A+B. Regarding @TanaBarbierās point, this could be seen as a small step towards hardware in outcome, although not in interface.
Significant? Probably not often! But measurable:
This is an awesome story BTW! I love their modules.
Iām okay with the change. Wonāt take more than a couple of hours to adjust. I was just pointing out what I thought as an oversight in the UI.
Still a little confused, as you are saying that both ctrl-drag AND shft-ctrl-drag will duplicate the top cable? Any way I try it, ctrl-drag without shift does NOT duplicate cables for me.
I donāt think I often mix audio without scalingā¦ Triggers I get, gates not so sure since I often use those with slews, and then voltage matter. Triggers ok, for sure. V-oct I donāt think so, in some cases but really not in the general caseā¦ Anyway I will adjust and keep thinking it is a weird choice.
Well, it is your prerogative to find a hook that sells the product and I guess you still want to use the reference to eurorack since it is part of the idea but it has shifted to something more/ different, hasnāt it?
Upon looking more closely, I can see how it might not be considered a duplicate. To me a duplicate should preserve the color of the top cable, and Ctrl-Drag no longer does this (Command-Drag on Mac). But it most definitely is different behavior than simply Click-Drag when there is an existing cable. A Click-Drag will move the existing cable. A Ctrl-Drag will create a new cable anchored at the clicked port, using the most recent cable color if auto rotate is off, else the next color if on.
So Click-Drag will move the top cable if it exists, else will create a new cable. Ctrl-Drag will always create a new cable.
Or are you not seeing this behavior?
I understand now.
Yes, I am seeing the behaviour you describe. My confusion was a matter of semantics. I donāt consider this behaviour as duplicating a cable but rather simply adding a new cable on the selected port.
The shft-ctrl-drag function is what my brain considers duplication - making a copy of an already established connection that I can drag to a new port.
Thank you for clearing that up.
I definitely can understand that view point, especially given the cable color is not preserved.
Perhaps Ctrl-Drag could be called āForce new cable creationā, and Shift-Ctrl-Drag could be āDuplicate top cableā
That would be better yes. Then again, since no-one else has brought this up perhaps itās just me
As a side note Iāve already adapted to the new way without much trouble and have bound both combinations to mouse buttons for one-handed operation so the extra key press is a non-issue.
