Skip to content
/ mixxx Public
  • Rate limit · GitHub

    Access has been restricted

    You have triggered a rate limit.

    Please wait a few minutes before you try again;
    in some cases this may take up to an hour.

  • Notifications You must be signed in to change notification settings
  • Fork 1.3k

Controller mapping "SCS.3d MIDI 1" error on launch after upgrade to mixxx 2.4 #13133

Open
@sysdbugfactory

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

sysdbugfactory commented on Apr 19, 2024

@sysdbugfactory
Author

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

daschuer commented on Dec 2, 2024

@daschuer
Member

Is this a duplicate of #13144?

Swiftb0y

Swiftb0y commented on Dec 2, 2024

@Swiftb0y
Member

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 of StantonSCS3d.incomingData so engine doesn't complain. It doesn't explain why the controller sends that in the first place though.

added this to the 2.5.1 milestone on Dec 19, 2024
git-developer

git-developer commented on Feb 17, 2025

@git-developer
Contributor

It doesn't explain why the controller sends that in the first place though.

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 status 0xf0.

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

StantonSCS3d.incomingData = StantonSCS3d.statusResponse;

after declaration of StantonSCS3d.statusResponse.

git-developer

git-developer commented on Feb 17, 2025

@git-developer
Contributor

Related: #11536, #12824

git-developer

git-developer commented on Feb 17, 2025

@git-developer
Contributor

Problem was introduced with 2.4.0 (does not occur on 2.3.6 and below).

Swiftb0y

Swiftb0y commented on Feb 17, 2025

@Swiftb0y
Member

This is caused by a sysex command sent from init() requesting the firmware version.

Oh yeah. I missed that.

Workaround is to add

StantonSCS3d.incomingData = StantonSCS3d.statusResponse;

after declaration of StantonSCS3d.statusResponse.

Yup. Do you want to open a PR?

git-developer

git-developer commented on Feb 17, 2025

@git-developer
Contributor

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:

MidiKey mappingKey(data.at(0), 0xFF);

auto it = m_preset.getInputMappings().constFind(mappingKey.key);
for (; it != m_preset.getInputMappings().constEnd() && it.key() == mappingKey.key; ++it) {
processInputMapping(it.value(), data, timestamp);
}

2.5.0

Declaration of a function incomingData() and call of all (really? can't believe that) input functions:

functionName.append(QStringLiteral(".incomingData"));
m_incomingDataFunctions.append(
wrapArrayBufferCallback(
wrapFunctionCode(functionName, 2)));

for (auto&& function : m_incomingDataFunctions) {
ControllerScriptEngineBase::executeFunction(&function, args);
}

git-developer

git-developer commented on Feb 18, 2025

@git-developer
Contributor

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 with 0xF. Some of them are used in XML mappings:

$ grep -Hirn 'status>0xf' res/controllers/*.xml
res/controllers/Reloop Beatpad.midi.xml:1987:                <status>0xF0</status>
res/controllers/Roland_DJ-505.midi.xml:3591:                <status>0xFA</status>
res/controllers/Roland_DJ-505.midi.xml:3600:                <status>0xFC</status>
res/controllers/Stanton SCS.1d.midi.xml:18:                    <status>0xf0</status>
res/controllers/Stanton SCS.1d.midi.xml:358:                    <status>0xf9</status>
res/controllers/Stanton SCS.3d.midi.xml:17:                <status>0xf0</status>

It might be that these messages are affected, too.

git-developer

git-developer commented on Feb 18, 2025

@git-developer
Contributor

I found the missing puzzle pieces.

PortMidiController::poll checks for SysEx (0xF0 status byte) and delegates to one of:

void MidiController::receivedShortMessage(unsigned char status,
unsigned char control,
unsigned char value,
mixxx::Duration timestamp) {

void MidiController::receive(const QByteArray& data, mixxx::Duration timestamp) {

which in turn delegate to one of

void MidiController::processInputMapping(const MidiInputMapping& mapping,
unsigned char status,
unsigned char control,
unsigned char value,
mixxx::Duration timestamp) {

void MidiController::processInputMapping(const MidiInputMapping& mapping,
const QByteArray& data,
mixxx::Duration timestamp) {

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:

  1. The proposed quick fix is OK for this issue.
  2. Other system messages than SysEx (e.g. status byte 0xF9, 0xFA, 0xFC) are not related.
  3. We should investigate in Custom Sysex handler for MIDI controllers #11536 how to deal with the problem in general:
    1. Either make processInputMapping(byte[]) configurable (as in 2.3)
    2. Or make 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.
  4. Confusing Midi Sysex handling #12824 is a duplicate of Custom Sysex handler for MIDI controllers #11536.

WDYT?

3 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Controller mapping "SCS.3d MIDI 1" error on launch after upgrade to mixxx 2.4 · Issue #13133 · mixxxdj/mixxx