Some Friendly Suggestions

OSC/PILOT Bugs And Feature Requests
1

Good Morning/Afternoon/Evening!

So after spending some time setting up workspaces to control VCV Rack, I have collected a few issues that I believe, if resolved, may help the usability of the program (which I provide out of a growing infatuation with the functionality OSC/Pilot provides):

  1. Dials can be difficult to use. As it is now, you have to touch the actual value slider in order to be able to manipulate the parameter. On larger sized dials, this isn’t really a problem - however, with smaller screens (I’m using a 12"), controls need to be packed tightly at times.
    Possible solution 1: Enable the ability to “grab” the dial slider from anywhere inside the outer-most part of the dial, like the center (using the dial’s X-axis to determine what value to begin with, followed by the normal operation). As far as I can see, the only reason this wouldn’t be the preferred functionality would be for placement of buttons inside the dial’s center - which is remedied by the fact that we have layers, and can move a button on top of the dial to defeat the dial activating when touched in the center. Possible solution 2: Add an option for dial functionality to switch between circular (as it is now) and linear (vertical) input (however, I imagine this would require that the previous possible solution be implemented first)

  2. Edit mode is quirky at times. So many times I’ve accidentally moved things on the page that need not be moved - especially when they’re elements like text, lines, boxes, images, etc. - which adds a lot of time and frustration to the process of setting up multiple workspaces full of controls. Possible Solution: Add option in context menu to lock items in the workspace from being moved, while still being able to select those locked items and change their settings. (Note: this may also need to deactivate locked items from selection when using an area selection, like tapping and dragging to select multiple controls)

  3. It’s possible - if not probable - that one may accidentally open edit mode while performing and move a control from its intended position (again, smaller screen here). Possible Solution: Add a “Lock all parameters” option to the controls at the top of the screen to avoid performance mishaps for those of us plebs with small screens.

  4. Exiting from edit mode is too easy. In order to hide the workspace select and context menu when positioning items at the bottom of the screen, one must tap on an empty space. If the space tapped is in something like the bottom third of the screen, that tap is interpreted as swiping up to exit Edit mode. This adds about 4 extra steps for every parameter at the bottom of the screen EVERY time it needs to be adjusted (Select item at bottom of screen->tap off to hide menu->tap registers as exiting edit->swipe down to re-enter Edit->move/rescale control) This isn’t a problem with entering Edit mode. It can take a few tries to enter Edit mode, WHICH IS GOOD so as to avoid accidentally doing so. Possible solution: Reduce the window being interpreted as a swipe up OR make it so that one must SWIPE up, instead of just being able to tap in the lower portion.

I think that’s all I have for now. I hope there’s helpful information in that and anything I can do to assist the process would be gladly undertaken. Ya’ll got something good here!

Cheers!
-juandale

2

Thanks for taking the time to post these suggestions. I’ll look into adding some locking controls in the next build. I’ll also look into the exiting of edit mode issue.
For your knob suggestion, can you elaborate a bit more? Are you thinking it behaves as a horizontal slider but with an extended range, similar to the way knobs work in a lot of other UIs that are mouse controlled?

1 Like
3

I appreciate you reading and considering them!

I was envisioning it behaving essentially almost exactly as it currently does, except that input will be “detected” while touching inside the inner part of the control, rather than ONLY when touching exactly over the slider. My suggestion about the X-axis bit was only to propose how to find a value to output when input is received in the “center, or inside” of the control.

Hope that helps, you’re very much appreciated, Sir!

4

But honestly, to touch on your question about the fader UI used for mouse control, that’s also a good option, only consideration being that I prefer the vertical fader action in those instances, but maybe others would use and appreciate the dial being switchable from circular action, to either vertical or horizontal fader action.

5

I’ve tried to address points #3 and #4 in the build I just posted. Let me know what you think:

1 Like