Support the Icon P1-Nano controller

[SamWhited]

This adds support for the Icon Pro Audo P1-Nano (and likely the larger P1-X/P1-M, though I can't test that) which (mostly) follows the Mackie Control Protocol (MCU) spec. It may be worth having a generic "MCU Device" script at a later date, that other scripts like this one (with minimum proprietary features) could inherit from, or that would stand alone if your specific device wasn't supported. However, I don't have a way to test that since I only have one controller that uses MCU, so for now it's its own script.

Associated manual PR: mixxxdj/manual#751

Potential future follow ups (or hit me up if you have ideas for some of these):

• Figure out how to set the text and MIDI configuration of the touch screen buttons
• Figure out if it's possible to enable the Trim and Off buttons without their proprietary software
• Figure out what to do with the Read/Write/Touch/Latch/Trim/Off buttons
• Let the user configure and use the other 4 faders for samplers, preview decks, aux inputs, mics, etc.
• Let the user configure what the 7-segment display is used for (eg. we might put BPM here)
• Use the blue/red LED under the jog wheel for something?
• Should we extract some of this into a generic "MCU Compatible Device" mapping that this mapping can inherit from and only add some proprietary bits on top?

[SamWhited]

This is sporadically (but not always?) throwing:

Uncaught exception: file:///home/sam/.mixxx/controllers/Icon-P1Nano-scripts.js:178:
Error: script tried to connect to ControlObject ([Controls], ShowDurationRemaining) which is non-existent.

On startup. I see there were some open issues for this, but maybe not for 2.5? Unclear to me if this is something that it's possible to fix in the controller mapping, looks like a Mixxx bug.

See #10967

[SamWhited]

Quick ask for whomever reviews this: how would we feel about including an XML file with the distribution that can be loaded with Icon's proprietary tool? Right now the touch screen controls can't be used due to #14651 so as a workaround I could export the XML file used to configure the device and we could mention in the docs that it's in the controllers directory so that if you are on Windows or Mac you could load it at least. It feels weird having a file for some proprietary software in Mixxx though. Maybe it's better to just stick it on the forum thread instead?

[acolombier]

This is sporadically (but not always?) throwing [..] On startup

Sounds like a race condition between the CO creation and the controller starting. This CO gets created inside the preference window, which IIRC is created at the end of the init loop, after the controller manager which will start your controller in a thread.

This CO will probably have to be moved out to be compatible with QML (Mixxx 3.0)

[acolombier]

It feels weird having a file for some proprietary software in Mixxx though. Maybe it's better to just stick it on the forum thread instead?

It does sound weird, and could even be problematic due to distribution licenses. What would this file be used for? Without context, the forum indeed sounds like a great default place, but depending how this is meant to be used, perhaps we could use an alternative open format?

[SamWhited]

What would this file be used for? Without context, the forum indeed sounds like a great default place, but depending how this is meant to be used, perhaps we could use an alternative open format?

The file itself is just XML, it lists all the names of the buttons on the touch screen and can be loaded into their proprietary software to change the button names (and what MIDI parameters they output). Unfortunately due to #14651 we can't actually set these from mixxx itself at the moment.

[SamWhited]

Before we continue with the review on this, I'm considering making some pretty major changes.

Right now each screen shows a parameter (gain, high EQ, etc.) and you toggle through the various decks with the left and right arrows that would select a track in a DAW. However, this means that when you adjust the volume for deck 1, say, the screen on the device changes to the "gain" screen, and when you adjust the volume for deck 2 it changes to the "high EQ" screen. This doesn't make much sense, but the controller expects the volume to be associated with that particular virtual screen (because it thinks they both correspond to a single DAW track).

Instead I'm thinking about changing this to behave more like a DAW: the first four screens will each be a different deck and you continue to choose them with the arrows like before. This time however the parameter can be changed by scrolling with some other button (maybe shift + turning the knob? Maybe 8>> and <<8?). Now when you select deck 1 and adjust the volume, the deck 1 screen is automatically selected, which makes a lot more sense. The problem with this is that more buttons are required and I'd have to figure out the best way to handle selecting the parameter as well as the deck, and that I don't know what to do with the other four screens anymore (preview decks? control aux inputs? Mics? they could be anything).

I know if you don't have this controller this may be a bit hard to follow, but if anyone has opinions I'm all ears!

EDIT: went ahead and just tried this and it feels much better to me; works the way you expect a DAW controller to work and in tandem with the built in features of the controller. Still need a use for the rest of the channels, but that can come later and isn't important to start with. This also opens up the option of using the <<8 and 8>> buttons to change all the screens to something else (eg. preview decks, aux, mics, etc.) at a later date, so it's more flexible than the old way. Will update the documentation shortly, but for now I'm going to say this is ready for review again.

[SamWhited]

Any chance of getting this reviewed before 2.5.2 goes out?

[SamWhited]

Gentle ping on this; any chance @Swiftb0y, @ronso0, or @acolombier want to do a review? This has been sitting for a bit. After this and the Twister stems one are merged this will be my last one for a while, I promise :)

[acolombier]

@mixxxdj/developers will there be another 2.5 or should this go in 2.6?

[JoergAtGithub]

Target should be 2.5 !

[acolombier]

Looking good - some optional nit and questions regarding groups. Just waiting for a bit to see if it needs changing but planning to merging as is otherwise!

[acolombier]

As always, thanks for your contribution and for keeping up with our (sometimes) slow review process 😃