MorphLog: un blog di un certo livello

Dato che, strano ma vero, ho ricevuto richieste di vedere il software che ho sviluppato, ho pubblicato tutto qui.

Andate e prendetene tutti.

http://www.vimeo.com/4325822

Ammetto che è passato un po’ di tempo da quando ho scritto l’ultima volta della tesi, ci sono state di mezzo le vacanze, poi qualche altra preoccupazione ha deciso di flirtare a tre col mio tempo libero e la mia voglia di scrivere quello che stava accadendo, col risultato che io sono qua, faccio le cose, ma nessuno sa niente — e c’è anche chi giustamente si arrabbia.

Allora, eravamo rimasti al video figoso in cui io disegnavo delle cose in rosso e poi i rettangolini blu diventavano bianchi, giusto? WordPress mi conferma che è così, e quindi c’è una parte che manca all’appello.

Tanti piccoli accordi

Discutendo col prof — che infine ha dovuto mettermi un freno ché sennò gli fornivo idee per tre anni di progetti e non era bello — siamo giunti a due idee:

1. la mia proposta iniziale era di selezionare un accordo di base (es. G#7) poi selezionare uno stile musicale (es Blues) e poi selezionare una delle possibili progressioni Blues che cominciano — o contengono in qualche posizione — l’accordo selezionato. L’idea sarebbe stata anche buona ma effettivamente incasinata;
2. la sua controproposta è stata di costruire attorno al Tonalizer un “chord set”, ossia un insieme in cui l’utente inserisce degli accordi a sua discrezione, ordinabile, cioè che lui per conto suo si comporta come un insieme nel senso matematico, però sui suoi elementi si può costruire una sovrastruttura ordinata, che a noi che ci piace il pane con la soppressa piacerà chiamare “sequenza”. Questa sequenza andrà quindi suonata con tempi da definire, ma suppongo si andrà di multipli non per forza interi della battuta.

A quel punto la mia controcontroproposta è stata di non abbandonare per forza l’idea iniziale ma di semplificarla, nel senso che l’utente inserisce un accordo, questo viene preso come accordo di base (cioè, il primo di una progressione) e si mostrano tutte le progressioni che possono cominciare con quell’accordo. Poi l’utente ne inserisce un altro e si mostrano tutte le progressioni che cominciano con l’accordo di base e contengono da qualche parte il grado/modo del nuovo accordo relativo a quello di base, e via così col terzo, il quarto e tutti gli accessori.

Inserire gli accordi

E qui viene la parte interessante. Ci sono due paradigmi principali sul reacTable, che sono l’interfaccia tangibile di cui ho già parlato, e l’interfaccia a strisci e ditate di cui è pieno il mondo, YouTube e anche gli scaffali dei negozi. Per cui uno potrebbe pensare di sviluppare una serie di oggetti a rappresentare accordi, accidenti, gradi, modi, il tutto gioiosamente componibile in catene e… e dopo il terzo accordo è finito lo spazio sul tavolo.

L’opzione due è appena un po’ più vecchia dell’homo sapiens, e cioè si tratta di usare le dita per scrivere nomi, accidenti, gradi, modi e tutto quanto — dove per “tutto quanto” intendo la scelta di stili e progressioni, nonché la costruzione della famosa sequenza. Bello, dice. Mica facile, però. Questa eventualità va sotto il nome di handwriting recognition e ci sono sostanzialmente due sistemi su cui fare affidamento:

• data un’immagine con le scritte da riconoscere, si applicano le ben note tecniche di riconoscimento ottico (il famoso OCR) basate su algoritmi di varia complessità che vanno dalle più semplici correlazioni alle più sofisticate tecniche per la ricerca i feature invarianti alle trasformazioni.
• data una spezzata definita per punti sul piano 2D, si possono applicare varie tecniche più o meno fantasiose, a partire dalla ricerca di similarità tra NURBS fino a simpatiche deviazioni del problema della visibilità.

La mia situazione è questa: reacTIVision rileva le ditate e ne trasforma il movimento proprio in sequenze di punti. La seconda via è evidentemente la mia via, motivo per cui da un po’ di giorni mi sto industriando per cercare quanti più metodi diversi riesco a trovare. Averne più di uno mi garantirebbe due vantaggi: primo, inserire un po’ di algoritmica un minimo sofisticata per contentare chi non vive senza; secondo, poter confrontare i vari sistemi in termini di facilità d’uso, flessibilità e velocità. Per ora mi sto concentrando su un sistema di similarità tra NURBS e un sistema basato su superfici non convesse costruite  per triangoli.

• NURBS: l’idea di base è di costruire dei modelli di riferimento, uno o più per ciascun glifo diverso, e usarli per confrontare la NURBS costruita dai dati ricevuti dall’utente. In verità non voglio confrontare veramente le curve ma solo il loro guscio convesso formato dai punti di controllo. Supponendo di usare i punti che arrivano da reacTIVision, questo sono tipicamente tanti e sparpagliati, in generale molto diversi da un modellino bello come questo:(non è che questo sia bellissimo, ma è meglio di niente). Il trucco starebbe nel calcolare un’approssimazione della curva inferta dall’input umano con un certo numero fissato di punti di controllo il più possibile equidistanti tra loro. La domanda è: qualcuno ha idee? Perché, una volta che questo è possibile in modo sufficientemente veloce, posto che i glifi di riferimento siano stati costruiti in modo analogo, allora diventa molto facile confrontare punto per punto l’input con la lista dei glifi, diciamo nell’ordine di m·n passi con m il numero di glifi ed n il numero di punti di controllo.
  Ci sono diverse condizioni problematiche, tra cui come allineare la coppia per il confronto. Per esempio scegliendo di far combaciare i due estremi, si deve per forza ripetere due volte il confronto per ogni coppia, nel caso gli estremi venissero scambiati: con un po’ di immaginazione dovreste riuscire a capire cosa intendo guardando l’esempio sopra. Un altro problema derivante dall’allineamento degli estremi è l’imprecisione dell’utente che può far variare anche di molto il punteggio. Tuttavia sono fiducioso circa la buona diversità tra i glifi.
• Superfici triangolate: il secondo metodo su cui mi sto concentrando consiste nel prepare dei modelli in questa forma: e poi guardare quanti punti dell’input cadono dentro la superficie. Con questo metodo il problema dell’allineamento è ancora peggiore: occorrerebbe individuare dei punti nei cui intorni possono situarsi gli estremi dell’input. Tuttavia, una volta scelto un “buon allineamento”, la robustezza all’imprecisione dell’input è nettamente superiore (e modulata dalla larghezza della striscia) e c’è anche il vantaggio che non si devono fare calcoli complessi con polinomi di grado elevato bensì un più rapido e veloce test di appartenenza — velocità comunque mitigata dal fatto che ogni punto va testato con ciascun triangolo o al più con un “intorno” di triangoli. Il punto sta tutto nel trovare detto buon allineamento.

Naturalmente se avete suggerimenti a riguardo — anche per altri metodi sulla piazza — io sono disponibile e, in caso, vi guadagnereste un posto tra i ringraziamenti.

Gestire il set

Una volta costruito il set, costruire la sequenza è un compito abbastanza semplice: il dito collega gli accordi con una sorta di spezzata, reacTIVision fornisce il percorso del dito per punti con associata anche la velocità del dito in ogni punto. Assumendo che il dito “rallenti” quando fa tappa su un accordo, si può usare questa informazione per costruire la catena. O qualcosa del genere, ci penserò più avanti. La gestione automatica di stili e progressioni invece è molto più facile, si può sviluppare con una combo di glifi alfanumerici e liste visualizzate sul tavolo.

Sì, insomma, di cose da fare ce n’è. Mi sono fissato il 9 febbraio per avere tutte queste meraviglie pronte per il test — anche se più realisticamente la fine dello sviluppo cadrà nella relativa settimana e non proprio quel lunedì. E poi si vedrà, fino al 9 aprile c’è tempo per inventarsi altre meraviglie.

Mi segnalano che sabato 13 (cioè fra tre giorni) ci sarà questo concerto-conferenza di musica elettronica alla Chiesa della Spina di Pisa. Vabè, l’articolo del link contiene qualche imprecisione ma spero che almeno gli orari siano giusti.

Dato che so che tra di voi non mancano i nerd, anche se quelli che gravitano nelle zone limitrofe a Pisa sono in numero decisamente basso, io ve lo dico: c’è da vedere e sentire il reacTable — con una probabile chicca finale che mi auguro non farà scoppiare una crisi diplomatica ma solo una risata. Io, per ovvie ragioni, non ci potrò essere, ma se qualcuno ci va con una videocamera, poi che carichi il tutto su YouTube, almeno :)

EDIT: Mi segnalano che il concerto è andato benone e che la chiesta era così piena che molta gente è rimasta fuori. La chicca finale [1] è stata apprezzata e non mi risultano sommovimenti tellurici di alcuna intensità.

1. Che poi era la famosa uscita presidenziale “Santoro, lei è un dipendente del servizio pubblico: si contenga!” col “si contenga” a loop in dissolvenza. ↩

Nonostante tutto c’è anche chi si chiede cosa ci faccio qui, se sto solo a rimirare il muro di fronte o leggere Adams sui divanetti rossi del salottino — che sono comunque due attività che svolgo con un certo impegno. In realtà qualcuno lo sa già e gli altri l’avranno intuito, sono al Music Technology Group della Universitat Pompeu Fabra di Barcellona per fare la tesi specialistica e la settimana scorsa avevo perfino ventilato l’ipotesi di raccontare qualche dettaglio su quello che sto facendo.

Tangibilità

Allora, tanto per cominciare io ero partito con l’idea di lavorare con questo giocattolo qua e alla fine ci sono riuscito. Loro lo spiegano meglio di me, ma in sostanza il reacTable è uno strumento musicale collaborativo ad interfaccia tangibile. Su questo fatto della tangibilità uno ci può spendere miliardi di parole ma l’esempio che ho trovato più efficace è questo qui a sinistra: l’abaco. Uno vede il reacTable e dice “oh, ma è multitouch” e invece no. Il punto chiave è che nel multitouch come quello presentato da Surface o iPhone o fratellini più o meno vistosi è che l’utente sì riempie lo schermo di ditate ma di fatto l’informazione è convogliata esclusivamente attraverso quella lastrina traslucida lì, sia che uno impartisca un comando, sia che uno riceva feedback. Nella tangibilità invece l’informazione è contenuta e trasmessa anche attraverso oggetti che l’utente può fisicamente manipolare. Può tenerli in mano, può toglierli o metterli, girarli, riposizionarli, configurarli, immagazzinarci informazioni e portarle con sè e poi ok, può anche toccare il tavolo e vedere cosa succede, ma il trucco è che l’utente ha in mano l’informazione e la può far entrare o uscire dal computer attraverso gli oggetti.

reacTable

Questi qua — dove per “questi qua” intendo principalmente Sergi Jordà che, tra le altre cose, è il mio contatto di riferimento — sono partiti volendo creare uno strumento musicale elettronico ad interfaccia tangibile che non richiedesse molto tempo e sofferenza per essere appreso e per ottenere risultati di un certo livello. La cosa bella è che quando hanno iniziato non avevano la più pallida idea di come fare la cosa, sapevano solo che volevano mettere delle cose su un tavolo e cavarne suoni.

Il risultato era una bizzarra combinazione di software e hardware:

• un motore di visione open source che riconosce, traccia e passa al sintetizzatore audio quei cosini simili a quello lì a destra — sono dei fiduciary marker estremamente ottimizzati e veloci da riconoscere, comunemente chiamati amebe sia per via della forma, sia perché sono generati automaticamente attraverso una fila di algoritmi genetici di cui io non capisco niente — e, ovviamente, le ditate che servono per configurare i parametri dei vari oggetti;
• un sintetizzatore audio “scritto” in Pure Data che però non è open volutamente perché così chi vuole può farsi il suo con le sue caratteristiche — e comunque non è difficile da copiare;
• un sintetizzatore video scritto in C/C++ e OpenGL che neanche quello è open però vabbè, non è mica difficile neanche quello;
• una videocamera infrarosso;
• un proiettore per fornire feedback visuale.

Subito uno può pensare che sia brutto che solo il reacTIVision sia open ma poi pensandoci si capisce che è una scelta intelligente e sensata, perché è l’unico componente veramente general purpose che può dare un contributo anche ad altri progetti, mentre i sintetizzatori sono fondamentalmente giocattolini senza alcun interesse scientifico reale.

Musica

Tutto bello e tutto buono, il reacTable comincia a funzionare e ad attirare l’interesse della comunità di musicisti elettronici sperimentali — quelli che, per capirsi, tirano assieme suoni, rumori ed altre cose e li chiamano Ambient, risma di cui fa parte anche Mr. Jordà. La voce gira, l’interesse cresce, il tavolo si arricchisce di funzionalità, iniziano i concerti, le installazioni, le performance, compaiono i primi virtuosi, Björk decide che ne deve assolutamente avere uno e i musicisti tradizionali avanzano pretese.

Il punto è che il reacTable non è mai stato pensato come uno strumento per la musica tradizionale, quella fatta di temperamenti, altezze, tonalità, tempo e tutti gli accessori. Tuttavia si decide di accontentare anche loro e comincia lo sviluppo di un semplice metronomo centrale che dà il tempo a tutto il tavolo, un sequencer melodico che dev’essere programmato in anticipo, un tonalizer che è un coso in cui si impostano alcune note su una scala di dodici semitoni e lui impone quelle altezze per un po’ tutti gli oggetti che producono suoni “accordabili”, e qualche altro giochino.

Allo stato attuale c’è poca chiarezza su questi strumenti per musicisti tradizionali, anche dato che il core team non era inizialmente interessato questo aspetto [1].

Poi arrivo io

Che non sono un grande fan dell’Ambient e delle cose rumorose, quindi inizio a lavorare sull’aspetto tonalizer e sequencer melodico/temporale.

Tonalizer — L’oggetto che c’è ora ha una serie di preset selezionabili manualmente su cui si possono impostare alcune note mediante una tastierina piuttosto grossa e scomoda, dato che è sempre aperta. L’idea è buona in un certo senso ma a mio parere viola prima di tutto il requisito di non intimidazione (ok che è una richiesta dei musicisti ma, una volta che c’è, lo vorranno usare tutti, e una tastiera di pianoforte può spaventare l’inesperto). Poi è grossa. Molto grossa. In più per cambiare preset bisogna per forza mettersi a mano a girare l’oggetto, non c’è alcun meccanismo automatico — ché anche questo fatto dell’automazione è un punto cardine del progetto, nel senso che in uno strumento tradizionale il suono si produce per diretta e continuativa azione del musicista mentre in uno strumento elettronico il musicista controlla alcuni parametri e poi ci sono dei processi nel computer che producono il suono in modo più che altro indipendente, per esempio quando uno schiaccia play sullo stereo e parte un brano, non è che deve restare lì a tenere premuto il bottone.Ho avuto una fila di idee, alcune molto sbagliate, altre più che altro carine da vedere ma che poi si sono rivelate poco pratiche, e questa qui sopra è l’ultima — che però non è ancora stata passata la vaglio dato che il Mister è in tour mondiale col tavolo fino ai primi di Dicembre. A vederlo così non sembra molto più di quello che c’è già ma ha alcuni plus che secondo me lo rendono interessante.

1. i preset, quei cosini lì attorno, avanzano automaticamente, regolati dal metronomo centrale (a meno di multipli) o da un metronomo locale — anche chiamato “sequencer temporale”, di cui parlerò dopo. Permette di creare sequenze abbastanza lunghe (qui fino ad un massimo di sedici preset) e i preset non attivati (quelli scuri) vengono semplicemente saltati;
2. riconosce, se c’è, l’accordo impostato, deriva una scala — su questo punto sono abbastanza incerto data la mia ignoranza in materia — e impone agli oggetti accordabili le note di quella scala. Se uno vuole usare un sottoinsieme di note, e non tutte quelle della scala, può sceglierlo in qualche modo a cui non ho ancora pensato, oppure uno può anche scegliere di tornare alla modalità attuale in cui le note imposte sono tutte e sole quelle programmate;
3. nel disegno che ho fatto c’è una ottava di pianoforte (sì, lo so che non sembra, ma è un’ottava di pianoforte) che a me piaceva ma può non piacere ad altri. L’idea sarebbe che anche l’interfaccia per inserire le note sia selezionabile dall’utente, per cui uno può preferire quella lì, o due ottave o un pezzo di una qualsiasi tastiera isomorfa o un’allegra combriccola di funghetti, cuoricini e monetine (mi auguro di no) o chissà che altro.

Melodie — Quello che c’è ora è un oggetto con alcuni preset configurabili prima di usarlo. Si inseriscono gli eventi nel modo tradizionale dei sequencer MIDI (ok, solo le note, non credo supporti altri eventi e non credo nemmeno che sia necessario che lo faccia). In istanti che non ho capito come sono determinati, la sequenza di note parte, va verso un oggetto e lo istruisce sulle altezze da usare in un modo abbastanza fumoso e poco definito.La mia proposta qui mutua alcuni concetti dalla precedente — poi dice “sei pigro” ma la pigrizia, in questi casi, è una dote, non un difetto — però modifica la parte di inserimento per adattarla alle esigenze ovviamente diverse. Ok, questa non è molto elaborata, non ci ho pensato molto ma, per essere la prima cosa che mi è venuta in mente, non mi è sembrata del tutto male. Il “piano roll” compare e scompare in modo analogo al precedente, la quantità di eventi può essere cambiata e il numero di altezze è fissato dal tonalizer nel modo che ho già descritto. Uno può “disegnare” con un solo gesto la melodia in quel modo illustrato dalla curva nera (in un modo simile a come ShapeWriter scrive le parole, ovviamente senza il vocabolario prefissato), oppure con più gesti “spezzati” e pure schiacciare con le dita per attivare e disattivare certe note.

Tempo — Fin qui sia gli accordi che le melodie avanzano per intervalli tutti uguali. Aggiungere un sequencer temporale che, mediante impulsi, faccia “scattare avanti” i preset o le singole note delle melodie, creerebbe una sorta di sequencer “bidimensionale” con le due dimensioni separate in due oggetti diversi. Non ho pensato a questo fatto a sufficienza, quindi in realtà non ho alcuna idea precisa a riguardo. La prima ovvia osservazione è che potrebbe essere scomodo avere un sequencer temporale per regolare le durate delle singole note. L’altra ovvia osservazione è che si può aumentare o diminuire la granularità temporale del coso melodico selettivamente solo su alcune note (per esempio partire con otto divisioni che possono essere suddivise o unite) però ho paura che, anche se mi sembra un’idea passabile, finisca per occupare un sacco di spazio. Questo potrebbe anche tradursi nell’eliminare la necessità di un oggetto temporale esterno.

In definitiva

Questo è il prodotto delle mie prime tre settimane al MTG. Il punto è un altro, cioè che è già passato un mese e un altro passerà prima che possa rimettere le mani sul reacTable. Poi ho pensato un’altra cosa: non so se sia io ad avere una visione parziale del tutto o se sia Padova che spinge più su certi aspetti, dando quindi un’impressione che certe cose siano più importanti di altre, però mi pare che tutto questo sia poco “informatico”, nel senso che non coinvolge strettamente quello che mi è stato insegnato a pensare come informatico (algoritmi e dati, principalmente) ma è più nel campo dell’applicazione, dello sviluppo di interfacce e di interazioni… non so se sono io ma boh, ho l’impressione che faticherò a giustificare questa cosa con i docenti di Padova…

… e nel frattempo posso solo studiare per gli ultimi due esami — e godermi un po’ di più la città.

PS: C’è un’altra idea, che però c’entra poco, a cui sto pensando. Magari ve ne parlo un’altra volta.

1. “Abbiamo un metronomo, ma io non lo so usare nei concerti e al momento non c’è un modo facile per spegnerlo al volo…” mi ha detto sconsolato Mr. Jordà. ↩