Description
Bug Description
Been using mixxx for a number of years with this setup and recently upgraded to 2.4
Upon launch an error message is raised stating:
The mapping for your controller "SCS.3d MIDI 1" is not working properly.
The script code needs to be fixed.
You can ignore this error for this session but you may experience erratic behavior.
Try to recover by resetting your controller.
details are:
Uncaught exception: :1: TypeError: Property 'incomingData' of object function StantonSCS3d() { [native ode] } is not a function
Backtrace: @:1
@:1
The Retry button loops on this error.
The Rgnore button allows mixxx to start and the controller seems to mostly work but is missing some features.
The expected behavior is no error and the controller working as it used to in previous mixxx version.
Version
2.4.0
OS
Linux (Manjaro)
Activity
sysdbugfactory commentedon Apr 19, 2024
I should add that the controller is a Stanton SCS.3d "DaScratch".
This is a certified mappings, so it is unexpected that it would raise an error.
Hopefully it's not a big issue but I do not grasp enough to be able to fix it myself.
daschuer commentedon Dec 2, 2024
Is this a duplicate of #13144?
Swiftb0y commentedon Dec 2, 2024
I don't think so. I think the hardware unexpectedly sends a sysex message which is automatically dispatched to
StantonSCS3d.incomingData
. That function however does not exist because the mapping doesn't expect to receive any SysEx data from the hardware. The easy fix would be to add a dummy implementation ofStantonSCS3d.incomingData
so engine doesn't complain. It doesn't explain why the controller sends that in the first place though.git-developer commentedon Feb 17, 2025
This is caused by a sysex command sent from
init()
requesting the firmware version. statusResponse() is the intended handler, configured in the XML file for status0xf0
.Maybe a status of
0xf0
in the XML was enough to route the message to the configured handler in 2.3, and this behavior changed from 2.4?Workaround is to add
after declaration of
StantonSCS3d.statusResponse
.git-developer commentedon Feb 17, 2025
Related: #11536, #12824
git-developer commentedon Feb 17, 2025
Problem was introduced with 2.4.0 (does not occur on 2.3.6 and below).
Swiftb0y commentedon Feb 17, 2025
Oh yeah. I missed that.
Yup. Do you want to open a PR?
git-developer commentedon Feb 17, 2025
I can do, but I'd like to understand better what's happening before. What I found out so far:
2.3.6
Lookup for an input function by key
[0xF0, 0xFF]
and function call:mixxx/src/controllers/midi/midicontroller.cpp
Line 472 in 691596c
mixxx/src/controllers/midi/midicontroller.cpp
Lines 490 to 493 in 691596c
2.5.0
Declaration of a function
incomingData()
and call of all (really? can't believe that) input functions:mixxx/src/controllers/scripting/legacy/controllerscriptenginelegacy.cpp
Lines 162 to 165 in 23a9c9a
mixxx/src/controllers/scripting/legacy/controllerscriptenginelegacy.cpp
Lines 208 to 210 in 23a9c9a
incomingData
to MIDI sysex mappings #14368git-developer commentedon Feb 18, 2025
I didn't find out yet where (and why) the difference is made between dispatching of data messages and sysex messages. Nonetheless a PR (draft for now) is open containing a quick fix.
Not sure if more fixes are required. MIDI SysEx has status byte
0xF0
. Some mappings use other system messages, all beginning with0xF
. Some of them are used in XML mappings:It might be that these messages are affected, too.
git-developer commentedon Feb 18, 2025
I found the missing puzzle pieces.
PortMidiController::poll
checks for SysEx (0xF0
status byte) and delegates to one of:mixxx/src/controllers/midi/midicontroller.cpp
Lines 249 to 252 in 88aa50e
mixxx/src/controllers/midi/midicontroller.cpp
Line 572 in 88aa50e
which in turn delegate to one of
mixxx/src/controllers/midi/midicontroller.cpp
Lines 298 to 302 in 88aa50e
mixxx/src/controllers/midi/midicontroller.cpp
Lines 602 to 604 in 88aa50e
The first
processInputMapping()
(scalar values) dispatches to user-configured bindings.The second (byte array) does not, but takes JS function
incomingData()
for granted. No default implementation is supplied.My conclusions:
0xF9
,0xFA
,0xFC
) are not related.processInputMapping(byte[])
configurable (as in 2.3)incomingData()
mandatory, document this, supply an empty default implementation and change the existing mappings by renaming the custom dispatcher function and remove the SysEx binding (<status>F0</status>
) from XML.WDYT?
3 remaining items