Controllers: Add Mapping for Reloop Ready

[Swiftb0y]

Initial commit of a mapping for the Reloop Ready controller.
The Padmodes are not implemented and just default to the hotcues
right now. The mapping currently depends on

• midi-components-0.0.js: Add JogWheel component #4474
• midi-components-0.0.js: Pot support for arbitrary maximums in 7-/14-bit handlers #4495
• .eslintrc.json: adjust eslint rules to enforce readable chain syntax #4512

[majekw]

FX unit 2 level knob doesn't work. With suggested changes it works (tested).

[majekw]

There is also issue with 'Vinyl' led status light on startup - it's not lit despite Mixxx 'on' settings. Pushing button changes it correctly. I didn't dig more into code to find where it should be added/corrected, sorry.

Anyway, thanks for a lot of job done to support it 👍

[Swiftb0y]

Thank you very much for your review. Currently there is no-one really reviewing controller mappings apart from myself and I obviously can't review my own mapping, so your effort to review this brings us closer to merging.
Sorry for the small issues, I'll take care of them ASAP.

[majekw]

@Swiftb0y, could You add new commits instead of force pushing? I don't know what changed since I tested it last time (no meaningful commit messages or just comments here) and I don't know if any new testing is required. I own Reloop Ready, but I seldom use it. I know that some modes of performance pads are not implemented yet, so I would be happy to check this as soon as they become available.
At the end You could just use merge with squash if you don't want many small commits merged, or even force push everything

Do you have some checklist to see what should work, what is work in progress and what is still to do?

And thank You for still working on it 👍

[Swiftb0y]

@majekw Since this is just a draft PR I wanted to keep the commit history clean. Since this PR contained preliminary commits which were merged in other PRs, I just rebased those out. So now it only contains the two hardware-specific files. The next push will be a couple of fixes and a new feature. I'll explain in the respective commit messages. I'll ping you again once this is ready for more testing.

[Swiftb0y]

I know that some modes of performance pads are not implemented yet, so I would be happy to check this as soon as they become available.

I don't think I'll implement the pitch play mode. And for the scratch bank mode, I wanted to repurpose that to beat jumps.

[Swiftb0y]

@majekw pushed new commit. you can take a quick changelog from the commit description. I developed most things in parallel so splitting into separate commits wouldn't have made sense since I'll squash this anyways. I'd highly appreciate if you could do some testing.

[Swiftb0y]

@majekw Were you able to do some testing?

[Abdull]

@Swiftb0y , thank you for Reloop Ready mapping!

I am currently testing your latest mapping version, i.e.

• https://github.com/Swiftb0y/mixxx/blob/c2c475d4e89ae4e6637bce71fb22a9aa642a715e/res/controllers/Reloop%20Ready.midi.xml
• https://github.com/Swiftb0y/mixxx/blob/c2c475d4e89ae4e6637bce71fb22a9aa642a715e/res/controllers/Reloop-Ready-scripts.js
  , against mixxx 2.4-beta-394-gd1c0de51b0.

I noticed the tempo sliders are behaving inverted (i.e., when physically moving the tempo sliders up towards "minus", actually physically/logically the sliders move down towards "plus").

Setting invert: true in the this.rate Pot component fixes this:

    this.rate = new components.Pot({
        inKey: "rate",
        invert: true, // <--- the fix #######################################
        max: 1023,
        // see explanation of ReloopReady.tempoFaderMiddles for info
        inValueScale: function(value) {
            var middle = (this.max + 1) * ReloopReady.tempoFaderMiddles[index];
            return script.absoluteNonLinInverse(value, 0, middle, this.max, 0, 1);
        }
    });

Also, I'm trying to also solve an issue with scratch behavior (which is not limited to the Reloop Ready mapping, see https://mixxx.zulipchat.com/#narrow/stream/109122-general/topic/spinning.20platter.20in.20vinyl.20scratch.20mode.20is.20jerky.20.2F.20unsmooth ).

Once you have some spare time, maybe we can put our heads together for solving it.

It be awesome if the Reloop Ready mapping could make it into Mixxx.

[Swiftb0y]

Hey there @Abdull. I'm afraid I can't do much about the scratch behavior issue (its universal to mixxx and related to the way we handle scratching internally which I'm not familiar nor qualified enough to look into it). I can however help you with the tempo sliders. What are your tempo slider settings (found in the deck preferences)?

[Abdull]

Hey there @Abdull. I'm afraid I can't do much about the scratch behavior issue (its universal to mixxx and related to the way we handle scratching internally which I'm not familiar nor qualified enough to look into it). I can however help you with the tempo sliders. What are your tempo slider settings (found in the deck preferences)?

With invert: true, everything becomes fine with the tempo sliders.

Regarding scratching, I guess a timeout until no movement is detected would be a viable solution (for all controllers); that is the solution Serato DJ has taken to my observation.

I would have worked on such solution in the past days if only my Reloop Ready hasn't started to logically spin the left jog wheel counterclockwise, no matter if it's spun physically clockwise or counterclockwise.

It's really a cheaply manufactured controller I cannot recommend, including the fact that Reloop is unwilling to provide MIDI mappings when asked.

[Swiftb0y]

With invert: true, everything becomes fine with the tempo sliders.

Yeah, I see, but that's weird because that would imply that the messages sent by your controller differ from mine. Can you send me a screenshot for your tempo sliders (in whatever mixxx skin you're using) and from the deck preferences?

It's really a cheaply manufactured controller I cannot recommend, including the fact that Reloop is unwilling to provide MIDI mappings when asked.

I agree. I already built in some logic to account for units such as mine that have the notch of the tempo fader offset, so it locks the fader at +0.5%bpm speed...

[Abdull]

Fixed. I'd highly appreciate if you could do some testing @Abdull.

Thanks, I can give it a good round of testing next year, i.e. tomorrow or the day after it ;). I will report.

[Swiftb0y]

all green. Already did some testing and I also made sure I didn't miss anything from your previous review comments. Looking forward to your testing @Abdull

[Abdull]

I executed the following commands to build this PR:

ccache --set-config=max_size=20.0G
# check active user-wide ccache configuration with
#   ccache -p

mkdir -p "${HOME}/git"
cd "${HOME}/git"

git clone --recurse-submodules https://github.com/mixxxdj/mixxx

cd "${HOME}/git/mixxx"

# checkout _this_ PR
gh pr checkout 4513

# I use Debian 12 btw
tools/debian_buildenv.sh setup

cmake -DCMAKE_INSTALL_PREFIX=/usr/local -S ~/git/mixxx -B ~/mixxx/git/build

cmake --build ~/git/mixxx/build --parallel $(nproc)

sudo cmake --build ~/git/mixxx/build --target install --parallel $(nproc)

Next, I cleaned up/removed manually-added files from "${HOME}/.mixxx/controllers" (they overlay/shadow/win over the same-filenamed versions found under ${HOME}/git/mixxx/res/controllers, having caused issues for me in the past by Mixxx using a mishmash of different controller file versions not working together; not sure about the winning precedence when also considering /usr/local/share/mixxx/controllers ) .

Executing "${HOME}/git/mixxx/build/mixxx" starts up the expected version 2.5.0-21-g4df4f3c29e (reloop-ready).

Successfully checked that the "Mapping Files" (blue clickable file links) are indeed pointing to the most recent versions from this pull request (i.e., all these "built-in" files are under ${HOME}/git/mixxx/res/controllers).

Happy to see the additional GUI tweaking options "Mapping settings" and "Tempo Fader neutral correction (See Manual)". I will set Channel Knob Assignment to "Filter, Low, Mid, High". Awesome!

Next up, I will do some mixing and report on that.

[Swiftb0y]

Great. Thank you for the feedback. There are no C++ changes in this PR so you also could've simply copied the files to your ~/.mixxx/controllers/ directory and used with 2.5 stable too. That would've probably been more convenient for you.

[Abdull]

all green. Already did some testing and I also made sure I didn't miss anything from your previous review comments. Looking forward to your testing @Abdull

Observations so far:

• For deck 1, despite its VINYL mode activated and the deck playing, forward-/backward-fast-spinning does not work: deck 1 stays in "speed-up-slow-down" mode (don't know the proper term for non-vinyl mode right now). This issue does not present itself on deck 2.
• @Swiftb0y, if I remember correctly, you also experienced the issue of the Reloop Ready crossfader spuriously software-wise sticking in place despite being physically moved. I still experience this phenomenon. When this happens, a new track on e.g. deck 2 I want to punch in (by moving the crossfader physically e.g. from complete left to center position) stays silent (the crossfader logically stays to the complete left). I think this is a feature of Mixxx and other DJ software to avoid abrupt value jumps for e.g. volume faders, so that the operator first has to physically slide over the currently set logical value in order to "pick up"/attach physical to logical control. But with the Reloop Ready, that's somehow a problem (maybe due to hardware noise). I also remember you did have some source code-controlled option in the Reloop Ready mapping files to deactivate this feature. Maybe you can expose it as an option to deactivate the "pick up feature" within the GUI configuration for all kinds of range values (?
• Vinyl / scratch mode (as it currently works only on deck 2) still produces a wobbly, unnatural movement when backspinning/forwardspinning after fingers are taken off the platter, manifesting acoustically like a worn-out audio tape. I think this is a bug/issue present in all controller mappings (not only in this Reloop Ready mapping). Curiously, the wobbly/jerky movement does not appear in "non-vinyl"/"vinyl deactivated" mode when the track is paused, albeit the non-vinyl mode produces distinct other sounds (this formant-like "keeping almost stable pitch" sound). In the past, I tried to fix this "wobbly fingers-off vinyl movement" in your Reloop Ready JavaScript coe with the following workaround: despite fingers off the platter, keep state of this platter as if still touched (because for whatever reasons, this does not cause wobbly spinning); then when spinning speed goes below some threshold, restore actual state of no fingers on platter. Obviously, while this did work sort of, it just caused further issues. I wish I better understood Mixxx' model of writing mappings so I could contribute a working solution.
• in the GUI configuration, "Tempo Fader neutral correction (See Manual)": do you mean as manual the comment in Reloop Ready.midi.xml? I.e.:

            <!--
                On my hardware unit, the tempo faders have such a cheap build-quality
                that the notches in the center are not actually in the middle
                If you find your notches are offset too, do this:
                Load this mapping in mixxx using `developer` mode.
                Then move the tempo fader into the notch at the position where
                the tempo should then be the true tempo (+/- 0). Open the developer tools
                and read the `rate` value of the channel. If its already 0.5 you should be
                good, if its not that, copy the value here and the fader will be adjusted
                for you.
            -->

[Swiftb0y]

Thanks a lot for the thorough report. I will try to address them ASAP.

For deck 1, despite its VINYL mode activated and the deck playing, forward-/backward-fast-spinning does not work: deck 1 stays in "speed-up-slow-down" mode (don't know the proper term for non-vinyl mode right now). This issue does not present itself on deck 2.

Thats weird, I'll look into it.

if I remember correctly, you also experienced the issue of the Reloop Ready crossfader spuriously software-wise sticking in place despite being physically moved.

I experienced it with the volume faders IIRC. The feature is called "soft-takeover" and its easy to disable in this case. I'll push a commit soon.

Vinyl / scratch mode (as it currently works only on deck 2) still produces a wobbly, unnatural movement when backspinning/forwardspinning after fingers are taken off the platter, manifesting acoustically like a worn-out audio tape. I think this is a bug/issue present in all controller mappings (not only in this Reloop Ready mapping).

Yeah, its an issue in the scratch code no one has bothered to look into. Thats out-of-scope for now IMO. The way the scratching is done is the mapping is correct, its just not calculated correctly in the actual C++ scratch code.

in the GUI configuration, "Tempo Fader neutral correction (See Manual)": do you mean as manual the comment in Reloop Ready.midi.xml?

No I mean manual as in the (broken until the corresponding mixxxdj/manual#478 is merged) "Mixxx Manual" link at the top right (next to "Support").

[Swiftb0y]

For deck 1, despite its VINYL mode activated and the deck playing, forward-/backward-fast-spinning does not work: deck 1 stays in "speed-up-slow-down" mode (don't know the proper term for non-vinyl mode right now). This issue does not present itself on deck 2.

Thats weird, I'll look into it.

I can't confirm this. Without further debugging, my best guess would be a hardware problem on your side. Can you double check whether you have the correct ReloopReadyInstance.components.leftDeck.jog.inputTouch mappings in your XML? Also double check whether mixxx (using --controller-debug) receives messages when you touch and release messages (specifically status 0x90 (ch 1, opcode 0x9), ctrl 0x06 messages). Does the issue go away when you toggle the vinyl button a couple times?

[majekw]

Deck 1 works as intended in vinyl mode on my unit.

Another thing: there is slight delay between touching jog wheel and Mixxx reaction and stratch effect. I see that touch events from controller are instant, so delay is somewhere in Mixxx. Is it bug or should I get used to this delay? Try fast instant jog spin to replicate this.

[Swiftb0y]

Thanks for the testing Marek.

Another thing: there is slight delay between touching jog wheel and Mixxx reaction and stratch effect. I see that touch events from controller are instant, so delay is somewhere in Mixxx.

If the delay is only audible (and also happens when scratching on the waveform) a too large audio output buffer size may be at fault. Apart from that, it may be some weird behavior with the underlying mixxx jog code again... I'm not sure. For now I'm afraid you're gonna have to get used to it.