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

• #4474
• #4495
• #4512

[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 :+1:

[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 :+1:

[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...

[Swiftb0y]

put in some love. tested the pitch-play mode and fixed the tempo slider as per @Abdull's suggestion. This is ready to go, I'd appreciate a review.

[Swiftb0y]

Hi @Abdull, I have made some bigger changes to this mapping. Now based on 2.4. Can you do me a favor and test the current state of the mapping? Thank you.

[Abdull]

Hi @Abdull, I have made some bigger changes to this mapping. Now based on 2.4. Can you do me a favor and test the current state of the mapping? Thank you.

Very nice! Thank you very much.

I just tested res/controllers/Reloop Ready.midi.xml and res/controllers/Reloop-Ready-scripts.js from https://github.com/mixxxdj/mixxx/pull/4513/commits/d97a241a4ed97802053e0960362bbf0349f14e10 against the Mixxx 2.4.0 release (self-compiled, commit ca8720f8f365853bb80e23714ed89e41b54d536a, on Debian bookworm, uname -a: Linux frami 6.5.0-0.deb12.1-rt-amd64 #1 SMP PREEMPT_RT Debian 6.5.3-1~bpo12+1 (2023-10-08) x86_64 GNU/Linux).

The tempo faders react logically correctly to physical movement (physical down is logical down, and up is up).

The controller pads shine colorfully according to the hotcue buttons, and CUE blinkenlights nicely.

The only issue I noticed (with the previous Reloop Ready mapping Aufschlag already) is that when I load a new track on a deck, that deck's physical VINYL button LED turns off, even though logically Mixxx correctly has the vinyl mode activated. This can be workedaround by pressing the deck's VINYL button twice so it shines again. I can't tell auf die Schnelle if this is a bug with the mapping or a bug with Mixxx.

But besides that, the mapping looks great to me. Thanks @Swiftb0y !

[Swiftb0y]

The only issue I noticed (with the previous Reloop Ready mapping Aufschlag already) is that when I load a new track on a deck, that deck's physical VINYL button LED turns off, even though logically Mixxx correctly has the vinyl mode activated. This can be workedaround by pressing the deck's VINYL button twice so it shines again.

I haven't noticed that, but I'll look into it. The vinyl (or more commonly called scratch) button is implemented purely within javascript, so I'm a little confused. What do you mean with "vinyl mode activated [within mixxx]"?

[Abdull]

The only issue I noticed (with the previous Reloop Ready mapping Aufschlag already) is that when I load a new track on a deck, that deck's physical VINYL button LED turns off, even though logically Mixxx correctly has the vinyl mode activated. This can be workedaround by pressing the deck's VINYL button twice so it shines again.

I haven't noticed that, but I'll look into it. The vinyl (or more commonly called scratch) button is implemented purely within javascript, so I'm a little confused. What do you mean with "vinyl mode activated [within mixxx]"?

Ah okay, TIL vinyl/scratch mode is not modeled within Mixxx, but purely within the controller mappings (so that's probably also why there are no vinyl/scratch mode indicators/buttons within the Mixxx GUI interfaces).

Here is a recording of the vinyl/scratch mode buttons I observe on my Reloop Ready controller:

As a precondition for this glitch to happen, the "SHIFT" button on the Reloop Ready controller has to have been pressed at least once during the Mixxx runtime. From then on, when loading a track to a deck (via pressing "LEFT LOAD" button for left deck, or "RIGHT LOAD" button for right deck), the targeted deck's "VINYL" button light will turn off, even when it is supposed to stay on.

Maybe it isn't an issue with the Mixxx Reloop Ready controller mapping, but a bug with the Reloop Ready controller firmware — as per the Windows-based Reloop Control Panel, my controller has revision (firmware?) v1.00.

Sending my controller the SysEx MIDI message F0 00 20 7F 19 F7 (as per Reloop's MIDI mapping PDF Firmware_map_READY_public_20210311.pdf, this is the SysEx request for "firmware version") returns f0 00 20 7f 19 00 01 00 00 f7 — so this look like a payload of 00 01 00 00 / v1.00 as well (used WebMIDI tool: https://arachsys.github.io/webmidi/sysex ).

[Swiftb0y]

Here is a recording of the vinyl/scratch mode buttons I observe on my Reloop Ready controller:

Thank you for the in depth video and analysis. The misprint on the box is funny, I've never noticed that. I don't think that is purely graphical however and no real units with that issue exist (hopefully :eyes:).

Maybe it isn't an issue with the Mixxx Reloop Ready controller mapping, but a bug with the Reloop Ready controller firmware — as per the Windows-based Reloop Control Panel, my controller has revision (firmware?) v1.00.

Pretty sure its not. FWIW I have the same firmware version. also the newest version of the mapping also requests that from the controller, so you can look it up by inspecting the controller logs (without having to install software only available on windows ;).

I'm fairly certain I know what the issue is and it's pretty straightforward to solve. I'll push a fix soon, I'm just still finishing up the remaining tasks from the previous review.

[Abdull]

FYI (for your inspiration): @andymann has a repository with Mixxx MIDI mappings for the Reloop Buddy, which is very similar to the Reloop Ready:

https://github.com/Andymann/mixxx-controllers

[Swiftb0y]

Good to know, I'd love to see that upstreamed. Maybe I can adapt the Ready mapping for the Buddy.

[Swiftb0y]

new version. see commit message for details. please resolve any review comments that you deem addressed. Thank you.