Up to ES7? and related JS/mapping thoughts

Hiya. I've realised now that part of the mixxx-launchpad process is transpiling from newer to older JavaScript. I'm not a coder (dyslexic, dyscalculic, exceptionally bad memory) so I can't directly dive in to grok and upgrade things in a standard manner, but I'm wondering how much of that could essentially be passed over, now that Mixxx has moved to ES7.

I have a primary controller, a Reloop Beatmix 4, but I'm very curious about the abstracted functions (including rebouncing beatjump) and understanding of the [Launchpad] grid this system apparently affords, especially in relation to hotcues and loops. 64 hotcues is the max currently; if there's a way to trigger them, then super creative beatjumping can be achieved, plus there is the official skin availability of 64 samplers already.

Abstracted functions; as in the functions that are shared with multiple [Launchpad] grid devices though generating their separate mappings. The related Mixxx "thread" currently, imho , is the common-*/components .js scripts, that provide functions to multiple controllers.

However, using the common*.js etc. system to share access to an "extended" set of novel features is arguably problematic, as in that it is said (by @ronso0, can't find the link) that bloating their scope (I paraphrase) could degrade performance at certain point(s) of the general Mixxx process.

So, the main point of this thread is the current mixxx-launchpad process and how it now relates to ES7 and Mixxx scripting.

The related thing that I'd like to bring up at the same time, that's not soley about mixxx-launchpad, is about the decades-old "should we put novel functions in our system's standard set of functions?" programming language theory/implementation question.

If "no", then "should/how can we share abstracted/parameterised functions between controllers, however novel they might be?". (The distinction between novel and "that isn't actually that far out when you think about it" is questionable imho).

mixxx-launchpad generates multiple controller profiles, and at the other end of the scale, Mixxx universally provides certain handy abstracted functions to all devices.

Given that many controllers have a grid system, and that style of HCI is not going away (e.g. up the pad filter on https://controllers.cc to 16/32); and given that (afaiu) the greater aspect of the transcoding process in mixxx-launchpad is now unneeded (maybe, unless there is worth seen in backporting from ES8, ES9, ES10..); and even if the main common-controller-scripts.js doesn't end up getting extended;

Is there a way to make making controller profiles/scripts easier by somehow sharing shareable functions between them? (One feature I've created is "auto hotcue creation for drop/-16/-32/-64 plus intro end", which could be parameterised to give it a more general worth)

N.B. FWIW, aside from this, there is (amongst other things!) the thread about MIDI mapping via JS, updating the MIDI components .js, and JS modules, and affecting scripts in the GUI.

Hi @mxmilkiib,

I am very much opinionated about keeping transpilation / bundling:

we are using Typescript, which has to be transpiled.
mixxx still hasn't got ES style importing system, thus there is no way to idiomatically modularize the code right now, so bundling can't be ditched
it let's us workaround bugs in the engine (like arrow functions not working properly) easily
it affords us greater independence and to experiment with new features

I know it has cons, like greater barrier to entry, additional tools to be learned, etc. but IMO the pros trump these. So in short, I wouldn't pass over the process at the current state.

I don't think I can provide an answer to how hard it would be to reuse this framework for other controllers. When I created it, I had only the support of multiple versions of LaunchPad in mind, and that I wanted to make it easy to customize it with a config file. Only recently (when I bought a LaunchControl) did I start to modularize it further by extracting common plain JS utilities (common), common mixxx utilities (mixxx), etc. I still find some generic parts time to time that are too opinionated and have to be refactored even in the context of Novation controllers (e.g in #89 I needed to abstract the notion of control further.)

Facilitators:

The build system is generic enough to support almost any controller. Even if it has so many controls, that you need to generate them programatically (#87).
The mixxx utilities are generic. There's a lazy loading system to only instantiate required parts of the object tree.

Obstacles:

The component and declarative configuration system (which is really the heart of the thing) is kind of bare bones, most of the code is specific to the device. Although it went to a thorough refactor to enable declarative configuration for the LaunchControl, it is far from ideal.

mixxx-launchpad generates multiple controller profiles, and at the other end of the scale, Mixxx universally provides certain handy abstracted functions to all devices.

I see two major problems with reusing anything from the mixxx library here:

they are not ES modules, so we have to resort to some inferior importing mechanism
we are using TypeScript in strict mode, type stubs need to be added.

More concretely about the reusability of the declarative controls are in a nutshell the following. The most fleshed out controls are in https://github.com/dszakallas/mixxx-launchpad/tree/master/packages/launchpad-common/src/controls.

All of these are for triggers (pads, buttons), no knobs, encoders. (Currently my highest priority is to introduce knob and fader controls into this system as part of the LaunchControl mapping)
They were designed with the presence of modifier states in mind (shift, control, control-shift) to get full functionality. Not having those reduce functionality of some controls quite badly. (Not on my roadmap to do anything about this)
They talk to the device in a very low-level way; they use Launchpad specific messages for colors. Generalizing it should entail the introduction of some way to abstract colors. Certain older Novation devices doesn't have RGB leds, so they use a restricted color palette which is actually a pro for portability (only the hotcues/samplers are smart enough to try RGB and fall back to a restricted color palette if not available, as having a wide spectrum of colors is quite essential for these). (Low prio, on which i can't convince myself to work, but I am very open to contributions)
They target the launchpad grid. They should instead target a more generic control definition. A grid is nice, because it makes it straightforward to layout an array of controls with custom dimensions. I guess we could introduce a sort of combinator that works as a control definition transformer and gets some rule of MIDI control definitions and turns it into an n x m grid for use of at least some of the controls that are almost always arrays (hotcues, jumps, loops). (I will likely work on this, as I would like to use a grid system for the LaunchControl as well, and that will need some abstraction that is more independent of the device)

dszakallas / mixxx-launchpad

Up to ES7? and related JS/mapping thoughts #86