UNIVERSITÀ DEGLI STUDI DI MILANO - LIM | Laboratorio di ...
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
UNIVERSITÀ DEGLI STUDI DI MILANO
FACOLTÀ DI SCIENZE E TECNOLOGIE
DIPARTIMENTO DI INFORMATICA
GIOVANNI DEGLI ANTONI
Corso di Laurea triennale in
Informatica Musicale
welco
SVILUPPO DI UNA APP ANDROID PER LO
STRUMENTO INTERATTIVO KIBO
Piccola guida per gli studenti in
Relatore: Prof. Luca Andrea Ludovico
Correlatore: 2019-2020
Prof. Adriano Baraté
Tesi di Laurea di:
Gabriele Morabito
Matr. Nr. 873045
anno accademico 2020-2021
Questo lavoro è dedicato a tutti quelli che stanno in fissa
“Amici, dai smezziamo la benzina
che è la musica,
la musica, la musica.”
– Stefano della Grotta in "A fari Spenti" by CaligoBenk
i
Ringraziamenti
Un ringraziamento alla mia famiglia che, nonostante tutto, è sempre in grado di
privilegiarmi di una fiducia cieca e impagabilmente disinteressata.
A Mattia d’Amico ed Emanuele Namias, che dall’inizio di questo percorso han-
no prestato la massima attenzione per non farmi sentire solo e per aiutarmi nel
mio lavoro.
Alla professoressa Ciaravolo e alla professoressa Robotti, che si sono accollate
la noia di insegnarmi a leggere, di aiutarmi a capirmi, di aiutarmi a crescere, di
avermi accompagnato, di discutere con me, di essere delle amiche. Non esistono
parole per esprimere la mia gratitudine.
Alle mie amiche e ai miei amici, che sono il bene più prezioso che ho, senza di
voi sarei un fuoco spento.
A Funkylized, un giorno ti troverò.
Al Nurapolis, che conserva la mia libertà.
Al Bardolino, che conserva il mio cuore.
Ai CaligoBenk, con voi ho vissuto probabilmente tra i momenti più eccitanti
della mia vita, le mie bacchette sono inutili senza di voi.
A Piero e Tobe, sono grato di avervi incontrato tra le file dei banchi.
A Francesca, sei la mia fortuna più grande.
ii
Indice
Ringraziamenti ii
Indice iii
1 Introduzione 1
1.1 Obiettivi e motivazioni . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Stato dell’arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Kodaly srl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Progetto e organizzazione della tesi . . . . . . . . . . . . . . . . . . 6
2 Tecnologie utilizzate per lo sviluppo 7
2.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Introduzione al Sistema Operativo . . . . . . . . . . . . . . . 7
2.1.2 L’architettura del sistema operativo Android . . . . . . . . . 8
2.1.3 Ambienti e linguaggi per lo sviluppo di applicazioni Android 9
2.1.4 Concetti chiave per lo sviluppo di applicazioni Android . . . 10
2.1.5 Gestione delle risorse e degli assets . . . . . . . . . . . . . . 13
2.1.6 L’interfaccia grafica di una applicazione Android . . . . . . . 14
2.2 Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Il Kibo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 L’applicazione “Kodaly Alpha” 20
3.1 Introduzione agli obiettivi, al target e alle funzionalità . . . . . . . 20
3.2 La struttura dell’applicazione . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 La struttura delle Activity . . . . . . . . . . . . . . . . . . . 22
3.2.2 Le modalità di utilizzo . . . . . . . . . . . . . . . . . . . . . 28
3.2.3 Le componenti logiche dell’applicazione . . . . . . . . . . . . 29
4 Conclusioni 33
4.1 Considerazioni e problemi riscontrati . . . . . . . . . . . . . . . . . 33
4.2 Stato del progetto e sviluppi futuri . . . . . . . . . . . . . . . . . . 34
iii
Bibliografia 37
iv
Capitolo 1
Introduzione
Sin dalla nascita del primo smartphone touch che prendeva il nome di Simon,
un dispositivo progettato dalla IBM arrivato sul mercato nel 1993/1994, e dallo
stravolgimento del mercato della telefonia mobile con l’arrivo del primo iPhone
di Apple nel 2007, divenne molto chiara la potenzialità di cui questi strumenti
disponevano.
L’utilizzo degli smartphone oggi si riconosce in una quantità quasi indefinibile di
funzionalità differenti: messaggistica, monitoraggio delle funzioni del corpo, ap-
prendimento, sostituzione di strumenti fisici, etc.. Tra le caratteristiche che con
molta probabilità hanno definito il successo di questo mezzo, così per come lo
intendiamo oggi, troviamo la portabilità e la versatilità; queste hanno permesso
che in breve tempo lo smartphone, dall’essere uno strumento innovativo e di facile
utilizzo, divenisse uno strumento indispensabile.[1]
Come nel resto delle dimensioni, anche in quella della musica avvenne una rivolu-
zione in tal senso; gli smartphone hanno permesso agli utenti di avere un accesso
rapido e semplice a funzioni per cui prima era necessario un grado di impegno
relativamente maggiore, come ad esempio la possibilità di accedere a tablature e
spartiti, di accedere a testi, di ascoltare musica, di creare playlist, di riconoscere
un brano, di accordare strumenti, di ascoltare la radio, finanche la possibilità di
utilizzare lo smartphone come strumento musicale; tutto questo in qualsiasi mo-
mento e luogo, letteralmente a portata di mano. [2]
In questo documento si espone il risultato del processo di sviluppo di Kodaly
Alpha, una applicazione Android per l’interfacciamento allo strumento interattivo
Kibo di proprietà intellettuale della azienda Kodaly srl.
Il Kibo, coerentemente con gli orientamenti aziendali della Kodaly srl, è uno stru-
mento musicale che matura con l’intento di essere, per soggetti quali bambini,
disabili cognitivi e fisici, e persone in generale povere di conoscenze musicali, un
mezzo attraverso cui esprimere se stessi senza avere particolari conoscenze teoriche
1
CAPITOLO 1. INTRODUZIONE 2
della musica.
1.1 Obiettivi e motivazioni
Sono moltissimi i letterati e i pensatori che hanno scritto del ruolo che la tecno-
logia riveste nei confronti dell’esistenza e della vita dell’uomo, dal filoso Umberto
Galimberti allo scrittore Yuval Noah Harari. Tra le diverse correnti di pensiero
si rivela costante il punto di incontro nella messa in discussione della logica del
prometeismo, che vede la tecnica come possibile strumento di illimitato controllo
sulla natura da parte dell’uomo. Riassumendo all’estremo, il pensiero che ne risul-
ta, e che io personalmente condivido, si può delineare nella frase "tecnologia come
mezzo e non come fine", ovvero l’idea che, nonostante lo sviluppo della tecnica
abbia aperto scenari e possibilità in passato neanche immaginabili, come scrive
Umberto Galimberti, "La tecnica di per se non tende a uno scopo, non promuove
un senso, non apre scenari di salvezza", il fine e le necessità sono ancora carat-
teristiche che, in questa relazione, appartengono all’uomo e che, in funzione del
criterio di giudizio dei singoli individui, possono avere accezioni positive e negative.
L’obiettivo con cui il progetto è iniziato era quello di progettare e sviluppa-
re una applicazione che fosse in grado di interfacciarsi via BLE (Bluetooth Low
Energy) con il Kibo e che implementasse delle funzionalità coerenti alle sue ca-
ratteristiche di utilizzo di cui successivamente verrà trattato. Le motivazioni che
mi hanno spinto a raccogliere lo spirito e la sfida proposta dal LIM (laboratorio
di informatica musicale) riguardano, da un lato l’intenzione di avvicinarsi ad un
ecosistema florido e costantemente in espansione come lo è Android ed in secondo
luogo l’interesse riguardante la componente di scopo umanistico e di ricerca ap-
partenente al progetto portato avanti dalla Kodaly srl.
1.2 Stato dell’arte
Sono molteplici le applicazioni, sviluppate sia per Android che per iOS, che per-
mettono all’utente di utilizzare il proprio dispositivo come strumento musicale o
che permettono attraverso di esso di interfacciarsi ad un controller di vario genere,
tra le più note troviamo l’applicazione NOISE della ROLI che permette la simu-
lazione del noto touchpad prodotto dalla ROLI e il collegamento via Bluetooth e
via USB con un dispositivo fisico;
CAPITOLO 1. INTRODUZIONE 3
(a) Roli touchpad (b) Applicazione Noise
Figura 1: Relazione tra lo strumento fisico della Roli e la applicazione Noise
Nel caso specifico del Kibo è necessario fare riferimento all’applicativo intito-
lato “Kodaly” messo a disposizione dalla Kodaly srl sull’app store di iOS; questo,
durante lo sviluppo, è stato il riferimento su cui si è basata la realizzazione del-
l’applicazione Kodaly Alpha.
Al seguente link è possibile trovare l’applicazione disponibile per iOS: https:
//apps.apple.com/it/app/kodaly/id1456795017.
L’applicazione Kodaly mette a disposizione diverse funzionalità quali:
• La possibilità di connettere l’app via BLE e via cavo sino a sette diversi
dispositivi Kibo.
• La possibilità di simulare il comportamento del Kibo attraverso l’applicativo
• Diversi modi di utilizzo
• Diversi banchi di suoni
• La possibilità di indirizzare ad un altro dispositivo messaggi MIDI via p2p.
In generale i modi di utilizzo che l’applicazione implementa, al fine di sfruttare
le caratteristiche proprie del Kibo, si distinguono in tre differenti scenari:
• Tastiera Avanzata: in questo contesto, a ciascuna forma corrisponde la nota
di una scala predeterminata; essendo otto le forme disponibili sul Kibo, sono
otto le notte appartenenti a ciascuna scala.
Una similitudine interessante relativa a questa funzionalità è quella che si
potrebbe trovare con l’Hang Drum o più banalmente con una chitarra dotata
di una accordatura aperta, dove le corde suonate senza pressioni sulla tastiera
producono suoni tendenzialmente in armonia e coerenti tra di loro.
CAPITOLO 1. INTRODUZIONE 4
• Strumento percussivo: in questa dimensione ad ogni forma è collegato un
suono che si può manifestare come una sequenza ripetuta o come un singolo
suono percussivo.
• DJ Console: in questo terzo scenario viene data la possibilità all’utente di
utilizzare il Kibo come una console attraverso cui mutare e un-mutare le
componenti strumentali di un brano preselezionato associate ad ogni forma
del Kibo. Quando una forma viene inserita nella sua posizione viene un-
mutato il loop relativo e, nel caso in cui non lo sia già, viene inizializzato
il brano con tutti gli altri strumenti in muto; nel momento in cui invece la
forma viene disinserita questo viene mutato. [3]
In riferimento alle motivazioni sopra esposte, ovvero la possibilità di offrire un
mezzo di assistenza nell’espressione musicale di un bacino di utenza che comprende
persone con disabilità cognitive e fisiche, risulta enorme il vantaggio che porterebbe
l’estensione di questo strumento su Android, essendo questo il sistema operativo
staticamente maggiormente distribuito sulla popolazione.
1.3 Kodaly srl
Le informazioni riguardo alla Kodaly srl riportate in questa sezione sono il risultato
di un’intervista da me condotta in data 27/12/2020 a Mattia d’Amico, cofondatore
della società.
La Kodaly srl è una società a responsabilità limitata che si costituisce startup
innovativa a vocazione sociale nel dicembre del 2018. I fondatori sono Emanuele
Namias, nel ruolo di ingegnere gestionale, e Mattia d’Amico, ideatore, progettista
hardware e sviluppatore.
Per comprendere quali sono le condizioni che hanno posto le basi per la creazione
di questo progetto è funzionale considerare il fatto che Mattia d’Amico nel 2014
è stato cofondatore di Officine Tesla che, come mostrato nel loro sito web, si
dichiara “Associazione Culturale senza scopo di lucro, allo scopo di promuovere
l’educazione alla qualità d’ascolto attraverso lo sviluppo di tecnologie musicali per
favorire l’inclusione sociale e lo scambio culturale” [4].
Partendo da simili presupposti la Kodaly si forma con l’obiettivo di sviluppare
tecnologie musicali adattive nei confronti degli utenti, così da rendere la possibilità
di espressione attraverso strumenti musicali alla portata di tutti.
CAPITOLO 1. INTRODUZIONE 5
Per meglio descrivere quali sono le caratteristiche e gli intenti della società,
riporto di seguito un estratto dell’intervista condotta:
Gabriele: Come immagini un futuro in cui la Kodaly ha raggiunto un ruolo di spicco
nel contesto in cui opera?
Mattia d’Amico: Innanzitutto mi immagino un mondo con più creatori e meno spettatori.Vedo
una società dove la creatività delle persone è fondamentale, se non addirittura
necessaria. Spero che gli strumenti che verranno prodotti in futuro saranno
intelligenti e adattivi rispetto alle caratteristiche, le possibilità e alle capacità
delle persone.
Gabriele: Dire che la Kodaly è una società che offre prodotti e servizi nel campo della
didattica è scorretto?
Mattia d’Amico: No, la visione è quella di poter dare a tutti la possibilità di esprimersi at-
traverso la musica e l’utilizzo degli strumenti musicali. Una persona quando
è privata dell’esperienza musicale e di conseguenza di tutta la complessità
emotiva che ne deriva, è una persona con delle disabilità; il che non significa
saper suonare il violino come paganini quanto più sapersi emozionare come
si emozionava paganini suonando. Il Kibo vuole essere una prima esperienza
con le tecnologie musicali.
Noi siamo orientati ad una fetta di mercato che è quasi abbandonata dal-
le tecnologie, questo significa che ancora sono troppo pochi gli strumenti
per bambini e disabili rispetto a quanti ce ne sono per amatori e musici-
sti professionisti. Noi è li che andiamo perchè ci sono le sfide più difficili da
superare.
Gabriele: Al momento quali sono i servizi che la Kodaly offre?
Mattia d’Amico: Allora... noi facciamo produzione, consulenza, ricerca e sviluppo.
I prodotti che offriamo sono di tipo hardware, software e progettuale. Fac-
ciamo formazione a docenti che non sanno nulla di musica e vorrebbero in-
tegrarla nella propria didattica utilizzando strumenti intuitivi e alla propria
portata.
L’altro giorno per esempio abbiamo preso un accordo con ******** per un
contenuto che verrà distribuito digitalmente e che sarà utile per la formazio-
ne alla didattica musicale per i docenti.
Per arrivare a questo stadio c’è stato molto studio riguardo alla cimatica e
della psicologia della Gestalt (studio della percezione delle forme, basato sul
bianco e nero, nonché motivo per cui il logo e i colori sono così).
Gabriele: Che cosa significa Kodaly?CAPITOLO 1. INTRODUZIONE 6
Mattia d’Amico: Kodaly è il nome di un metodo per l’insegnamento del canto corale ed è inoltre
un nome che mi porto dietro da quando sono bambino per via del fatto che
mio padre era un insegnate di coro. L’ho scelto non tanto per i suoi contenuti
quanto più perché è qualcosa di inerente all’educazione musicale.
Gabriele: E Kibo invece? che significato ha questo nome?
Mattia d’Amico: Kibo invece è un nome che deriva dall’ambito informatico: quando eravamo
ragazzi nel giro dei LAN party c’erano tanti modi di sintetizzare alcune parole
ricorrenti, come ad esempio "Mobo" che sta a significare Motherboard; invece
Kibo non è altro che il diminutivo di Keyboard. Successivamente mi sono
accorto che potrebbe sintetizzare molti termini che si adattano bene al suo
scopo, come ad esempio Kidboard.
1.4 Progetto e organizzazione della tesi
L’intero processo per arrivare a questo risultato, compreso di fase di studio e
comprensione del dominio, è durato circa dieci mesi.
Questo processo si è strutturato in quattro diverse fasi:
• Fase di studio del sistema Android e degli ambienti di sviluppo.
• Fase di ricerca e scelta degli strumenti per lo sviluppo dell’applicativo.
• Studio di fattibilità, progettazione e sviluppo.
• Scrittura dell’elaborato finale.
I successivi capitoli che compongono questo elaborato sono disposti come segue:
• Nel secondo capitolo verranno presentate ed analizzate tutte le tecnologie
utilizzate per lo sviluppo dell’applicazione; in particolare si estenderà un
approfondimento su Android, sul Bluetooth Low Energy e sul Kibo.
• Nel terzo capitolo verrà raccontato in particolare il modo in cui l’applicazione
è stata sviluppata, come si struttura e quali sono le sue funzionalità.
• Nel quarto capitolo si discuterà di quali sono gli obiettivi raggiunti, di al-
cune considerazioni nate durante lo sviluppo e dei possibili sviluppi futuri
dell’applicazione.Capitolo 2
Tecnologie utilizzate per lo sviluppo
In questo capitolo verranno illustrate ed introdotte le tecnologie che sono state
utilizzate per lo sviluppo dell’applicazione, verrà chiarito come si struttura il si-
stema Android, quali strumenti mette a disposizione degli sviluppatori ed infine
verrà spiegato il funzionamento del device cui l’applicazione fa diretto riferimento,
il Kibo.
2.1 Android
2.1.1 Introduzione al Sistema Operativo
Android è un sistema operativo per dispositivi mobili basato sul kernel Linux, svi-
luppato originariamente da una piccola azienda, la Android Inc; è stato acquistato
e migliorato dal 2005 da Google LLC. [5]
Come dichiarato su NET MARKETSHARE, Android è il sistema operativo per
dispositivi mobili più diffuso in assoluto, con una fetta di mercato dichiarata al
momento al 71,24% sul totale e seguito da iOS con il 28,26% [6].
Una delle caratteristiche più rilevanti, e che in parte giustifica l’enorme successo
del prodotto, è che Android, secondo le volontà dei suoi proprietari, è distribuita
in modalità open source secondo i termini della licenza libera Apache 2.0, il che
significa che tutti coloro che vogliono utilizzare il sistema operativo possono farlo
direttamente attraverso il codice sorgente messo a disposizione.
Le complicazioni e i costi enormi che deriverebbero dal mantenimento e dallo svi-
luppo di un sistema operativo ex novo hanno portato sempre più aziende produt-
trici di dispositivi informatici all’utilizzo di Android come piattaforma di partenza
per la creazione di versioni dello stesso, bilanciate perfettamente per i propri hard-
ware.
Ad oggi i dispositivi Android hanno esteso la loro ragion d’essere ad una forma
7CAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 8
estremamente più variabile di come inizialmente concepita; tra questi possiamo
trovare smartphone, tablet, e-reader, netbook, lettori MP4, smart TV e disposi-
tivi indossabili. Un altro fattore che ha determinato il successo di Android è la
grande comunità di sviluppatori che, fermentando sin dai tempi della sua nasci-
ta, oggi semplifica l’accesso ai novizi che si affacciano al sistema creando così un
positivo circolo virtuoso.
2.1.2 L’architettura del sistema operativo Android
Prima di iniziare ad approfondire il funzionamento e le caratteristiche del sistema
operativo, risulta interessante osservare l’architettura che lo definisce (fig.2).
Figura 2: Architettura del sistema Android
Come possiamo notare, il sistema operativo è suddiviso in cinque sezioni su
quattro livelli:
• Il kernel Linux: in italiano "nocciolo", è la componente principale del si-
stema operativo, l’interfaccia che si frappone tra l’hardware ed i processi in
esecuzione di cui viene diretta la gestione delle risorse e la comunicazione.CAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 9
• Le librerie: Android comprende un set di librerie native realizzate in C e
C++, esse contengono il codice necessario per il corretto funzionamento
ed utilizzo del sistema operativo; ad esempio, tra queste troviamo librerie
dedicate alla navigazione sul web o alla gestione dei file multimediali.
• Android runtime: fornisce un insieme di librerie che consentono agli svi-
luppatori di implementare applicazioni Android utilizzando il linguaggio di
programmazione Java. In questa sezione è inclusa inoltre la Dalvik Virtual
Machine una derivazione della Java virtual machine ottimizzata tra le varie
cose per sfruttare la scarsa quantità di memoria presente nei dispositivi mo-
bili.
Dalla versione di Android 5.0 (Lollipop), la macchina virtuale Dalvik è
ufficialmente sostituita dalla runtime ART (Android RunTime). [7]
• Application framework: l’insieme dei servizi messi a disposizione degli svi-
luppatori dal sistema operativo per sfruttarne a pieno le potenzialità durante
lo sviluppo delle proprie applicazioni.
• Applications: l’insieme delle applicazioni installate all’interno del dispositivo.
2.1.3 Ambienti e linguaggi per lo sviluppo di applicazioni
Android
Se è possibile misurare il successo di un ambiente di sviluppo dalla quantità di
applicazioni disponibili per lo stesso, è appropriato affermare che Google ha effi-
cacemente raggiunto grandi obiettivi proprio in virtù di due “scelte” fondamentali:
l’utilizzo di Java di Sun Microsystem, un linguaggio di programmazione già am-
piamente conosciuto e padroneggiato da un largo bacino d’utenza, e dalla messa
a disposizione di molteplici strumenti per lo sviluppo. Tra questi, uno strumento
assolutamente degno di nota è Android Studio, un IDE(integrated developmente
environment) basato sul software di JetBrains IntelliJ IDEA, progettato specifica-
mente per lo sviluppo di applicazioni Android e disponibile per sistemi Windows,
Mac OS X e Linux. [7][8] Tra i vantaggi che l’utilizzo di Android Studio comporta
troviamo:
• Un sistema di compilazione flessibile articolato su Gradle per la building
automation;
• La possibilità di creare APK (Android Package) varianti e multiple;
• Strumenti per il monitoraggio delle prestazioni in esecuzione, compatibilità
di versione e problemi potenziali di vario tipo;CAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 10
• Ampio supporto ai servizi Google e ad ulteriori tipi di device;
• Un layout editor con un interfaccia grafica intuitiva e funzionale;
• Strumenti per il debugging dell’applicazione;
• Un emulatore integrato.
Come già detto, il linguaggio di programmazione utilizzato per lo sviluppo di
applicazioni Android è il linguaggio Java, nonostante questo Android mette a di-
sposizione un set di strumenti che permettono allo sviluppatore di scrivere codice
in linguaggio C e C++, l’NDK (Native Development Kit), che attraverso la Java
Native Interface puo’ essere richiamato dal proprio script in Java. Questo stru-
mento è di particolare interesse per chi sviluppa applicazioni che necessitano di
buone prestazioni audio, come ad esempio applicazioni musicali in real time. [9]
Per essere il più esaurienti possibile è necessario menzionare che nel Google I/O
2017, Google ha dichiarato Kotlin, un linguaggio open-source e multi-paradigma
sviluppato dalla JetBrains, come linguaggio ufficiale di Android affiancato a Java.
[10]
Una importante alternativa a questo tipo di approccio alla programmazione An-
droid, detta nativa, è quella cross-platform, un metodo di sviluppo che, partendo
da un’unica base di codice, permette la creazione di applicazioni eseguibili su dif-
ferenti sistemi operativi. Tra le piattaforme per lo sviluppo cross-platform più
affermate nell’ambito di applicazioni mobile troviamo Flutter e Xamarin.
2.1.4 Concetti chiave per lo sviluppo di applicazioni An-
droid
Se dovessimo stilare una lista degli elementi condivisi dalla totalità delle applica-
zioni Android, troveremmo questi quattro componenti [11]:
• Activity: le Activity sono le interfacce utente dell’applicazione; assumono lo
stesso ruolo che le pagine html hanno in una applicazione web. Generalmente
l’utente utilizza le Activity per entrare in contatto con tutte le funzioni che
l’applicazione mette a disposizione;
La figura 2 rappresenta una illustrazione molto famosa riportata sulla docu-
mentazione ufficiale fornita da Android la quale mostra il ciclo di vita di una
Activity. La classe Activity consta di sette metodi richiamati ciascuno in un
particolare momento del suo ciclo di vita.
Nel momento in cui viene attivata per la prima volta l’Activity verrà chia-
mata la funzione onCreate(), in questo contesto generalmente vengono pre-
parati tutti gli elementi utili al running dell’Activity; successivamente vieneCAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 11
Figura 3: Ciclo di vita di una Activity
chiamato il metodo onStart() che rappresenta il momento in cui l’Activity
viene mostrata a schermo, ai fini dello sviluppo può essere visto come un
secondo momento di preparazione dei contenuti della classe e un punto diCAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 12
ritorno dal momento in cui l’Activity non è più visibile all’utente. Il me-
todo onResume() viene chiamato quando l’Activity inizia ad interagire con
l’utente e viene richiamato anche nel momento in cui l’Activity torna ad es-
sere visibile in primo piano sul display; il metodo onPause() viene chiamato
nel momento in cui l’Activity finisce in secondo piano; il metodo onStop()
viene chiamato quando l’Activity non è più visibile dall’utente ed infine il
metodo onDestroy() viene chiamato prima che il sistema termini il proces-
so. E’ importante ricordare che Android non garantisce sulla resilienza del
processo, questo significa che nel momento in cui fosse necessario acquisire
memoria, il sistema potrebbe distruggere i processi attivi e quindi il metodo
onDestroy() potrebbe non essere mai chiamato.
• Service: nonostante i Service siano imparentati alle Activity in termini di
ereditarietà di classe, si può dire che questi svolgono un ruolo diametral-
mente opposto ad essi. Volendo fare una analogia con il mondo del teatro,
possiamo immaginare le Activity come il "palco", dove l’utente può comuni-
care direttamente con l’applicazione, che nel nostro esempio svolge il ruolo di
pubblico, mentre i Service invece sono le quinte, utili per i lavori di lunga du-
rata o addirittura indeterminata, effettuati in background senza una diretta
connessione con l’utente, come dichiarato dalla documentazione ufficiale.
I suddetti si differenziano in due tipi: gli started e i bounded.
– Gli started sono tipi di Service mirati ad uno scopo specifico, come
ad esempio la riproduzione di musica in background; la loro peculia-
rità deriva dal fatto che la durata della loro esecuzione è indefinita e
indipendente dalla componente chiamante.
– I bounded invece sono tipi di Service utili alla comunicazione tra ap-
plicazioni differenti. Essi permettendo l’interazione tra diversi processi
operando in modalità client-server; il che significa che il loro operato
dipende unicamente dalla chiamata di una componente esterna.
• Content Provider: i Content Provider sono una componente fondamenta-
le per la garanzia della sicurezza dei contenuti. Grazie ad essi è possibile
implementare una comunicazione sana tra le applicazioni, senza che queste
si invadano lo spazio in memoria reciprocamente con l’obiettivo di ottenere
contenuti.
Al fine di mantenere il sistema sicuro, è fondamentale che dei file e dei da-
tabase venga fornito l’accesso solo alle applicazioni che li hanno creati; il
Content Provider risulta essere proprio lo strumento con cui quest’ultime
condividono i propri contenuti con il sistema.CAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 13
• BroadcastReceiver: i BroadcastReceiver sono delle particolari componenti
sensibili alle chiamate in Broadcast di sistema. Un’applicazione che si occupa
di elaborazione delle immagini potrebbe per esempio implementare un Broa-
dcastReceiver che risponde alla richiesta del sistema, da parte dell’utente, di
modifica di una immagine.
Tra questi componenti si frappongono gli Intent, uno strumento chiamato dallo
sviluppatore per l’attivazione di uno o dell’altro componente. Di fatto gli Intent
sono un sistema di messaggistica gestito direttamente dal sistema operativo attra-
verso cui, in generale, è possibile effettuare tre operazioni: avviare una Activity,
avviare un Service o inviare un messaggio in broadcast. Gli Intent possono dunque
essere di due tipi:
• Espliciti: quando viene dichiarato specificamente quale delle componenti
dell’applicazione dovrà essere attivata.
• Impliciti: quando non viene dichiarato specificamente quale delle componenti
dell’applicazione dovrà essere attivata bensì solamente il tipo di operazione
che dovrà essere svolta.
2.1.5 Gestione delle risorse e degli assets
Le risorse di cui normalmente una applicazione Android può disporre possono
essere molteplici. In generale si può dire che le risorse per comodità sono gestite e
messe a disposizione dello sviluppatore in due maniere differenti:
• Le risorse indicizzate: tipicamente si trovano nella cartella res/, vengono
compilate in formato binario e possono essere richiamate attraverso un id
univoco. Le risorse più comuni di questo tipo sono: i layout, che attraverso
un codice xml definiscono la disposizione grafica dei componenti; i mipmap,
che rappresentano le icone dell’applicazione; i drawable, che sono immagini di
vario genere e formato; i values, che sempre in xml, costituiscono informazioni
quali stringe, colori, dimensioni, etc.
• Le risorse grezze: possono essere risorse di qualsiasi genere, come ad esempio
audio o video; esse al contrario non vengono compilate in formato binario.
Queste esulano dal sistema di indicizzazione applicato da Android per le ri-
sorse sopra indicate e sono collocate all’interno della cartella assets/ espli-
citamente dedicata a questo genere di contenuti.
Una classe java dedicata, che prende il nome di AssetManager, fornisce
all’applicazione la fruizione dei contenuti attraverso uno Stream.CAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 14
2.1.6 L’interfaccia grafica di una applicazione Android
L’espressione “interfaccia grafica dell’applicazione” indica l’insieme di componenti
visuali proiettati a schermo durante l’esecuzione dell’applicativo.
Prima di elencare quali sono le caratteristiche che contraddistinguono l’interfaccia
grafica di una app Android è importante evidenziare le modalità in cui è possibile
lavorare su di essa. Possiamo definire tre approcci allo sviluppo differenti:
• Il metodo dichiarativo: che prevedere la dichiarazione dei componenti e delle
loro caratteristiche in formato xml.
• Il metodo procedurale: che prevede la creazione e la definizione dei contenuti
attraverso il codice di programmazione utilizzato.
• Il metodo misto: che prevede una dichiarazione iniziale attraverso il formato
xml ed una eventuale modifica attraverso il codice di programmazione.
Un altro concetto fondamentale da introdurre per comprendere a pieno il fun-
zionamento dell’architettura grafica proposta dal sistema Android è la gerarchia
degli elementi a schermo comprendente View e ViewGroup.
Una View è una struttura dati per la memorizzazione delle diverse caratteristiche
presenti in una particolare area rettangolare nello schermo, la classe che la im-
plementa viene utilizzata per diversi widget già messi a disposizione da Android,
quali Button, radioButton, Text, TextEdit, Spinner, CheckBox, etc.
Una ViewGroup invece, come suggerisce il suo nome, è un aggregatore di diversi
elementi quali View e ViewGroup, la classe che la implementa è utilizzata come
base per il sistema di layout predefiniti messi a disposizione dal sistema.
Figura 4: Gerarchia delle ViewCAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 15
Una volta indicato ad una Activity il file xml contenente i dati relativi alla
rappresentazione grafica degli elementi, attraverso il metodo della propria classe
setContentView(), sarà possibile lavorare sugli elementi presenti direttamente
dal codice di programmazione.
2.2 Bluetooth Low Energy
Con l’avvento del Bluetooth 4.0 nel 2010 le modalità Bluetooth BR (basic rate),
EDR (Enhanced Data Rate) e AMP (Alternative MAC/PHY) si sono viste af-
fiancate dal Bluetooth Low Energy, una tecnologia wireless di tipo PAN (Personal
Area Network) progettata e messa in commercio dal Bluetooth Special Interest
Group (Bluetooth SIG), una associazione formatasi nel 1999 dalla collaborazione
di diverse aziende attive nel mercato informatico; tra i nomi più noti troviamo
Ericsson, IBM, Intel, Nokia, Toshiba, Microsoft, Lenovo e Apple. Più in generale,
lo scopo di questa entità è quello di controllare lo sviluppo degli standard Blue-
tooh.
La tecnologia BLE (bluetooth low energy) nasce con l’obiettivo di abbassare gli
elevati consumi energetici relativi all’utilizzo della comunicazione via Bluetooth e
di adattarsi strategicamente alle necessità di nuovi applicativi presenti in diversi
settori come la mobilità, l’assistenza sanitaria, la sicurezza, etc.
E’ opportuno menzionare che di recente la tecnologia BLE è stata adoperata per
lo sviluppo del sistema di Contact Tracing nativo su Android e iOS per la traccia-
bilità del virus Covid-19.
Da questo momento utilizzeremo il termine “ Bluetooth tradizionale” per in-
dicare le modalità precedenti e diverse dallo standard Bluetooth Low Energy. In
termini di banda radio, tra le due modalità non vi è alcuna differenza poiché en-
trambe operano nello spettro di frequenze compreso tra i 2.400 GHz e i 2.4835
GHz; la differenza tra queste sta nella metodologia per la modulazione e la demo-
dulazione sul livello fisico: questo impone che due dispositivi configurati per usare
rispettivamente Bluetooth LE e Bluetooth tradizionale non possono comunicare
reciprocamente.[12] Tuttavia generalmente gli smartphone di ultima generazione
sono dotati di chip bluetooth che sono in grado di sfruttare entrambe le modalità
di utilizzo grazie all’impiego di uno schema trasmissivo basato sulla multiplazione
a divisione di tempo cosicché il canale di comunicazione possa essere messo a di-
sposizione, a turno, dalle modalità Bluetooth tradizionale e BLE.
In termini di quantità di dati per secondo Bluetooth Low Energy è limitato
ad una trasmissione di 1 Mbit/s ed inoltre i dati vengono trasmessi adottando
pacchetti di piccole dimensioni (20 byte).CAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 16
Come già detto la caratteristica che rende questa tecnologia così utile sta proprio
nell’abbattimento dei costi energetici che il suo utilizzo comporta e che lo ren-
de perfetto per lo sviluppo di applicativi che necessitano di trasmettere piccole
quantità di informazione limitando così il consumo delle batterie dei dispositivi.
2.3 Il Kibo
Il Kibo è un controller MIDI costruito interamente in legno, basato su cpu ARM
Cortex a 32bit e composto da otto pad magnetici, otto forme di legno magnetiche
rimovibili ad essi collegati, una manopola ed un ingresso micro USB; tra questi
componenti il Kibo integra anche un accelerometro.
In termini tecnici il Kibo è di fatto un controller MIDI che, attraverso il protocollo
MIDI-over-Bluetooth, è in grado di comunicare con altri dispositivi midi (p.es.
sequencers e sintetizzatori).[3]
Figura 5: Kibo
Il suo design è derivato da uno studio effettuato dalla Kodaly nel campo della
cimatica, delle neuroscienze e della sinestesia musicale. Come è intuibile osservare
nella figura 5, nel Kibo ad ogni tasto corrisponde una particolare forma.
Queste caratteristiche sono orientate alla stimolazione simultanea di più aree del
cervello, caratteristica che incide sul grado di attenzione e che facilita l’apprendimento.[13]CAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 17
Figura 6: Rendering Kibo, pressione di un tasto
Alla pressione di ciascun tasto il Kibo invia un segnale MIDI di tipo NOTE
ON. Durante il mantenimento della pressione sul tasto vengono inviati dei messag-
gi AFTERTOUCH che ne descrivono la variazione di pressione. Infine quando
la pressione viene rilasciata dal tasto viene inviato un messaggio di tipo NOTE
OFF.
Figura 7: Rendering Kibo, inserimento formaCAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 18
All’inserimento di ciascuna forma nella sua sede viene inviato un messaggio di
tipo CONTROL CHANGE con valore 127 e successivamente un messaggio di
tipo NOTE ON. Al disinserimento del tasto viene inviato un messaggio di tipo
CONTROL CHANGE con valore 0 e successivamente un messaggio di tipo
NOTE OFF.
Figura 8: Rendering Kibo, inserimento formaCAPITOLO 2. TECNOLOGIE UTILIZZATE PER LO SVILUPPO 19
Per quanto riguarda il potenziometro invece, la figura 9 ne riporta tutti i
comportamenti derivati dai gesti effettuati dall’utente.
Figura 9: Rendering Kibo, il potenziometroCapitolo 3
L’applicazione “Kodaly Alpha”
In questo capitolo si discuterà di quali sono gli obiettivi e le caratteristiche del-
l’applicazione “Kodaly Alpha”, il modo in cui queste sono state implementate e la
struttura che ne definisce il comportamento.
Il titolo “Kodaly Alpha” è stato deciso in primis in riferimento all’applicazione per
iOS a cui è ispirata, in secondo luogo per il fatto che, in ambito informatico, il
termine “versione alpha” è utilizzato per indicare un software ancora in fase di
sviluppo di cui non sono state completamente implementate le ottimizzazioni e le
funzioni.
3.1 Introduzione agli obiettivi, al target e alle fun-
zionalità
Come suggerisce il titolo della tesi, l’obiettivo del progetto consiste nello sviluppo
di una applicazione che si interfacci genericamente con il Kibo.
Per fare un ulteriore passo e comprendere invece gli obiettivi dell’applicazione,
ovvero l’insieme di caratteristiche che rendono il prodotto utile e funzionale per
l’utente, è necessario prima ricordare che, come detto nella sezione 1.3, il target a
cui il Kibo si rivolge è composto principalmente di soggetti con disabilità o che non
possiedono alcuna formazione musicale; per questo motivo, idealmente, l’attenzio-
ne massima viene rivolta all’usabilità, l’intuitività e alla compatibilità, piuttosto
che alla complessità delle funzioni messe a disposizione.
Come detto precedentemente la progettazione e lo sviluppo dell’applicazio-
ne Kodaly Alpha prende fortemente ispirazione dall’applicazione Kodaly presente
sull’app store.
20CAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 21
E’ possibile suddividere le funzioni presenti all’interno dell’applicazione in tre
tipi:
• Funzioni riguardanti la connettività: l’insieme di funzioni utili alla gestione
della comunicazione via bluetooth con i dispositivi Kibo, come ad esempio
la ricerca, la connessione e la disconnessione.
• Funzioni riguardanti la suonabilità: l’insieme di funzioni concernenti le mo-
dalità in cui è possibile far suonare il Kibo.
• Funzioni riguardanti la gestione dei parametri: l’insieme di funzioni che
permettono la gestione dei parametri relativi alle diverse modalità sopra
citate.
3.2 La struttura dell’applicazione
In questa sezione verrà analizzata su diversi livelli la struttura dell’applicazione,
verranno ispezionati gli elementi che ne definiscono il comportamento e ne strut-
turano la logica.
L’applicazione è stata scritta completamente in linguaggio Java e attraverso l’u-
tilizzo dell’IDE Android Studio; per un corretto funzionamento richiede l’utilizzo
dei seguenti permessi:
• android.permission.BLUETOOTH: per attivare in generale qualsiasi tipo di
comunicazione bluetooth come la connessione ed il trasferimento dei dati.
• android.permission.BLUETOOTH_ADMIN poiché l’applicazione necessità di
gestire i parametri bluetooth e di effettuare una ricerca dei dispositivi dispo-
nibili.
• android.permission.ACCESS_FINE_LOCATION poiché il bluetooth può esse-
re utilizzato per ottenere informazioni relative al posizionamento del dispo-
sitivo.
La versione dell’SDK (Android Software Development Kit) minima supportata
dall’applicazione è la ventisei.CAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 22
3.2.1 La struttura delle Activity
Figura 10: Struttura delle Activity
La figura 10 riporta la struttura grafica dell’architettura dell’applicazione in fun-
zione delle sue Activity.
La SplashActivity
Come è possibile osservare, la prima Activity che viene chia-
mata dall’applicazione è la “ splash Activity”. Gli “splash
screen” o “launch screen” sono delle "schermate" mostrate
durante il caricamento dei dati che generalmente vengono
inoltre sfruttate per mostrare immagini o loghi relativi alle
aziende produttrici dei software.
Figura 11: Logo La splash activity in questione mostra infatti il logo della
Kodaly srl Kodaly srl (fig. 11), mosso e animato attraverso il pacchetto
android.animation messo a disposizione da Android; al toc-
co dello schermo o superati i tre secondi la splash activity
chiama automaticamente la MainActivity.CAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 23
Si riporta qui sotto un estratto del codice Java rispettivamente della chiamata
ritardata e dell’animazione del logo.
1 @Override
2 public boolean onTouchEvent ( MotionEvent event ) {
3 int v = event . getAction () ;
4 if ( v == MotionEvent . ACTION_DOWN ) {
5 screenIsPressed = true ;
6 Intent intent = new Intent ( g e t A p p l i c a t i o n C o n t e x t () ,
7 MainActivity . class ) ;
8 startActivity ( intent ) ;
9 return true ;
10 }
11 return false ;
12 }
13 void load_animations () {
14 new AnimationUtils () ;
15 logoAnimation = AnimationUtils . loadAnimation ( this ,
16 R . anim . logo_animation ) ;
17 logoAnimation . setInterpolator ( new L in ea rIn te rp ola to r () ) ;
18 logoAnimation . s e t A n i m a t io n L i s t e n e r ( listener ) ;
19 imageView . startAnimation ( logoAnimation ) ;
20 }CAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 24
La MainActivity
La MainActivity è l’Activity attraverso cui è possibile gestire tutti i parametri re-
lativi ai modi di utilizzo e da cui è possibile chiamare l’Activity dedicata all’utilizzo
del Kibo virtuale e l’Activity per lo scanning bluetooth.
Figura 12: MainActivityCAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 25
Come è possibile osservare nella figura 12 il layout della MainActivity si pre-
senta diviso in cinque sezioni; partendo dall’alto verso il basso:
• Il titolo dell’azienda.
• Due bottoni allineati a forma di Kibo utili per passare alle Activity ad essi
collegate.
• Una sezione per la scelta delle modalità di utilizzo e del banco suoni da
caricare.
• Una sezione dedicata alla gestione dei parametri relativi alla modalità scelta.
• Un campo di testo relativo alle informazioni riguardanti lo stato di connes-
sione dell’applicazione.CAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 26
Il VirtualKibo
Figura 13: VirtualKibo Activity
La VirtualKiboActivity è una Activity la cui interfaccia grafica simula il sistema
di pad e forme presenti sul Kibo. Disegnata in funzione di un orientamento oriz-
zontale, essa si presenta come una griglia di 4x2 bottoni interattivi.CAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 27
Come nell’utilizzo del Kibo, nella funzione SONG, di cui verrà successivamen-
te discusso il funzionamento, è simulato all’interno dell’Activity un sistema di
inserimento e disinserimento delle forme.
La ScanActivity
Figura 14: Scanner ActivityCAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 28
La ScanActivity mostrata in figura 14 è l’Activity preposta per lo scanning blue-
tooth dei dispositivi Kibo. Il suo layout è composto da due bottoni per l’avvio e
lo stop dello scanner e di una lista contenente i device Kibo trovati che, se pre-
muti, attivano la fase di connessione ad essi e conseguentemente il ritorno alla
MainActivity.
3.2.2 Le modalità di utilizzo
Discutendo sulle modalità di utilizzo è possibile innanzitutto evidenziare che l’ap-
plicazione può essere “suonata” dall’utente in due modi differenti e mutuamente
esclusivi:
• Attraverso la connessione via BLE ad un dispositivo fisico: attraverso que-
sto sistema è possibile suonare inviando messaggi MIDI direttamente da un
dispositivo Kibo.
• Attraverso l’utilizzo del Kibo virtuale: grazie a questo sistema è possibile
suonare utilizzando la simulazione del Kibo messa a disposizione dall’appli-
cazione; in questo caso i messaggi MIDI verranno sia inviati che ricevuti
all’interno dell’applicativo stesso.
Per ciò che concerne le modalità e le funzioni relative a come è possibile far
suonare l’applicazione, l’applicazione ne mette a disposizione tre:
• La modalità INSTRUMENT: questa modalità permette all’utente di utiliz-
zare il Kibo come uno strumento musicale nella sua forma più canonica, con
degli oggetti che riproducono dei suoni a diverse altezze, similmente ad una
tastiera di pianoforte. I suoi parametri sono:
– Il suono: la scelta del campione relativo allo strumento scelto; come ad
esempio una chitarra o un vibrafono.
– Il pitch, per indicare la tonica della scala.
– L’ottava
– La scala, poiché il Kibo possiede unicamente otto tasti è previsto che
suoni sempre scale di otto note
• La modalità BEAT: questa modalità permette all’utente di suonare il Kibo
triggerando loop in riferimento ai tasti premuti; al rilascio della pressione sul
tasto corrisponde l’interruzione del loop.
• La modalità SONG: permette all’utente di utilizzare il Kibo come un mixer at-
traverso cui, durante la riproduzione del brano scelto e grazie all’inserimentoCAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 29
e al disinserimento dei tasti, è possibile mettere rispettivamente in un-mute
e in mute il loop relativo al tasto utilizzato. Anche in questo caso l’unico
parametro previsto è il parametro “suono” che permette la scelta del brano
da riprodurre.
Tutti i contenuti audio presenti all’interno dell’applicazione sono di proprietà
esclusiva della Kodaly srl.
3.2.3 Le componenti logiche dell’applicazione
Figura 15: Audio Components System
La figura 15 riporta lo schema del sistema di funzionamento dei componenti audio
dell’applicazione. I componenti logici sono:
• Il Kibo: il device fisico che, in funzione dei comportamenti dell’utente, invia
dei messaggi MIDI al MIDI receiver.
• Il Virtual Kibo: che, simulando il Kibo, invia segnali MIDI dello stesso tipo
al MIDI receiver.CAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 30
• Il MIDI receiver: la componente che si occupa di ricevere i messaggi MIDI,
di processarli e di demandare al Player Manager di reagire in funzione dei
parametri da lui memorizzati.
• Il PlayerManager: la componente che si occupa di gestire tutti i parametri
inseriti dall’utente; come ad esempio la modalità di utilizzo e il suono.
1 public void play ( int note , int velocity ) {
2 // controlla modalita ’ utilizzo
3 switch ( getPlay_mode () ) {
4 // Se INSTRUMENT fornisci la scala
5 case INSTRUMENT :
6 play_note ( getScale_mode () [ note ] , note ,
7 velocity ) ;
8 break ;
9 /*
10 Se SONG inizializza tutti i loop e
11 mutali tutti tranne quello selezionato
12 */
13 case SONG :
14 if ( playing . isEmpty () ) {
15 initializes_song ( note , note ) ;
16 } else {
17 if ( isMute ( note ) ) {
18 unmute ( note ) ;
19 } else {
20 mute ( note ) ;
21 }
22 }
23 break ;
24 /*
25 Se BEAT inizializza il loop selezionato
26 */
27 case BEAT :
28 play_beat ( note , note ) ;
29 break ;
30 default :
31 throw new I l l e g a l S t a t e E x c e p t i o n (
32 " Unexpected value : " + getPlay_mode () ) ;
33 }
34 }
35
Come è possibile osservare dalla porzione di codice sopra riportata, una del-
le sue funzioni è quella di delegare al Player di suonare correttamente in
funzione dei parametri sopra citati.
• Il Player: la componente che si occupa di comunicare direttamente con il mo-
tore audio e di implementare alcune delle funzioni che quest’ultimo mette aCAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 31
disposizione. Può risultare interessante in questo contesto osservare nel det-
taglio alcune delle sue funzioni: ad esempio, per quanto riguarda la gestione
del pitch nella modalità INSTRUMENT, è stata implementata la variazione di
velocità di lettura del campione all’interno della funzione play().
1 public void play ( int note , int oct , int pitch , int
velocity ) {
2 double vel = velocityToDouble ( velocity ) ;
3 final double i n c r em e n t _ c o e f f i c e n t = 1.059463;
4 double indice_calcolo = Math . pow ( increment_coefficent
, ( note - 1) ) ;
5 double rate ;
6 int octave = oct ;
7 int octave_norm = Math . abs (4 - octave ) ;
8 octave_norm = ( octave_norm == 0) ? 1 : octave_norm ;
9 int c o e f f i c e n t e _ m o l t i p l i c a t i v o _ o t t a v a = octave_norm *
2;
10 double c o e f f i c e n t e _ m o l t i p l i c a t i v o _ p i t c h = Math . pow (
increment_coefficent , ( pitch ) ) ;
11
12 // set reading speed
13 if ( octave > 4) {
14 rate = sample . getFrameRate () * ( indice_calcolo ) *
( coefficente_moltiplicativo_ottava ) *
coefficente_moltiplicativo_pitch ;
15 } else if ( octave == 4) {
16 rate = sample . getFrameRate () * ( indice_calcolo ) *
coefficente_moltiplicativo_pitch ;
17 } else {
18 // set reading speed
19 rate = sample . getFrameRate () * ( indice_calcolo ) /
coefficente_moltiplicativo_ottava *
coefficente_moltiplicativo_pitch ;
20 }
21 ....
22 }
23
come è possibile osservare dalla porzione di codice, il sample rate, o velocità
di lettura del campione, varia in funzione di tre parametri:
– Il coefficiente incrementale di semitono: poiché nel temperamento equa-
bile un’ottava si compone di dodici semitoni equidistanti, il rapporto di
frequenza tra due semitoni adiacenti corrisponde alla radice dodicesima
di due, ovvero 1.059463.CAPITOLO 3. L’APPLICAZIONE “KODALY ALPHA” 32
– L’ottava: ad un incremento e ad un decremento di ottava corrisponde
rispettivamente un raddoppio e un dimezzamento della frequenza e di
conseguenza della velocità di lettura del campione.
– Il pitch
• Il motore audio / Jsyn: Per motore audio si intende la componente che si
occupa di gestire e mettere a disposizioni funzioni quali, la riproduzione di un
suono o la gestione del volume in output. Jsyn è una libreria Java realizzata
da Phil Burk disponibile con licenza Apache 2.0. Il paradigma utilizzato da
Jsyn è quello di unità singole che, se connesse, formano catene complesse per
la creazione di suoni eventualmente caratterizzati da effetti. [10]Capitolo 4
Conclusioni
In questo capitolo verranno analizzati i problemi e le complessità mostratisi nel
corso dello sviluppo dell’applicazione Kodaly Alpha e si discuterà degli eventuali
sviluppi futuri.
4.1 Considerazioni e problemi riscontrati
Tra le prime scelte fatte durante la progettazione del lavoro, è stata fatta quella di
non utilizzare il formato .sf2 (soundfont) per la gestione dei campioni, al contrario
invece dell’applicativo presente per iOS che invece utilizza proprio questo formato.
Un file in formato .sf2 è una struttura dati che raggruppa campioni PCM e una
serie di metadati riguardanti il posizionamento lungo le diverse ottave, eventuali
loop ed effetti sonori.
Uno dei motivi che mi ha spinto a non utilizzare questa tecnologia per lo sviluppo
dell’applicazione Kodaly Alpha riguarda in primis lo scarso risultato nella ricerca
di librerie sufficientemente intuitive e performanti, in secondo luogo il fatto che la
Kodaly srl stessa si è pronunciata positivamente rispetto all’utilizzo di un approc-
cio differente.
Uno dei problemi che spesso vengono evidenziati nello sviluppo di una appli-
cazione Android è quello riguardante la latenza audio.
Come è facile intuire, in una applicazione come lo è Kodaly Alpha, dove l’assunto
di base è che le funzioni debbano essere semplici ma performanti, questo problema
risulta amplificato poiché compromettente gli obiettivi essenziali dello sviluppo.
Sulla documentazione ufficiale di Android è esposto un capitolo completamente
dedicato alle high prerfomance audio in cui viene caldeggiato l’utilizzo di librerie
native in C++ quali AAudio e Oboe.
33CAPITOLO 4. CONCLUSIONI 34
Per ciò che concerne Jsyn è possibile dire che esso si presenta molto intuitivo
e ricco di funzionalità, ma per quanto riguarda l’implementazione su Android, in
termini di audio performance, potrebbe non essere la scelta più funzionale.
Un altro aspetto interessante nello sviluppo, riguarda il fatto che Android, al
contrario di iOS, è un sistema operativo installato su dispositivi mobili estrema-
mente differenti tra loro, dai dispositivi di fascia alta a quelli di fascia bassa con
prestazioni molto limitate. Inoltre è messo a disposizione da compagnie diverse con
distribuzioni diverse, come ad esempio MIUI sui dispositivi dell’azienda XIAOMI
oppure EMUI sui dispositivi HUAWEI e HONOR.
E’ importante dunque considerare nello sviluppo le differenze che l’applicativo
potrebbe manifestare su un dispositivo piuttosto che su un altro.
4.2 Stato del progetto e sviluppi futuri
Allo stato attuale delle cose, l’applicazione Kodaly Alpha è in grado di:
• Gestire tre differenti modalità di utilizzo: INSTRUMENT, BEAT e SONG.
• Nella modalità INSTRUMENT è in grado di parametrizzare fino a tre ottave,
dodici chiavi differenti e nove diverse scale:
– Scala Maggiore
– Scala Minore
– Scala Minore Armonica
– Scala Blues
– Scala Diminuita
– Scala Aumentata
– Scala Pentatonica Maggiore
– Scala Pentatonica Minore
– Scala Orientale Maggiore
• Stabilire una connessione via BLE con un device Kibo e suonare in funzione
dei segnali da esso inviati.
• Simulare graficamente e nel comportamento un device Kibo fisico attraverso
il sistema VirtualKibo.CAPITOLO 4. CONCLUSIONI 35
In termini di sviluppi futuri, prima di concentrarsi su funzionalità aggiuntive
sarebbe probabilmente più adeguato concentrare le risorse sull’ottimizzazione del
sistema audio. Sarebbe probabilmente appropriato sostituire all’utilizzo di JSyn
un motore audio più coerente con le disposizioni ed i consigli forniti dalla docu-
mentazione ufficiale Android.
Tra le priorità risulta evidente la necessità di lavorare per minimizzare la la-
tenza audio che, allo stato delle cose, si dimostra ancora sufficientemente elevata
da compromettere l’utilizzo dell’applicativo stesso.
Una feature già presente sull’applicazione Kodaly per iOS, che sarebbe necessa-
rio implementare anche nella sua corrispettiva per Android, riguarda la possibilità
di estendere la connettività a più di un device contemporaneamente fino ad un
massimo di sette. Questa funzionalità permetterebbe di avvicinare l’applicazione
all’utilizzo didattico, uno degli usi per cui essa è concepita.
Un’altra importante questione riguarda la gestione dei file audio.
Al momento il motore audio permette esclusivamente la lettura di file in formato
non compresso, il che prevede, poiché non è ancora stato implementato un sistema
di compressione e decompressione dei file, che l’apk contiene file audio in formato
.wav che appesantiscono notevolmente l’applicativo fino ad un superamento di
300Mb a fronte di una dimensione media delle applicazioni inferiore ai 50Mb.
Sarebbe opportuno che gli assets siano memorizzati in un formato compresso come
ad esempio il formato .mp3.Puoi anche leggere
