Arturia Minilab MkII

MiniLab mkII JavaScript: come aumentare la precisione dei knob in Cubase 15 con MIDI Remote

La Arturia MiniLab mkII è un controller compatto ma molto denso: 25 slim-keys, 16 encoder, 8 pad in doppio banco e due touch strip. Sulla carta è un formato ideale per Cubase 15 tramite MIDI Remote.

Nella pratica, però, basta assegnare un encoder a un parametro con range ampio per accorgersi del limite: il movimento è a scalini, e trovare il punto esatto diventa più difficile del dovuto.

Non è un difetto dell'hardware, e non è nemmeno un problema specifico dello script ufficiale Steinberg. Il nodo è la granularità percepita del controllo relativo standard. La buona notizia è che si può migliorare molto senza uscire dalla MIDI Remote API: basta cambiare architettura.

Perché il driver ufficiale non basta

Nel repository ufficiale Steinberg esiste già uno script per la MiniLab mkII. La struttura è pulita e pronta all'uso: il driver definisce 16 encoder relativi in RelativeBinaryOffset, con due encoder push, e organizza il controller in tre pagine: Focus Quick Controls, Mixer ed EQ of Selected Track. [file:112]

Questa impostazione funziona bene come mapping generico. La pagina Mixer usa una MixerBankZone, esclude input e output, assegna gli 8 encoder superiori al pan e gli 8 inferiori al volume, mentre i due push encoder servono per PrevBank e NextBank. [file:112]

La pagina EQ of Selected Track controlla le quattro bande dell'EQ del canale selezionato, distribuendo frequenze, Q e gain tra i 16 encoder. La pagina Focus Quick Controls, invece, è una pagina contestuale più generica, legata ai Focus Quick Controls e ad alcuni lock di focus e mouse cursor. [file:112]

Il problema non è quindi "manca il driver". Il problema è che, usando il binding relativo standard, il feeling resta quello deciso da Cubase per quel tipo di controllo, con poco margine di intervento sulla finezza percepita.

La strada che ha funzionato davvero

L'idea iniziale più ovvia era semplice: usare direttamente i binding relativi standard e conviverci. In pratica, però, non era abbastanza flessibile per ottenere la sensibilità desiderata sui parametri più delicati.

La soluzione che si è rivelata efficace è stata un'altra: lasciare l'architettura dentro la MIDI Remote API, ma disaccoppiare completamente il knob fisico dal parametro host.

Invece di far pilotare l'encoder direttamente al parametro di Cubase, ogni encoder viene definito come makeKnob(...), bindato al suo CC e impostato in setTypeAbsolute(). Quel knob non controlla il parametro finale, ma una CustomValueVariable intermedia.

Il parametro vero viene poi collegato con page.makeValueBinding(trigger, hostValue). A quel punto il controllo reale passa da una variabile software intermedia, che può essere aggiornata con una logica personalizzata.

Questa scelta cambia tutto: Cubase continua a vedere un valore normalizzato tra 0 e 1, ma il modo in cui quel valore viene costruito è deciso interamente dal codice.

L'architettura custom

La catena effettiva è questa:

  1. Encoder fisico makeKnob(...)
  2. Binding MIDI sul suo CC in setTypeAbsolute()
  3. Knob collegato a una makeCustomValueVariable('trig_x')
  4. Binding host finale fatto con page.makeValueBinding(trigger, hostValue)
  5. Logica custom nel callback mOnProcessValueChange
  6. Reset del knob sensore a un centro noto dopo ogni tick

In altre parole, il knob fisico diventa un sensore di movimento, non più un controller diretto del parametro.

Nel callback mOnProcessValueChange si legge il processValue normalizzato generato da Cubase, si ricava direzione e intensità del movimento, si decide uno step software e poi si aggiorna la CustomValueVariable. Infine il knob viene riportato subito al centro con setProcessValue(activeDevice, CENTER).

Per evitare loop o rientri indesiderati, il tutto è protetto con flag di push/reset. Inoltre trig.mTouchState.bindTo(knob.mSurfaceValue) resta utile per mantenere coerente lo stato di touch.

La scoperta che ha sbloccato tutto

Inizialmente il centro era stato trattato come 0.5. È la scelta intuitiva, ma sulla MiniLab mkII in questo contesto non è il centro corretto del messaggio neutro.

Il valore giusto è:

var CENTER = 64 / 127;

Numericamente significa 0.503937..., non 0.5.

Questa piccola differenza è stata decisiva. Una volta allineato il centro reale a 64/127, sono sparite gran parte delle asimmetrie apparenti e dei falsi tick in direzione opposta che comparivano vicino alla posizione neutra.

Da lì il decoder è diventato davvero simmetrico avanti/indietro.

Come leggere i tre cluster dell'encoder

Nei test reali il comportamento osservato dei knob si è organizzato in tre cluster principali.

Forward:

  • 0.511811 -> distanza circa +0.007874
  • 0.519685 -> distanza circa +0.015748
  • 0.527559 -> distanza circa +0.023622

Reverse:

  • 0.496063 -> distanza circa -0.007874
  • 0.488189 -> distanza circa -0.015748
  • 0.480315 -> distanza circa -0.023622

Tradotto in termini pratici, l'encoder si comporta come se avesse tre "marce" simmetriche:

  • gear 1 = ±1/127
  • gear 2 = ±2/127
  • gear 3 = ±3/127

Questo consente di classificare il movimento in modo molto stabile usando soglie fisse.

Il decoder usato nel progetto

La configurazione che ha dato risultati solidi è questa:

var CENTER = 64 / 127;
var CENTER_EPS = 0.003;
var T1 = 0.011811;
var T2 = 0.019685;
var STEPS = [0.0002, 0.0040, 0.020];

La logica è semplice:

  • se il movimento è molto vicino al centro, si ignora
  • se supera il dead zone, si capisce il verso
  • in base alla distanza dal centro si determina la marcia
  • a ogni marcia corrisponde uno step software diverso
  • il trigger custom viene aggiornato
  • il sensore viene riportato al centro

Il punto importante è che gli STEPS non descrivono il MIDI in ingresso, ma la risposta software che si vuole ottenere sul parametro host. Qui sta tutto il guadagno di precisione percepita.

Perché questa soluzione è migliore del workaround in absolute mode

Esiste anche un workaround senza JavaScript: lasciare gli encoder in absolute mode e ridurre la knob acceleration nel MIDI Control Center. In alcuni casi funziona sorprendentemente bene, ma ha due limiti strutturali.

Il primo è che servono più giri per coprire il range completo del parametro. Il secondo è il value jump: l'encoder conserva una posizione virtuale interna, e quando si cambia target il parametro può saltare al primo tocco.

Con l'architettura custom descritta qui, invece, il knob non trasporta più una "posizione" persistente del parametro. Trasporta solo movimento, che viene reinterpretato lato Cubase e riversato su una variabile intermedia.

Il risultato pratico è un controllo più fine senza rinunciare alla continuità del workflow.

Com'era organizzato il setup finale

Nel mapping personalizzato sviluppato a partire dalla configurazione utente di Cubase, la struttura delle pagine è diventata diversa da quella dello script factory. Le pagine presenti sono Default, Trasporto ed EQ. [file:43]

La pagina Default è collegata a una MixerBankZone con FollowVisibility=true e ospita 16 binding di volume su 16 canali di banco, più le azioni di navigazione banca e alcuni comandi di trasporto/mixer. [file:43]

La pagina EQ lavora invece sul canale selezionato e comprende EditorOpen, PreFilter, LowCut, HighCut e le quattro bande del ChannelEQ, inclusi i toggle On/Off delle bande. Rispetto alla pagina EQ del driver factory Steinberg è un'impostazione più ricca e più utile nel lavoro reale. [file:43][file:112]

Lo scheletro del driver

La parte iniziale del file resta quella tipica di un driver MIDI Remote in JavaScript ES5:

var midiremote_api = require('midiremote_api_v1');

var deviceDriver = midiremote_api.makeDeviceDriver(
    'Arturia',
    'MiniLab mkII',
    'base64.it'
);

var midiInput = deviceDriver.mPorts.makeMidiInput();
var midiOutput = deviceDriver.mPorts.makeMidiOutput();

deviceDriver.makeDetectionUnit()
    .detectPortPair(midiInput, midiOutput)
    .expectInputNameContains('MiniLab mkII')
    .expectOutputNameContains('MiniLab mkII');

Sul piano pratico questa forma di detection funziona bene per uno script custom locale. Va però tenuto distinto dal driver ufficiale Steinberg, che nel file factory usa invece il riconoscimento via expectSysexIdentityResponse(...). [file:112]

Inoltre conviene ricordare che l'ambiente della MIDI Remote API è ES5: niente const, niente let, niente arrow function.

Il cuore della soluzione

Il passaggio decisivo non è intercettare tutto il MIDI grezzo e riscrivere da zero il driver. Il passaggio decisivo è usare la MIDI Remote API in modo meno diretto.

Invece di questo:

knob.mSurfaceValue.mMidiBinding
    .setInputPort(midiInput)
    .bindToControlChange(0, 74)
    .setTypeRelativeBinaryOffset();

si fa questo:

var knob = surface.makeKnob(0, 0, 2, 2);

knob.mSurfaceValue.mMidiBinding
    .setInputPort(midiInput)
    .bindToControlChange(0, 74)
    .setTypeAbsolute();

var trig = surface.makeCustomValueVariable('trig_1');
page.makeValueBinding(trig, hostValue);

A quel punto il knob non muove più direttamente il parametro host. Lo muove tramite una variabile software controllata da codice.

Il callback diventa il posto in cui decidere quanto deve valere davvero ogni tick dell'encoder.

Esempio semplificato del decoder

Una versione ridotta del cuore logico è questa:

var CENTER = 64 / 127;
var CENTER_EPS = 0.003;
var T1 = 0.011811;
var T2 = 0.019685;
var STEPS = [0.0002, 0.0040, 0.020];

function clamp01(v) {
    return v < 0 ? 0 : (v > 1 ? 1 : v);
}

function classifyGear(adist) {
    if (adist >= T2) return 3;
    if (adist >= T1) return 2;
    return 1;
}

knob.mSurfaceValue.mOnProcessValueChange = function (activeDevice, value) {
    var dist = value - CENTER;
    var adist = Math.abs(dist);

    if (adist < CENTER_EPS) return;

    var dir = dist > 0 ? 1 : -1;
    var gear = classifyGear(adist);
    var step = STEPS[gear - 1];

    var current = trig.getProcessValue(activeDevice);
    var next = clamp01(current + dir * step);

    trig.setProcessValue(activeDevice, next);
    knob.mSurfaceValue.setProcessValue(activeDevice, CENTER);
};

Nel file reale servono anche protezioni contro i loop e una sincronizzazione minima tra trigger e accumulatore interno, ma il principio è tutto qui.

Cosa cambia all'uso

Con questa architettura il controller smette di essere "quello che manda 128 valori". Diventa piuttosto un generatore di impulsi simmetrici attorno a un centro reale, che il codice traduce in micro-spostamenti o macro-spostamenti del parametro.

Questo permette di disegnare il feeling del controllo in modo molto più libero:

  • una marcia lentissima per il fine tuning
  • una marcia intermedia più rapida
  • una marcia veloce per coprire range ampi

Nel setup finale, STEPS = [0.0002, 0.0040, 0.020] si è rivelato un compromesso molto convincente: gear 1 davvero precisa, gear 2 pronta, gear 3 sufficientemente rapida da non rendere faticoso attraversare il range.

Cosa resta aperto

Non tutto viene risolto automaticamente.

I pad restano dipendenti anche dal firmware e dalla curva scelta in MIDI Control Center. Le touch strip possono richiedere una logica dedicata a seconda dell'uso che si vuole farne. E il tema del "reset al valore di default" non è universale: portare un parametro a 0.5 funziona solo quando il centro logico coincide davvero con il centro del range.

Ma il punto fondamentale resta: il collo di bottiglia principale degli encoder si può superare.

Conclusione pratica

La MiniLab mkII non va scartata come controller per Cubase solo perché il comportamento standard degli encoder sembra troppo grossolano. Con una piccola riscrittura del driver in JavaScript ES5 e con un'architettura basata su CustomValueVariable, decoder software e recentraggio controllato, il feeling cambia in modo netto.

Il driver ufficiale Steinberg rimane una buona base concettuale per capire la superficie e le pagine disponibili. Ma se l'obiettivo è aumentare davvero la precisione percepita dei knob, la strada più efficace è costruire un layer intermedio tra encoder fisico e parametro host.

Scarica il file JavaScript completo