KONTAKT SCRIPTING TUTORIAL – QUARTA PARTE

Written by Antonio Antetomaso on . Posted in Software, Tutorial

In questo quarto appuntamento parleremo di un argomento assai ghiotto (almeno spero): la programmazione di interfacce grafiche. Chi ha utilizzato Kontakt e ha usato almeno un plugin di terze parti non ha potuto fare a meno di ammirare come il più delle volte un tale prodotto venga reso fruibile attraverso un’interfaccia accattivante, usabile e, soprattutto, in linea con il tipo di strumento musicale offerto.

Di Antonio Antetomaso

Con Kontakt 5 poi le cose si sono fatte maggiormente appetibili dato che è possibile programmare le interfacce grafiche introducendo componenti (bottoni, knob, potenziometri, switch ecc.) dal look and feel customizzabile. Un esempio? Beh mi risulta che uno dei primi plugin a fare uso di tale tecnologia sia stata la libreria (SUPERBA) di Fender Rhodes prodotta da Gospelmusician.com, Neo Soul Suitcase, ora aggiornata a Neo Soul Keys 3X .

Guardate che meraviglia, non sembrano proprio i potenziometri originali di un Fender Rhodes Suitcase? Come dite? Come si realizzano? Un po’ di pazienza e un passettino alla volta, iniziamo dalle basi. Naturalmente mi preme sottolineare che c’è una grossa differenza tra il disegnare o progettare un’interfaccia perchè sia usabile e nello stesso tempo accattivante e programmarla. Infatti il primo task è normalmente compiuto da un team di grafici e designers, sulla base delle specifiche ricevute dal progettista dello strumento in questione. Una volta ricevuto l’artwork grafico si passa alla codifica vera e propria in ambiente di scripting.

Noi focalizzeremo la nostra attenzione su questo secondo aspetto anche perchè il ruolo di grafico e di progettista di interfacce decisamente non si confà alle mie capacità. In particolare concentreremo la nostra attenzione sui componenti di base di una interfaccia Kontakt e su come si programmano, per poi passare ai concetti più complessi. Finita la predica e messe adeguatamente le mani avanti, partiamo senza indugio.

La prima cosa che si fa quando si programma un’interfaccia per uno strumento Kontakt è dichiarare l’interfaccia stessa all’interprete, mediante l’istruzione

 

make_perfview

 

In pratica stiamo dicendo all’interprete di creare una performance view, che può essere di due tipi: pixel  e grid. In pratica queste due tipologie fanno riferimento al modo di specificare le dimensioni per l’interfaccia che stiamo creando, specificandole in pixel o in righe e colonne (considerandola una matrice appunto).

Partiamo dal metodo più semplice, una performance view specificata in grid mode. Una interfaccia specificata con il metodo matriciale secondo Kontakt è composta da 16 colonne e al più 16 righe. Ogni cella dell’interfaccia è identificata da una coppia di coordinate, il numero di riga e il numero di colonna. Per specificare le dimensioni di una interfaccia si usa la funzione:

 

set_ui_height()

 

passando in ingresso il numero di righe desiderate, visto che il numero di colonne è fisso. Facciamo un esempietto va’…tanto per gradire. Editor alla mano:

Dimenticavo, naturalmente un’interfaccia va dichiarata nella on init. Salvando l’esempio mostrato e cliccando su “Apply”, noterete come l’area grigia al di sopra dell’editor venga espansa. Quella è l’area in cui compariranno man mano i controlli che andremo a programmare. Uscendo dalla fase di edit del nostro strumento noterete come l’area da esso occupato all’interno del workspace Kontakt sia aumentata in funzione delle nuove dimensioni specificate.

Analizziamo ora come specificare la dimensione dell’interfaccia in pixel. Niente di più facile: va utilizzata la funzione

 

set_ui_height_px()

 

passando in ingresso il numero di pixel in altezza (la lunghezza è comunque invariata). Provando a modificare l’esempio precedente si ha:

Posso già immaginare le vostre considerazioni: “Ma perchè dovrei andare a ragionare a livello di pixel? E’ tanto comoda la gestione a matrice…”. Vero, ma ci sono casi in cui l’interfaccia è particolarmente complessa è occorre specificare la posizione dei vari componenti al millesimo o, comunque, in un modo non compatibile con le possibilità offerte da un posizionamento per cella.

Ok, abbiamo la nostra meravigliosa area dove iniziare ad inserire controlli, iniziamo a divertirci. Prima domandina, come pensate che siano gestiti i controlli dal punto di vista di Kontakt? Ma è naturale…con delle variabili da dichiarare e utilizzare. E difatti nel metodo on init avviene normalmente la dichiarazione dei componenti grafici che intenderemo adoperare. Da notare che le variabili associate ad oggetti di un’interfaccia hanno  tutte il prefisso ui_

Ecco i principali componenti:

  • ui_knob – potenziometro rotativo
  • ui_slider – slider orizzontale
  • ui_label – etichetta testuale
  • ui_button – pulsante
  • ui_menu – menu a tendina
  • ui_switch – interruttore on/off
  • ui_table – interfaccia tipicamente utilizzata per step sequencers e arpeggiatori
  • ui_file_selector – file selector
  • ui_level_meter – misuratore di livello di segnale
  • ui_text_edit – campo di testo editabile
  • ui_value_edit – campo di selezione di valori
  • ui_waveform – (carino questo ma disponibile solo per Kontakt 5) display di forma d’onda
Per utilizzare uno di questi meravigliosi oggettini si deve procedere alla dichiarazione, come accennato, nel seguente modo:
declare ui_knob $NOME_VARIABILE(,,)
passando tra parentesi il numero di parametri in funzione del tipo di componente che andiamo a dichiarare, naturalmente. La lista di parametri per ogni componente grafico è disponibile ben documentata nel manuale dello scripting di Kontakt, il KSP per gli amici (buoni, alla fine verrà reso disponibile anche quello, per i fedelissimi). Nel caso del potenziometro abbiamo bisogno di tre parametri, questi:
  • min = valore minimo
  • max = valore massimo
  • display-ratio = divisione del range in steps
asd
Facciamo una prova e vediamo che viene fuori:
Carino no? Il codice prodotto ha avuto come effetto quello di far comparire un simpatico potenziometro rotativo che procede in cento steps dal valore 0 al valore 100. Proviamo ad aggiungere una bella etichetta (label per gli amici), tanto per complicare un po’ le cose e giocare maggiormente con nuovi parametri. Per utilizzare una label effettueremo la seguente dichiarazione:
declare ui_label $myLabel (, )
avendo cura di passare in ingresso alla funzione due parametri, la lunghezza e l’altezza da un punto di vista matriciale. Nel caso in esempio diciamo che la nostra bella label la vogliamo lunga 2 celle e posizionata a partire dalla prima cella in altezza. Ecco l’effetto:
Proviamo a cambiare la posizione dei controlli creati: ci viene in aiuto al funzione move_control() alla quale passare la variabile associata al controllo da spostare, la colonna e la riga (disposizione matriciale). Così se ad esempio volessimo spostare il potenziometro sotto la label per muoverlo in seconda riga e prima colonna, dovremmo inserire la seguente riga di codice:
move_control($myKnob,1,2)
Avete notato che il potenziometro e la label assumono come nome lo stesso della variabile associata a ciascuno di essi? Non è molto funzionale ai fini della realizzazione della nostra interfaccia. Mediante la funzione set_text() possiamo rinominare a livello di interfaccia i nostri componenti. Facciamolo:
set_text($myKnob, “Girami!”)
set_text($myLabel,”Questa è una etichetta”)
Il risultato finale è riportato in figura:
Mentre l’interfaccia finale si presenta così
Come di consueto, il codice sorgente d’esempio è disponibile per il download qui. Il suggerimento è quello di scaricarlo, aprire Kontakt e giocarci consultanto la guida. Come dite? Non ce l’hai data? Presto fatto, eccola (link al KSP)
Nella prossima puntata complicheremo ulteriormente il nostro esempio programmando qualcosa di simile ad un caso reale di utilizzo…il divertimento è garantito.
Stay tuned!

Tags: , ,

Trackback from your site.

Leave a comment

Inserisci il numero mancante: *