change MIDI switch and button option behavior?
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Mixxx |
Won't Fix
|
Low
|
Unassigned | ||
Bug Description
Previously: Bug #Bug #995652
I'd like to re-visit what it means to set the "button" and "switch" MIDI options. What are they for?
The behavior of the "switch" MIDI option in master is:
1) Change opcode to MIDI_NOTE_ON
2) Change value to 1.
The behavior of the "button" MIDI option in master is:
1) Change opcode to MIDI_NOTE_ON
2) Change value to 1 if value != 0, 0 otherwise.
Notes:
1) ControlPushButton interprets NOTE_OFF or value 0 messages as releases. All other messages (regardless of value) are presses. (So step 2 of "button" above does not matter as only 0 values are counted as releases). This means that nanoKontrol discussed in Bug #995652 should no longer need <switch> options.
2) Connecting a switch or button MIDI option control to a ControlPotmeter (or derivative) is useless. Once the MIDI value is converted to parameter space, the value will be 1/128.0 or 0. So that's not relevant here.
3) ControlObject interprets the value directly. Switch mappings will set a CO to 1 no matter what (useless). Button mappings will set a CO to 1 or 0.
When the Switch MIDI option is used on a physical switch (a physical MIDI switch control that only sends one message per change (0x7F for on, 0x00 for off) rather than a push-button that sends a NOTE_ON followed by NOTE_OFF when released) every toggle results in ControlPushButt
This is not quite right. A (NOTE_ON, 1) set will cause:
1) a toggle pushbutton to toggle its state by 1.
2) a power window button is continuously pressed and never released (this just toggles the state back and forth)
3) a longpresslatching button is continuously pressed and never released (same result as a toggle button)
4) a push button is continuously pressed and never released
Since the MIDI switch has a physical setting (on and off), I think we should not interpret these as a button press. Instead, we should directly set the value of the CO to the value of the switch (1 for on and 0 for off).
The way it is today, the switch can get out of sync with the CO. If I turn keylock on with the switch then turn it off with the mouse, once I toggle the switch again keylock will toggle once more but it will be on while the MIDI switch is off.
Similarly, if I take a 0/1 toggle switch MIDI control and bind it to "hotcue_X_activate" with the <button> MIDI option:
* Toggling the switch to on sets the hotcue_X_activate to 1 (which starts previewing from the hotcue).
* Toggling the switch to off sets hotcue_X_activate to 0 (which ends previewing).
If you never turn the switch off then the deck is stuck previewing and users get into states like Bug #1026724.
So the goal of the button option -- to make the switch act like a button -- fails in that case.
So, I propose:
* The MIDI switch option is for mapping a switch that has an on and off state that is managed by the MIDI controller or is a physical switch.
* The MIDI button option is for making Mixxx interpret a switch that has an on and off state that is managed by the MIDI controller or is a physical switch as a button with no press/release duration.
To accomplish this:
The switch MIDI option does the following:
1) Set the control to 1 if the value is greater than 0 and 0 otherwise.
The button MIDI option does the following:
1) Issue a (MIDI_NOTE_ON, 1) set immediately followed by a (MIDI_NOTE_OFF, 0) set to the CO.
The end goal of the switch MIDI option is to take a message and interpret it as a 0/1 toggle state set.
The end goal of the button MIDI option is to take a message and make it interpreted as a push button press and release.
Letting a switch be interpreted as a single NOTE_ON (as <button> does today) is asking for trouble if bound to something that really needs a release event.
Finally, what about MIDI toggle switches with more than 2 states? I have a 3-state toggle on my VCI-400 except each of the 3 settings is an individual 0/1 toggle switch. So switching from state 1 to state 2 issues a 0 message for state 1 and a 1 message for state 2. So at least Vestax has opted to compose 2-state toggle switches to make an N-state toggle switch. Has anyone seen a controller that models a multi-state toggle as a single control? If they just set the MIDI value to the toggle # then my proposal for <switch> behavior will work for those too (as long as the # of toggle states s <= the CO's number of toggle states).
| Changed in mixxx: | |
| milestone: | none → 1.12.0 |
| importance: | Undecided → Low |
| tags: | added: midi |
| Owen Williams (ywwg) wrote | #1 |
| Owen Williams (ywwg) wrote | #2 |
| RJ Skerry-Ryan (rryan) wrote | #3 |
| Owen Williams (ywwg) wrote | #4 |
| Owen Williams (ywwg) wrote | #5 |
| Daniel Schürmann (daschuer) wrote | #6 |
| Changed in mixxx: | |
| status: | New → Won't Fix |
| Swiftb0y (swiftb0y) wrote | #7 |
| lock status: | Metadata changes locked and limited to project staff |
I'm pretty sure we have to keep the switch code permanently:
* In "momentary" mode, the nanokontrol fires 0x7F on push down, and 0x00 on lift up.
* In "toggle" mode, it fires 0x7F on the first push, and fires nothing on lift up. The button stays lit. With the second push, it fires 0x00 on lift up.
if I use a momentary button on a toggle PushButton, I don't want both messages to fire or else the button will never stay on. I might do this for powerwindow toggles where I can't change the nanokontrol lights -- better to let the state only be reflected in the UI. So I'd prefer to keep the code that only listens to 0x7F. But then, I might use a toggle for an actual toggle button, and then I do need to listen to 0x00 or else it takes another press to turn the state off, but then the light is on, etc etc.