You don’t need the Addition module any more, you can just plug in more than one voltage.
Using it as an OR for gates can be even more useful. With the VCV Pulse Matrix, I use the Submarine OG 106 to combine two trigger rows, in order to add occasional random triggers.
See, all I had to do about it is to sleep on my own question
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.
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.
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.
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.
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.
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.
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.
