Pitch value on startup

[gui-lux]

Bug Description

Hi,
I noticed v2.4 sometimes applies a wrong value on pitch sliders at startup.
This is rather minor because one pitch slider touch totally wipes the trouble and this could be related to my controller as previously discussed. On the other hand, v2.3.x didn't behave like this.

So, when starting v2.4 with my MC4000 from Denon with pitch sliders set on a value that is not zero, not min value, not max value, then mixxx displays a pitch value that looks multiplied by ten and more, and giving strange zoomed-in (in case of positive hardware pitch value) waveforms.
I can reproduce across shutdowns and power cut only, can't reproduce when only restarting mixxx, and not reproducing 100% with a simple reboot.

The following line from an lsusb output that relates my controller :
Bus 001 Device 005: ID 15e4:8001 Numark MC4000

From mixxx.log :

Debug [Controller] ControllerManager:slotInitialize
Debug [Controller] Extension .midi.xml total 3 mappings
Debug [Controller] Extension .hid.xml total 0 mappings
Debug [Controller] Extension .bulk.xml total 0 mappings
Debug [Main] Set root GL Context widget valid: WInitialGLWidget(0x558a9f3af0) false
Debug [Main] Displaying main window
Debug [Main] Running Mixxx
Debug [Main] OpenGL driver version string "2.1 Mesa 20.3.5", vendor "Broadcom", renderer "V3D 4.2"
Debug [Main] Supported OpenGL version: 2.1
Debug [Main] RLimit Cur  95
Debug [Main] RLimit Max  95
Debug [Main] ControllerManager::getControllerList
Info [Main] Loaded skin "Deere"
Warning [Main] Unsupported locale "cmn"
Debug [Controller] Extension .midi.xml total 129 mappings
Debug [Controller] Extension .hid.xml total 15 mappings
Debug [Controller] Extension .bulk.xml total 1 mappings
Debug [Controller] ControllerManager: Setting up devices
Debug [Controller] Scanning PortMIDI devices:
Debug [Controller]  Found output device # 2 MC4000 MIDI 1
Debug [Controller]  Found input device # 3 MC4000 MIDI 1
Debug [Controller]     Linking to output device # 2 "MC4000 MIDI 1"
Debug [Controller] Scanning USB Bulk devices:
Info [Controller] Scanning USB HID devices
Info [Controller] Excluding HID device { 2575:0001 r3100 | Usage: 000d:0004 | Interface: #0 | Manufacturer: Weida Hi-Tech | Product: CoolTouch® System }
Info [Controller] Duplicate HID device, excluding { 2575:0001 r3100 | Usage: 000d:0022 | Interface: #0 | Manufacturer: Weida Hi-Tech | Product: CoolTouch® System }
Info [Controller] Duplicate HID device, excluding { 2575:0001 r3100 | Usage: 000d:0022 | Interface: #0 | Manufacturer: Weida Hi-Tech | Product: CoolTouch® System }
Info [Controller] Duplicate HID device, excluding { 2575:0001 r3100 | Usage: 000d:0022 | Interface: #0 | Manufacturer: Weida Hi-Tech | Product: CoolTouch® System }
Info [Controller] Duplicate HID device, excluding { 2575:0001 r3100 | Usage: 000d:0022 | Interface: #0 | Manufacturer: Weida Hi-Tech | Product: CoolTouch® System }
Info [Controller] Duplicate HID device, excluding { 2575:0001 r3100 | Usage: 000d:0022 | Interface: #0 | Manufacturer: Weida Hi-Tech | Product: CoolTouch® System }
Info [Controller] Duplicate HID device, excluding { 2575:0001 r3100 | Usage: 000d:0022 | Interface: #0 | Manufacturer: Weida Hi-Tech | Product: CoolTouch® System }
Info [Controller] Duplicate HID device, excluding { 2575:0001 r3100 | Usage: 000d:0022 | Interface: #0 | Manufacturer: Weida Hi-Tech | Product: CoolTouch® System }
Info [Controller] Duplicate HID device, excluding { 2575:0001 r3100 | Usage: 000d:0022 | Interface: #0 | Manufacturer: Weida Hi-Tech | Product: CoolTouch® System }
Info [Controller] Duplicate HID device, excluding { 2575:0001 r3100 | Usage: 000d:0022 | Interface: #0 | Manufacturer: Weida Hi-Tech | Product: CoolTouch® System }
Info [Controller] Duplicate HID device, excluding { 2575:0001 r3100 | Usage: 000d:0022 | Interface: #0 | Manufacturer: Weida Hi-Tech | Product: CoolTouch® System }
Info [Controller] Excluding HID device { 248a:8266 r0 | Usage: 0001:0006 | Product: i4 | S/N: 72:02:f6:00:13:0b }
Info [Controller] Duplicate HID device, excluding { 248a:8266 r0 | Usage: 000c:0001 | Product: i4 | S/N: 72:02:f6:00:13:0b }
Info [Controller] Duplicate HID device, excluding { 248a:8266 r0 | Usage: 0001:0002 | Product: i4 | S/N: 72:02:f6:00:13:0b }
Info [Controller] Duplicate HID device, excluding { 248a:8266 r0 | Usage: 0001:0001 | Product: i4 | S/N: 72:02:f6:00:13:0b }
Debug [Controller] ControllerManager::getControllerList
Debug [Controller] Searching for controller mapping "/home/dietpi/.mixxx/controllers/Denon MC4000303909.midi.xml" in paths: "/home/dietpi/.mixxx/controllers/,/usr/local/share/mixxx/controllers/"
Debug [Controller] Loading controller mapping from "/home/dietpi/.mixxx/controllers/Denon MC4000303909.midi.xml"

• This "MC4000303909.midi.xml" is due to a little bit of customization of the shipped mapping, like adding ffwd and rewind in place of unused pitchbend buttons, with the help of the midi learn functions.
• This "Weida Hi-Tech | Product: CoolTouch® System" is the touchscreen part of an 15.6 HDMI touchscreen.
• This "Product: i4 | S/N: 72:02:f6:00:13:0b" is a bluetooth keyboard.
• Not sure I'm doing the right thing with those HID devices.

Thanks dev team

Version

2.4

OS

DietPiOS (debian bullseye based)

[Swiftb0y]

Can you reproduce the issue when you disable the controller? I want to make sure its not the controller mapping's fault.

[gui-lux]

Not reproducing when my controller is unchecked in the prefs.

[Swiftb0y]

So looks like its related to your controller mapping. Thats not possible for me to debug without access to the hardware. Are you comfortable with Javascript?

[Swiftb0y]

actually just double checking, there might be another issue. In the mapping XML, can you comment out the <control>s that have <key>rate</key> and <options> <fourteen-bit-lsb/> </options> set and see if the issue still occurs?

[gui-lux]

Followed your instructions and pitch displays 0 while hardware sliders do not respond.
Should I try with only <fourteen-bit-lsb/> commented out ?

Javascript?

On a scale from 1 to 5, I would say zero :D More seriously, the best I can do is copy-paste some lines.

[Swiftb0y]

On a scale from 1 to 5, I would say zero :D More seriously, the best I can do is copy-paste some lines.

Mhmm okay, can you apply git patches? That would be less error-prone than copy-pasting stuff.

Followed your instructions and pitch displays 0 while hardware sliders do not respond.
Should I try with only commented out ?

Ahh right, you'll probably have to change the rate mappings that contain <fourteen-bit-msb/> to <normal>. The result should be that the fader continue to work, they're just lower-resolution.

diff --git a/res/controllers/Denon MC4000.midi.xml b/res/controllers/Denon MC4000.midi.xml
index 3ddd8b174a..343ae48a56 100644
--- a/res/controllers/Denon MC4000.midi.xml	
+++ b/res/controllers/Denon MC4000.midi.xml	
@@ -1163,7 +1163,7 @@
                 </options>
             </control>
             <!-- Pitch fader LSB (14-bit value sent across 2 messages) -->
-            <control>
+            <!-- <control>
                 <group>[Channel1]</group>
                 <key>rate</key>
                 <status>0xB0</status>
@@ -1180,7 +1180,7 @@
                 <options>
                     <fourteen-bit-lsb/>
                 </options>
-            </control>
+            </control> -->
             <!-- Pitch fader MSB (14-bit value sent across 2 messages) -->
             <control>
                 <group>[Channel1]</group>
@@ -1188,7 +1188,8 @@
                 <status>0xB0</status>
                 <midino>0x09</midino>
                 <options>
-                    <fourteen-bit-msb/>
+                    <!-- <fourteen-bit-msb/> -->
+                    <normal/>
                 </options>
             </control>
             <control>
@@ -1197,7 +1198,8 @@
                 <status>0xB1</status>
                 <midino>0x09</midino>
                 <options>
-                    <fourteen-bit-msb/>
+                    <!-- <fourteen-bit-msb/> -->
+                    <normal/>
                 </options>
             </control>
         </controls>

[gui-lux]

Hi,
sorry for the lag.
Didn't know how to proceed with the diff command so I did it by hand on the stock mapping.
I confirm the lower resolution with pitch faders.

Still reproducing after a reboot.

[Swiftb0y]

Mhmm thats weird. What values does the controller send on startup? Can you start mixxx with --controllerDebug and share the log from a run where the wrong value is applied? There should be a bunch of lines starting with incoming: that shows what the controller is sending.

[gui-lux]

Debug [Controller] "outgoing: " "MC4000 MIDI 1:  status 0x91 (ch 2, opcode 0x9), ctrl 0x02, val 0x00"
Debug [Controller] sending MIDI bytes: 149 , 21 , 0
Debug [Controller] "outgoing: " "MC4000 MIDI 1:  status 0x95 (ch 6, opcode 0x9), ctrl 0x15, val 0x00"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:30 ms status 0x9F (ch 16, opcode 0x9), ctrl 0x1C, val 0x00"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:31 ms status 0xB1 (ch 2, opcode 0xB), ctrl 0x19, val 0x40"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:33 ms status 0xB0 (ch 1, opcode 0xB), ctrl 0x19, val 0x40"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:34 ms status 0xBF (ch 16, opcode 0xB), ctrl 0x08, val 0x7F"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:35 ms status 0xB1 (ch 2, opcode 0xB), ctrl 0x16, val 0x3D"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:36 ms status 0xB0 (ch 1, opcode 0xB), ctrl 0x16, val 0x3E"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:37 ms status 0xB8 (ch 9, opcode 0xB), ctrl 0x02, val 0x40"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:39 ms status 0xB9 (ch 10, opcode 0xB), ctrl 0x02, val 0x2C"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:40 ms status 0xBF (ch 16, opcode 0xB), ctrl 0x1A, val 0x00"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:43 ms status 0xB0 (ch 1, opcode 0xB), ctrl 0x1C, val 0x7F"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:44 ms status 0xB1 (ch 2, opcode 0xB), ctrl 0x1C, val 0x00"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:45 ms status 0xBF (ch 16, opcode 0xB), ctrl 0x0C, val 0x09"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:47 ms status 0xBF (ch 16, opcode 0xB), ctrl 0x0D, val 0x00"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:48 ms status 0xB9 (ch 10, opcode 0xB), ctrl 0x00, val 0x7F"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:50 ms status 0xB8 (ch 9, opcode 0xB), ctrl 0x00, val 0x42"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:51 ms status 0xB1 (ch 2, opcode 0xB), ctrl 0x18, val 0x40"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:53 ms status 0xB0 (ch 1, opcode 0xB), ctrl 0x18, val 0x40"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:54 ms status 0xB0 (ch 1, opcode 0xB), ctrl 0x1A, val 0x40"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:56 ms status 0xB1 (ch 2, opcode 0xB), ctrl 0x1A, val 0x40"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:57 ms status 0xB1 (ch 2, opcode 0xB), ctrl 0x17, val 0x40"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:59 ms status 0xB0 (ch 1, opcode 0xB), ctrl 0x17, val 0x40"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:60 ms status 0xB8 (ch 9, opcode 0xB), ctrl 0x01, val 0x51"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:62 ms status 0xB9 (ch 10, opcode 0xB), ctrl 0x01, val 0x27"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:63 ms status 0xB0 (ch 1, opcode 0xB), ctrl 0x09, val 0x29"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:64 ms status 0xB0 (ch 1, opcode 0xB), ctrl 0x29, val 0x76"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:66 ms status 0xB1 (ch 2, opcode 0xB), ctrl 0x09, val 0x35"
Debug [Controller] "incoming: " "MC4000 MIDI 1: t:67 ms status 0xB1 (ch 2, opcode 0xB), ctrl 0x29, val 0x17"
Info [Main] Loaded skin "Deere"
Info [Main] Enabling ALSA real-time scheduling

I did another test afterwards :

• set pitch fader A at +5.00, +3.00 for pitch fader B.
• quit mixxx normally, reboot, restart controller
• start mixxx and read pitch values : pitch A = +63.10, pitch B = +37.62
• that's weird indeed

[Swiftb0y]

Okay, I have no idea why this is wrong. Can you share your customized version of the mapping so I can double check whether your changes might have introduced issues?

[gui-lux]

Sure, I'm experimenting the same issue with both custom and stock mapping.
Custom mapping :
Denon MC4000303909.midi.xml.txt

[gui-lux]

I forgot to say something about mapping and tuning, so I will test again but explain first.

There is an js file shipped with the mapping named Denon-MC4000-scripts.js
I always retune the sensitivity parameter in this file after every mixxx build as follows :

// Sensitivity of the jog wheel (NOTE: sensitivity depends on audio latency)
MC4000.jogParams = {
    sensitivity: 7,
    maxJogValue: 3

The default value for sensitivity is 25 and far too much responsive for me, explaining my custom value.

[gui-lux]

Hi,
still reproducing after a fresh clone/build with this Denon-MC4000-scripts.js fully reset.

[Swiftb0y]

Yeah, this is probably an issue within mixxx, not sure when anybody will get around to looking into this, its likely not easy.

[Swiftb0y]

Hey @gui-lux, I think I found the culprit, could you apply the changes in #13463 and see if that fixes it for you?

[gui-lux]

Hi @Swiftb0y ,
needs to be checked few more times but I'm afraid I'm not reproducing this anymore.
This bug happened while I was running v2.4 beta, I'm running v2.4.0 stable release now and to me everything's fine.
I'll take care to check with v2.4.1 right away.

[gui-lux]

v2.4.1 build, lift-off and no glitch from the pitch. Tried with power cut as well because I used to have more chance to reproduce like this.
Maybe good for closing ?
Thanks for the follow-up anyway !

[Swiftb0y]

I haven't been able to reproduce this issue either in a long-time (probably because its because of some race on startup), but the original issue with the wrong slider value is still there I'm fairly confident. Thanks for testing anyways. I'll close when #13463 is merged.