The trick is to map the knob to a specific range, and then set the knob in the patch to somewhere outside that range.
Some more minor glitches when I started up the module just now — it didn’t freeze like it did last time, but:
(1) it was playing a different patch from the one I had open when I shut it off. (I am 99.9% certain this is not confusion on my end.)
(2) I had previously set all the plugins to autoload, and that setting had disappeared so none of them autoloaded.
(3) The catchup mode preference reverted to “Track when knob moves” again.
Ah, ok! So what I’m seeing is this, when I’m in Track on Equal mode:
I create a knob mapping and set the min to 50%.
I turn the virtual knob to 0% manually (or by using a second knobset)
I go to the main knob set, which has the 50/100% min/max limit, and I can’t pick the knob up since it’s at 0 but I set a minimum of 50.
To get out of it, I can go back to whatever I did to get into this situation in step 2, and move it manually or with another knobset into a valid range.
I thought about this exact situation a lot while making Pickup modes. To indicate that this is what’s happening, I have a black square drawn on the knob in Knob set view (it’s not pretty and the GUI can be improved, but at least it’s a signal that the knob cannot be “picked up” due to the the mapping having limited the range).
This is something that’s a natural consequence of having these three features: 1) min/max ranges for mappings, 2) the ability to move a knob outside of those min/max ranges manually or using multiple mappings, and 3) pickup modes.
If anyone has ideas for how it could be done better, I’m all ears. But essentially when you set a knobset range you are saying “This knob should not go below 50%”, and when you enable Track on Equal mode, then you’re saying “The knobs should never jump values”. And then if you manually turn the knob below 50%, it’s kind of a contradiction – the only only way to resolve it is to either change the min/max range, or manually adjust the knob back into a valid range, or violate the “never jump values” rule.
As for the other glitches, they all sound like the settings file is not loading or saving. This has been reported by others, too. I have’t gotten it to happen to me, but I’m still looking…
Ok, I think I found the settings file error. I had a limit set to 1024Bytes and the file can exceed that with the right combination of settings.
I’ll push a fix!
I think by “manually” you mean by using the Adjust button and the encoder, right?
Seems like I did encounter a bug the first time, then, because the Adjust button didn’t change the knob position, which I believe should never be the case.
One problem is that “whatever I did to get into this situation in step 2” could mean “set the knob outside the mapped range when I created the patch in VCV Rack,” which isn’t something I can go back and undo (although I can in theory fix it using the Adjust button).
I agree this is a tricky design problem. My personal feeling is:
– not being able to move the virtual knob with the mapped knob feels like the module is broken, even when it’s actually the logical outcome of the intersection of the known rules.
– “the module should not feel broken” should also be a rule, and it should have higher priority than some of the other rules.
– so I think there should be cases where the module breaks the “knobs should never jump values in Track on Equal mode” rule to avoid that feeling of brokenness. In practice that probably means either jumping values or ramping up from the virtual knob position to the bottom of the range.
Ok, I think I found the settings file error. I had a limit set to 1024Bytes and the file can exceed that with the right combination of settings.
I’ll push a fix!
as you say, I think this is a natural consequence of users setting contradictory rules - personally, I see this as their ‘look out’.
if you set a knob range for 50-100%, you cannot set it below that, by whatever means - and then expect to be able to pick it up with a control you’ve set for min 50%.
I think the way to design around this would be to have the limits placed on the actual parameter NOT the input mechanism.
this would mean its always consistent however it gets modified.
however, I recognise, thats likely a pretty big upheaval in design, so Im not suggesting this is done
I guess… you could use the min/max value as pickup for any value below/above.
but I really don’t like these kind of ‘hacks/workarounds’ as they almost always lead to inconsistencies and in turn unwanted side effects.
also, the main reason to have pickup is so that we don’t get jumps… so getting a jump from 0 to 50% is not good, even if its due to our rules set.
so I like it as-is, if as a user I setup inconsistent rules, then it should work within those rules… perhaps thats actually what I want !
consistency is king for me… exceptions always make things more complicated.
even if thats at the expense of users having to understand what they are doing more
Oh… Yes, I forgot that detail. So, that was a different bug. Well, that might be from the corrupted settings file bug – if the tracking mode was unknown/invalid it might not track at all. I can test out what happens if in that case, maybe reproduce your original issue.
Definitely a confusing situation. Even more confusing I could imagine having a patch where the knob is mapped in two different knob sets with two non-overlapping ranges, and the physical value is in one range but out of the other. Which is not a problem in Track on Motion or Linear Fade modes, so it should be allowed.
And yeah, the Adjust button is always the escape hatch. It’s just might not be obvious.
Yeah, I agree with that rule. Though I wouldn’t be surprised if someone thought jumping the value when they set it to Track on Equal mode will also make it feel like a glitch. On the other other hand, at least it won’t appear to be stuck, and an infrequent value jump is probably the lesser of the evils.
That’s how I’d been seeing it. But maybe what’s missing is letting the user know what’s going on.
Some solution ideas:
Allow Track on Equal to jump if the knob is turned to the range min or max and the param value is out of range. Maybe have a checkbox in the Prefs to disable this if a user really wants to never have a value jump even if it means being stuck. It also could show a notification if this is done “Param jumped to a value in the mapping range. This can be disabled in Settings > Prefs”.
The MetaModule Hub could warn if a knob is not in the mapping range of any knob set(s) before saving the patch file. A user could then quickly fix it and re-save/re-transmit. Not a full solution since there are other ways to get stuck, but those other ways are harder to do and can be undone on-module.
When opening a patch while in Track on Equal mode (or switching to Track on Equal while the patch is running) the MM could display a pop-up warning you that “Fundamental:Mix Volume is set to 25% but the mapping range is 50%-100% in Knob Set 1, so the knob cannot be moved. Do you want to set Volume to 50%?”[Yes][No]. And if you click [No] then it tells you “Use the Adjust button to manually move the knob between 50% and 100%, or change the min/max mapping range” [OK] [Don’t show again]. This wouldn’t work if you had mappings in multiple knob sets with non-overlapping ranges.
A better visual display: instead of how I drew it as a black square, it could be a flashing red X or yellow /!\ or something obvious that draws the users attention that there’s a problem. Clicking on this in the KnobSet view opens a confirmation dialog box “The knob is out of range. Ok to jump the value in range?” [Jump] [Cancel]
Turning a knob that’s out of range will show a notification at the top “Warning: turning this knob has no effect because the parameter value is out of range. Change the mapping Min/Max or use the Adjust button”.
Yeah that’s another solution:
min/max is global, not per-knobset, and Adjust respects the min/max range. Downside of that is that it limits the possibilities even for users that don’t use Track on Equal.
Or a softer version:
Display a warning when opening a patch (or adding/changing any mappings) if there are mappings to the same param in multiple knob sets with different ranges. Also display a warning if the user uses Adjust to move the parameter out of range. These warnings only appear if you are in Track on Equal mode. Something like “Warning: adjusting Mix Volume in Knob Set 1 might make it impossible to control the param in Knob Set 2, and vice-versa. Please adjust the min/max range for the mappings or disable Track on Equal mode to fix this”.
yeah, when I mention inconsistencies … thats partly as I assume there are multiple ways to get into this situation…
e.g.
preset saved value
adjust value directly
another knob (on a different page)
midi mapping (?)
these all have to ‘sing from the same song sheet’ to make sense.
one idea which may help a bit, is more user feedback on how to get to the pickup value.
on the Access Virus when using catchup, when you move a pot, it tells you on the display in which direction ( a little arrow) you have to rotate to hit the pick up value.
e.g. anti clockwise if the pickup is lower than current pot.
if you did this, then at zero the display would tell you that you still need to continue to rotate anti-clockwise, but you know this is impossible - and so will know you have hit the MIN on that control. (opposite for max)
what Id like about this is, its very useful to know which way the pickup value is, so its a generally useful feature, rather than something coded for a quite specific use-case. (imo)
@danngreen More on the bug where the Adjust button doesn’t move a knob. I’'m using the dev-6 firmware.
I loaded up the very cool 4ms Drum Glitch Effect patch that your colleague posted here.
I connected the input and output and played a drum loop but didn’t hear anything, so I tried wiggling the knobs in the knob set. I found that wiggling physical knob F, which is mapped to the Address knob on the Switch 8-to-1 module, had no effect on the virtual knob. So I selected that virtual knob and tried to change it using the Adjust knob, but that had no effect either.
(Seems unlikely that this matters but: When I first loaded the Drum Glitch Effect patch, I didn’t have the Count Modula plugin loaded ((because of the preferences bug that’s preventing my plugins from autoloading)) so I got a warning that the Switch 8-to-1 was being omitted. I loaded the plugin and reloaded the patch, and then all the modules loaded fine.)
OK, thanks. I’ll tried doing this (including loading the patch without the plugin first) to figure this out. So far no luck. When Adjust wouldn’t move the knob, was the displayed numerical value changing in the Adjust pop-up (the number should from 0 to 10, in steps of 0.1)?
From now on, the beta firmware will keep the “-dev-X.X” version numbers in sync with the plugin versions. So dev-9.0 plugins are required for firmware dev-9.0 and vice-versa.
Thanks for bundling the plugins, that’s much more convenient. (And making it easy to upgrade is important when you’re releasing updates at such a rapid clip!) I loaded the new versions and messed around some and didn’t run into the knob-freezing bug, so maybe it’s fixed as a result of the increased preferences size.
Just not implemented yet. It’s a bit more tricky since a MIDI controller doesn’t have to send continuous values. Say the virtual knob is at 60 and the MIDI controller sends 20 and the sends 80. Should that be a “pickup” since the value crossed? Or should it still not track since that would make the virtual knob jump in value (from 60 to 80)? I think there was another uncertainty, too, I’m forgetting.
This was partially working dev-6, but now is much more complete.
For VCV-ported plugins, the MetaModule calls the rack::Widget::draw(), drawLayer(), and step() functions for all widgets that it doesn’t already know how to draw. Nanovg commands (nvgText, nvgStroke, etc) will be properly rendered (see limits)
TTF fonts can be loaded (if you’re developing a plugin, then just put the ttf file in the assets/ dir, and calls to window::LoadFont() will work)
Limits:
The back-end graphics lib we use (LVGL) has problems with filling convex polygons.
This is just a start of a feature, but it was necessary for me to have this so I could verify if some wide screens were being rendered correctly. I think this will tie into the “performance mode” feature.
Also only exciting for plugin developers, but this allows running tasks in the background without loading down the audio thread. I would expect the most common usage will be for accessing the SD Card or USB drive (and indeed the STSP depends on this to stream)
