Various quality-of-life issues

Feature Requests
1

This module is awesome and obviously reflects a ton of great design work. Here are a few quality-of-life requests that would sand down a few of the rough edges:

– When I switch to a new knob set (or a new patch), the hardware knobs are in the wrong positions. When I touch a hardware knob, the virtual knob jumps to wherever the hardware knob happens to be. It would be better if the virtual knob was unaffected until the hardware knob reaches the point that the virtual knob is set to. This feature is called “pickup mode” on some MIDI controllers; it would work really well on the Meta because the virtual knobs give such a clear visual indication of where the parameter is currently on the knob.

– When I save an unnamed patch on the Meta Module in VCV Rack, the patch file is saved with a name like “Unnamed31.” It would be better if the module used the filename by default instead, e.g. if I save an unnamed patch as RingsIntoClouds.yml, the hardware Meta Module should display the patch as “RingsIntoClouds” rather than “Unnamed35.” Here’s why: I often forget to give the patch a name, but when I go to save it, I’m confronted with a Save dialog, at which point I have to make up a name. Why not use that name?

– I think this has been mentioned before, but it would be much easier to track I/O assignments within a patch if the I/O names displayed in the Jacks view were user-configurable.

– When updating firmware, it would be helpful if the “Update Firmware” screen, the loading screen, and the success screen could display the version number of the new firmware. The fact that the firmware folder always has the same name regardless of version makes me itchy, and seeing it on the screen would be calming.

– Similarly, the module should display something other than a blank white screen on startup – it’s unsettling.

– Smallest imaginable request: It’d be neat if patch files had a bespoke file extension rather than .yml.

– A much bigger request, which may be ruled out by hardware limitations: I often want to normal the inputs on the Meta, e.g. create a patch where a signal patched to input 3 is automatically normaled to input 4 unless there’s a physical cable inserted into input 4. It would be great to add that feature down the road if the hardware allows.

3 Likes
2

Pickup mode for the knobs will be so helpful! It happens all the time that values jump to different points, and depending on the parameters, it can get pretty harsh. Things like FM depth, distortion amount and mixer levels are very unpleasant…

2 Likes
3

are you telling me there currently is no pickup mode?
that kind of makes knob sets completely useless…

if you use pots (rather than encoders) pickup mode is essential.

the only reason to have it optional, would be for the case, where you dont use knob sets AND you dont like pickup option.
I’ll admit pick mode is far from perfect… as you have to know where the ‘lock’ is, which tends to mean looking at a screen - which is not very ‘tactile friendly’

note: there is also another option for pots, a so called ‘relative pickup’
basically, the happens is unlike pickup which is locked until values match turning the pot moves towards the lock value immediately (hard to describe exactly)

anyway definitely pickup mode is a must

3 Likes
4

++1 for pickup mode! and or a “value scaling” type takeover mode (a la ableton)

5

Can I suggest for the smaller knobs, to use a lighter shade. For example dark green for the [F] and lighter green for [Z]. Helps differentiate a little more for quality of life improvement, at least for me.

1 Like
6

+++1 for pickup mode. Klavis Twin Waves handles this interaction with an LED that lights up once the pot crosses the set value and is “live”.

1 Like
7

+1 for relative pickup mode and +1 for lighter colour for the small pots along with a selectable screen layout as has already been picked up by @danngreen :slight_smile:

8

I’ve been lurking this thread, BTW!

I added Pickup mode to our list.

When I save an unnamed patch on the Meta Module in VCV Rack, the patch file is saved with a name like “Unnamed31.” It would be better if the module used the filename by default instead, e.g. if I save an unnamed patch as RingsIntoClouds.yml, the hardware Meta Module should display the patch as “RingsIntoClouds” rather than “Unnamed35.” Here’s why: I often forget to give the patch a name, but when I go to save it, I’m confronted with a Save dialog, at which point I have to make up a name. Why not use that name?

Oh, I see, creating a file name for the yml file in VCV should modify the patch name if it’s not yet named. Yeah we can that. It already does the reverse direction in VCV (if you make a patch name, then it will default the filename to the patch name, minus special characters). And it does the same thing when you save from within the MetaModule: if you save a new patch and the Patch Name begins with “Untitled Patch” then whatever file name you pick is assigned to the Patch Name as well (and vice-versa).

Patch Name vs. Filename is a point of confusion though, and I have an open issue for it. Patch Name is nice because you can use any characters, but keeping them in sync is not always intuitive. We may end up just having file names and the Patch Name can be shown only on the patch Info page (along with the description), more like a title for the description, than something you use to identify the patch. Still feeling this one out.

– I think this has been mentioned before, but it would be much easier to track I/O assignments within a patch if the I/O names displayed in the Jacks view were user-configurable.

Yes, it’s already part of the patch format, we just haven’t implemented setting it from VCV yet.

– When updating firmware, it would be helpful if the “Update Firmware” screen, the loading screen, and the success screen could display the version number of the new firmware. The fact that the firmware folder always has the same name regardless of version makes me itchy, and seeing it on the screen would be calming.

We have an open issue for improving the firmware updater UX. I think it’s wise to keep the folder name always the same so that there’s no chance someone puts two firmware updates on the same disk. But, it should tell you the version it found vs. the version currently installed and let you confirm the update. Also when the wifi module is released, it gets a lot more complex because the MetaModule updates the wifi module’s firmware.
You can open the metamodule.json file to see the version if you’re unsure.

– Similarly, the module should display something other than a blank white screen on startup – it’s unsettling.

Yeah, that’s be pretty. I suppose splash screens are pretty standard.

– Smallest imaginable request: It’d be neat if patch files had a bespoke file extension rather than .yml.

Well, I like that it’s obvious what the file format is, and they are totally human-editable (if you’re into that sort of thing). I intend to document the format a bit, but it’s fairly obvious if you are familiar with yaml or even json. On the other hand, the .mmplugin extension, however is just a tar ball, but I think it’s smart to obscure it in case someone double-clicks it and then has all these files, that they might try to load or install. Plugin files are not meant to be human-edited.
That’s just my reasoning… I could be convinced though! I did use .mmplugin for a little while.

A much bigger request, which may be ruled out by hardware limitations: I often want to normal the inputs on the Meta, e.g. create a patch where a signal patched to input 3 is automatically normaled to input 4 unless there’s a physical cable inserted into input 4. It would be great to add that feature down the road if the hardware allows.

No hardware limit here. More of a question of what interface/UI do we use to create these normalizations. There’s an open issue for dealing with normalled mapped inputs already, I can tack this on.

6 Likes
9

Thanks for considering all these requests!

– Smallest imaginable request: It’d be neat if patch files had a bespoke file extension rather than .yml.

Well, I like that it’s obvious what the file format is, and they are totally human-editable (if you’re into that sort of thing). I intend to document the format a bit, but it’s fairly obvious if you are familiar with yaml or even json. On the other hand, the .mmplugin extension, however is just a tar ball, but I think it’s smart to obscure it in case someone double-clicks it and then has all these files, that they might try to load or install. Plugin files are not meant to be human-edited.
That’s just my reasoning… I could be convinced though! I did use .mmplugin for a little while.

I take your point and would definitely not want to argue about something as trivial as this! You’re right that I might not have tried opening it in a text editor if it had been called .mmplugin.

A much bigger request, which may be ruled out by hardware limitations: I often want to normal the inputs on the Meta, e.g. create a patch where a signal patched to input 3 is automatically normaled to input 4 unless there’s a physical cable inserted into input 4. It would be great to add that feature down the road if the hardware allows.

No hardware limit here. More of a question of what interface/UI do we use to create these normalizations. There’s an open issue for dealing with normalled mapped inputs already, I can tack this on.

That’s awesome. I can see how it’s a UI challenge but I think it’d be worth adding.

10

On the topic of files it would be really great if it were possible to boot up the device in a disk mode, where you could just plug USB c cable from my computer right to the device for file transfer

11

Just an update, Catchup modes is merged into the v2.x branch. More info here:

5 Likes
12

Hooray! Thanks, Dan.

13

I think your post covered about 95% of what I’d also like to see. I really love this module, but it’s just a few smart tweaks away from being totally intuitive when using it.

I would only add the common gripe about the knob display, which I think could be more matched to the knobs. I’ve read the posts about how difficult it is to put them all across the screen, but I think that if the large knob icons were slightly vertically staggered (as they are on the panel) this could work.

I also don’t think The displayed letters for each of the knobs matter near as much as the colors. This might just be a me thing, But I think whatever custom text you write for it would be better suited to go inside vs below the colored icon for the knob. That would be way more intuitive. (Granted, as I’m thinking about it, this would potentially create a problem for the colorblind)

Anyway, great post, great thoughts.

1 Like