Here is possibly the easiest to implement, best bang for buck UX suggestion ever:
Moving multiple jacks at once with the shift key is nice, but it shouldn't need the shift key at all, this should just be the default. If VM just pretended the shift key is always held down for jacks, it's suddenly a lot better. I noticed that I have unconsciously learned to hold the shift key whenever moving any jacks at all, which really jumped out to me that yeah, it clearly should just be the default. If I ever forget to hold the shift key, it only hurts the workflow, which seems silly. If I ever have my left hand occupied, like with a coffee or a cat that wants to be held, suddenly I can't use VM properly because shift key needed.
jclounge wrote: ↑Tue Aug 17, 2021 5:21 am Moving multiple jacks at once with the shift key is nice . . . .
I learned patching on a Moog (early 1970s) when patching was done one cable at a time. So, that's how I do it in VM. To help understand the issue here (and possibly integrate patching methods unique to soft synths into my workflow), I have some questions:
Does "moving jacks" mean moving virtual cables from one set of different jacks to another set of different jacks at the same time? Or does it mean moving all the cables connected to a single multiple to another single multiple? Or does it mean something different?
Steve W wrote: ↑Thu Aug 19, 2021 2:21 pm
Does "moving jacks" mean moving virtual cables from one set of different jacks to another set of different jacks at the same time? Or does it mean moving all the cables connected to a single multiple to another single multiple? Or does it mean something different?
Sorry about that, I'm not well versed in all the terminology! What I meant was the second one, moving multiple cable endpoints all connected to a single socket (mult) over to another single socket (mult).
It's unfortunate that people use the word jack in isolation as it's ambiguous. It could refer to a jack socket or a jack plug.
When there's only one cable plugged into a socket then when you click drag it unplugs the cable and you can use the mouse (or touch pad or touch screen) to move a jack plug about. If you end the operation over a compatible socket then the plug goes in the socket. This is obviously what you do all the time.
But when there's more than one cable plugged into a socket and you click drag then it behaves differently. It doesn't unplug all the cables and allow you to move multiple jack plugs at once. To do this you need to hold the shift key down.
In either case if you just click rather than drag the multiple opens up.
So what the OP is suggesting is that VM should behave as if the shift key is always pressed as this allows you to do everything you can without the shift key pressed AND the things you can do with the shift key pressed. It improves and simplifies the workflow and allows you to have one hand free to do something else.
It's obvious that the shift key operation was added as an improvement but it wasn't realised that there wasn't actually any need for the shift key as everything works better if the behaviour is simply as if the shift key is always pressed.
I'm labouring this but to summarise - if VM behaved as if the shift key was permanently pressed you could move single jack plugs or multiple jack plugs with a simple click drag (and the operation would then be symmetrical and less confusing as well as saving you the hassle of pressing the shift key). Or rather than dragging a simple click still opens the multiple so you can do more detailed operations.
Thanks for clarifications in terminology. For me a plug got put into a jack in terms of synths, though for AC a plug got put into a socket. The next time I am patching in VM I will try to design something so I get the feel for pulling out different numbers of plugs and moving them all to a new connecting point.
I was checking the behaviors of sockets (empty socket, one cable attached socket, multiple cables attached socket) ...
To explain my thoughts, a mouse click is composed of multiple actions : a "mouse down", when I press the mouse button down, and a "mouse up", when I release the mouse button.
Currently a socket have two different behaviors :
If empty or attached to only one cable, "mouse down" does nothing, or select the currently attached cable, and "mouse up" opens the multiple for the socket ...
If attached to multiple cables, then "mouse down" directly opens the multiple for the socket.
So to be consistent, perhaps would it be a good idea to only open the multiple on "mouse up", whatever the number of cables attached to the socket, and "mouse down" should always select any currently attached cables to the socket.
With those rules, when you want to move all cables at once, a mouse down and drag would be OK ... and it will still work if only one cable is attached.
And if you only want to move one cable from a multiple attached cables socket, you would just have to release the mouse button (mouse up) to open the multiple, so you can select the one cable you want to move.
What do you thing of this proposal ?
Note, I'm not sure about the impact this change could have for the module developer's ...
elamid wrote: ↑Fri Aug 20, 2021 8:50 am
What do you thing of this proposal ?
Note, I'm not sure about the impact this change could have for the module developer's ...
Hi Eric, YES, that's exactly what the shift key already does! So your proposal seems essentially the same as always pretending the shift key is held down, unless I'm missing some nuance?
This would be the easiest thing in the world for the developers to do. Without even looking at the code we can already know this trivially simple thing would work: Wherever in the jacks/cables code it says "is the shift key held down", change that to "true". Beyond that, it would be a matter of taste/preference whether to simplify the code even further, given that there would be even less code paths to worry about than before.
It would be similarly easy, but with slightly more boilerplate code added, to make this into a user preferences check box, which would ensure that everyone is happy even if they for some reason prefer the current behaviour.
As far as I can see the behaviour that Eric is describing is exactly what happens when the shift key is down.
This behaviour isn't handled by module developers by the way. It's handled globally by Cherry Audio's code. So wouldn't require any module updates to implement.
It should be just a one line modification taking maybe ten minutes work in total to locate the code, change it and recompile. Longer if they were to offer a user option to turn it on and off but why bother? I can't see any down side from changing it permanently to "shift always pressed behaviour".
