not sure if this is related to some of the other knob issues. when system is set to 'track when equa’l, in this patch both A and B knobs (they are both mapped to buttons on the push module) will not pickup at all, therefore not trigger things in the patch.
8x sample loop player2.yml (19.2 KB)
This might have been fixed by v2.0-dev-12.5. There was a bug that knob mappings would go to 0.9999 instead of 1.
just installed 12.5 and tried out the patch. the issue is still occurring
Ok, I’m on 12.5 and I tried this out. The Push buttons have mapping min/max set to 0-50%. So “Track when Equal” won’t work because a button’s value flips between 0 and 1 (0 and 100%). So when the button is at 100%, the knob mapping can’t ever equal it because the mapping specifies only going to 50%.
I set the ranges to 0-100% and now I can track the buttons with knobs.
hmm so in vcv, the push module’s push button is mapped to 50.1 - which, at least in vcv, allows a trigger pulse to occur when the knob is barely turned from >0. is that .1% not translating into mm somehow? maybe there’s a different threshold mm would prefer, such as .2% or higher?
The 50.1% should get translated fine, though it willl just show up as 50% on the Edit Mapping page.
Interestingly if I set it to 100% and then get the knob to “pickup”, then I can set it back to 51% and it’ll keep tracking. I’m not totally sure why that is – it should see the button value at 100% and then fail to pickup when you go to 51%. I’ll step through the code and see why that is.
I looked through the code, and it’s behaving as I programmed it to do (at least with the Push button in this patch).
This came up at least once before (starting here-ish: Development firmware v2.0-dev - #62 by danngreen). In that discussion there was no solid conclusion but perhaps just that we need to pop up a display telling the user what’s happening. But maybe it needs to work differently? Here’s how it works now:
A mapped knob is always in one of two states: Tracking or Catchup.
When it’s Tracking, then any time a panel knob moves, first we request that the module tell us the current value of its virtual knob. We compare this to the last known virtual knob value. If it’s different, then we know the module moved its own knob and so we enter Catchup mode. Otherwise, we stay in Tracking mode and send the the panel knob value (scaled by the min/max mapping values) to the module. After sending this value, we read back the virtual knob value and store that for the next time.
When it’s in Catchup mode, whenever a panel knob moves we read the virtual knob value from the module. We then scale the panel knob value by the min/max mapping values, and compare this to the value read from the module. If they’re approximately equal, then we enter Tracking mode. Otherwise we do nothing.
I played around a bit tonight and just for fun implemented a little “escape hatch” that checks if the mapped value is out of the min/max range. Then if you move the physical knob to 0% or 100% (depending if the virtual knob value is > or < both the min and max), it will enter Catchup mode. It seems to work for the Push button, but as discussed in the thread above, it might be confusing in other patches to have a knob jump values like that when in Track on Equal mode
I do have one more suggestion. It seems that in this patch the Push button doesn’t need to be in Track on Equal mode, it’s just that other knobs do. What if it allowed you to set the Tracking/Catchup method for each mapping individually? It could be done simply by keeping the same UI (Prefs menu) that sets the default mode, but in the Edit Mapping page there would be a dropdown to let you override the default and force a mapping to be a particular method. So in this case, the Push button mapping would be Track on Motion (and then it would toggle at any value > 0, which is what you want). The other knob mapped to the same panel knob could keep using the Track on Equal method, it could be that granular of a choice. I actually made the catchup mode system be per-mapping but never implemented any kind of UI to change them in any but globally.
Per-mapping modes could be useful for power users. It’s a lot to ask for the average user to process, though. So:
— it’s still worth looking at situations where you might was to display a helpful popup;
— consider implementing a “Button Mode” that the Meta Module assigns automatically whenever a hardware knob is assigned to a software button, regardless of the global setting.
this sounds pretty awesome, especially for any cases like what i have going on where we need a button and knobs mapped to the same mm knob. im curious, is this something that might be able to be set within the right click context menu in vcv?
certainly couldnt hurt imo. im finding the popups we have in mm thus far are quite useful ux
I think some kind of Button Mode for a mapping is a good idea. There’s no clear definition of “button” but at least it could make a good guess when you create a mapping, and it would be right most of the time.
If a mapping was a “Button mapping”, then we’d have a different set of rules for the mapping, maybe just forcing the mapping to always be in range (since it makes no sense to have a mapped button but be unable to change the button state).
I’ll work on getting a notification happening, it seems we’d need that no matter what for some edge cases.
Nice. Ideally the API would let a module specify whether a control should default to Button Mode, although in the absence of a value the MM might still have to guess.
I just implemented a quick solution that adds a user option to the preferences pane:
When checked (default), moving the panel knob to the closest position to the out-of-range parameter will automatically “pickup” the param and start tracking it. So this works with the Push patch, probably how it was intended to work (and I tested for inverted and non-inverted Min/Max values).
When not checked (no jumping), a notification pops up when you move the knob to the farthest extreme (100% or 0%, whichever is closer to the param). The notification could get annoying if somehow you really want it to behave this way, so I’m considering a third option for “Do not allow jumping but don’t notify”… Or we could notify just once until you open the patch again. Though, if someone doesn’t read and fully comprehend the notice it won’t be clear how to get it to show up again.
Any feedback on this is welcome, I’m calling it “v2.0.0-dev-12.10-rc1” because I’m not sure this is the right direction or not.
just tried this out and it seems to be working great with my button/knob dual mapping. ty!
im curious what kind of cases there would be where users would want to map a knob and button but not want the button to be able to work with track when equal (i can’t think of any). the notification was intensely repetitive but i would think, better to have it there so users would fix the issue or they just turn on 'allow jumping out of range params"?
Probably not with normal buttons, but there are some quasi-buttons and various things that don’t fit into boxes. For example the “buttons” in Bogaudio Matrix1616 are on/off and also can be set to a value like a knob.
Also this feature applies to any parameter, knobs included. It’s totally possible (and easy) to make a multi-map where one mapping is out of range, especially with multiple knob sets it could get confusing.
I still like the idea of having a default catchup mode type for buttons (or params that MM makes a guess are probably a buttons).
There’s also the button expander coming which brings up new mapping types (Button to knob, button to button, plus various modes like trig or toggle…) and I want to make sure the whole picture is cohesive. So still a few more things to figure out
upon further investigation of the new ‘allow jumping out of range param’ feature, im noticing that if you start the patch with the mm physical knobs at 0 (and the default of whatever those are mapped to in the patch is 0 at startup), you will need to first turn the knob >0 and then back down to zero for it to catch. one would expect the jump to occur right when you turn the knob, instead of having to initially turn it up then down, then turn it up again for it to work. im curious is this intended behavior?
quick test patch demonstrating (u knob)
- param jump quick test.yml (2.2 KB)
I see… I think it just needs to be allowed to jump an out-of-range parameter when the knobset or patch is first loaded (instead of only when the panel knob is moved)
I just fixed it, seems to work now with that patch.
It’s in this release:
https://github.com/4ms/metamodule/releases/download/firmware-v2.0.0-dev-12.13/metamodule-firmware-v2.0.0-dev-12.13-firmware-assets.zip
awesome, seems to be working ok w 12.13!
