domenica 8 luglio 2012

Strumenti info-musicali - I

L'anno scorso mi sono riavvicinato al mio amore giovanile: la musica; o, più precisamente: la composizione, l'esecuzione e la produzione di musica.
Ho ripreso la teoria, il pianoforte, la chitarra, la chitarra elettrica, il contrappunto e, con questo carico, mi sono avvicinato al computer e mi sono chiesto come aggiungere il mio ormai immancabile compagno alla banda.
Prima di tutto, dovendo recuperare la forma fisica e naturalmente scegliendo sempre la strada più "panoramica", ho deciso di scrivere un libro per chitarristi metal in erba che vogliano imparare a suonare la musica di Iron Maiden, con cui esercitarmi.
Poi, ascoltando le vecchie registrazioni (su audio-cassetta... ho detto vecchie!) del mio gruppo metal giovanile... l'illuminazione: riprodurre No Way dei Visions come one-man-band; e con "riprodurre" intendo "creare la partitura completa e registrare il brano".

Questi progetti hanno richiesto l'uso di molti strumenti informatici, sia editoriali che di produzione musicale; fra quelli software, che per scelta filosofica ho scelto fra quelli liberi (free, gratis), si annoverano programmi per la stesura di spartiti musicali, per la produzione di libri con contenuti musicali, per la produzione finale di materiale musicale audio (DAW - digital audio workstation). Data la quantità di argomenti, in questo articolo descriverò l'esperienza relativa alla produzione di un libro di musica, lasciando a successivi pezzi le altre non meno eccitanti avventure.

Requisiti di un libro di musica

Il libro che mi sono apprestato a comporre è un corso avanzato per chitarristi che vogliano imparare lo stile chitarristico degli Iron Maiden ai tempi del loro primo album: Iron Maiden.
L'album è stato scelto, oltre che per motivi affettivi, per la discreta varietà tecnica e stilistica che è tipica dei primi lavori.
Il libro, tuttora in fieri, ha i seguenti requisiti, in ordine di importanza:
  1. deve contenere testo ed estratti musicali correttamente e coerentemente impaginati;
  2. deve supportare sufficientemente la notazione per chitarra;
  3. deve essere multilingua, in inglese e in italiano, con testo su due colonne (come molte pubblicazioni musicali);
  4. deve essere dotato di indice generale e analitico;
  5. deve essere distribuito in formato pdf possibilmente ipertestuale.

Selezione degli strumenti


La sfida proposta non è banale, perché esistono, nel mondo del software libero, moltissimi editor di testo e alcuni editor di musica, ma pochissime soluzioni integrate.
La prima soluzione che potrebbe venire in mente è l'integrazione degli estratti musicali nel testo come immagini esterne mediante un qualunque editor che possa importare immagini. Le difficoltà di questa soluzione sono:

  1. l'ottenimento di una impaginazione (margini e dimensioni del testo) coerente fra il testo e l'immagine della musica importata;
  2. la possibilità di creare estratti musicali con un software dedicato.
Se il primo problema può essere affrontato con tanta pazienza e accontentandosi di una non perfetta integrazione fra testo e contenuti musicali, il secondo sembra insormontabile, almeno con il software libero che ho provato:

  • Musescore: un buon editor musicale wysiwyg in generale, che però:
    • non consente l'esportazione di estratti musicali, ma solo di partiture complete e già impaginate;
    • non supporta ancora la notazione del bending chitarristico;
  • Noteflight: un editor musicale  wysiwyg online, che però consente solo la stampa della partitura completa (eventualmente in pdf);
  • Lilypond: un ottimo processore di notazione musicale basato su un proprio linguaggio, che ha però in questo contesto le stesse limitazioni di Musescore (forse per il bending ci sono soluzioni possibili ma non immediate: le studierò in prossime occasioni).
Anche se difficilmente utilizzabili in questo contesto, questi software sono utili per altri fini che saranno affrontati nel prossimo articolo.

La soluzione integrata mi è presto parsa più praticabile, ma in questo campo la scelta si è ridotta a solo due opzioni:
  • lilypond-book: forse la soluzione ottimale in molti casi; se si risolverà il problema del supporto alla notazione del bending, la prossima edizione del mio libro utilizzerà questa soluzione;
  • LaTeX+MusixTeX: pur presentando una curva di apprendimento da ragno delle Dolomiti, questa soluzione "fa".
Su Windows, l'ottima distribuzione di LaTeX che ho utilizzato è MikTeX, che permette di configurare automaticamente l'estensione MusixTeX e fornisce un semplice, comodo e configurabile editor (TeXworks) e un visualizzatore pdf sincronizzabile con l'editor.

Plug'n'Play

Prima di incominciare a lavorare, è necessario:
  1. configurare MikTex per l'uso di MusixTeX
    1. accedere alle MikTeX Options;
    2. spostarsi sulla scheda Packages;
    3. selezionare il pacchetto MikTeX Packages/Applications/Music/musixtex
    4. seguire la procedura suggerita (tasto Ok?)
  2. configurare TeXworks per automatizzare la compilazione con MusixTeX:
    1. dal menù modifica/preferenze spostarsi sulla scheda composizione;
    2. aggiungere uno strumento di processo così definito:
      • Nome: musixTeX+texify-pdf (o altro nome preferito)
      • Programma: [installazione MikTeX]/miktex/bin/musixtex.bat, dove musixtex.bat è uno script così fatto:
        @echo off
        del *.mx?
        pdflatex -synctex=1 -undump=pdflatex %1
        if errorlevel 1 then goto exit
        musixflx %1
        texify --pdf --tex option=-synctex=1 %1
        
      • Argomenti: $fullname
      • Visualizza PDF dopo composizione: si (o secondo le proprie preferenze)
Ora siamo pronti per scrivere il nostro libro con LaTeX. Per incominciare definiamo nel preambolo:
...
\usepackage[british,italian]{babel}
\usepackage[utf8]{inputenc}
\usepackage{parallel}
\usepackage[hyperindex]{hyperref}
    \hypersetup{...}
}
\usepackage{musixtex}
\input musixgui
\input musixper
...
dove abbiamo impostato il documento per supportare:
  • la sillabazione in inglese e in italiano tramite il componente babel;
  • l'input in formato utf8;
  • le due colonne che conterranno il testo nelle due lingue tramite il componente parallel;
  • la costruzione di un pdf ipertestuale;
  • la compilazione di spartiti musicali tramite il componente musixtex;
  • due estensioni di esempio:
    • musixgui (per scrivere la notazione ad accordi per la chitarra);
    • musixper (per supportare la notazione delle percussioni).
Scrivere le parti testuali in un documento LaTeX è molto semplice e l'argomento è ampiamente documentato.
Le parti musicali si inseriscono nel documento LaTeX mediante l'ambiente music, come nel seguente esempio:
\begin{music}
\nostartrule
\nobarnumbers
\generalsignature{1}
\generalmeter{\meterfrac{12}{8}}

\startpiece
\notes\zchar{20}{\metron{\qup}{160}}\en
\Notes\ds\zchar{14}{IV}\islurd1{f}\Ibu1{f}{g}2\qb1{f}\tslur1{g}\tbu1\qb1{g}\en
\leftrepeat
\Notes\Ibl1{i}{i}5\qb1{i}\qb1{i}\tbl1\qb1{i}\Ibl1{j}{g}3\qb1{j}\qb1{i}\tbl1\qb1{g}\en
\NOtes\ql k\en
\Notes\itieu0{i}\cl i\ttie0\cl i\en
\NOtes\qu g\en
\bar
\NOtes\ql j\en
\Notes\itieu0{i}\cl i\ttie0\cl i\en
\NOtes\qu g\qu f\en
\Notes\itied0{g}\cu g\ttie0\cu g\en
\NOtes\qu h\en
\bar
\NOTes\zchar{14}{II}\itied0{b}\hup b\en
\NOtes\ttie0\qup b\en
\Notes\ds\zchar{14}{IV}\islurd1{f}\Ibu1{f}{g}2\qb1{f}\tslur1{g}\tbu1\qb1{g}\en
\setrightrepeat
\endpiece

\end{music}
per ottenere:

Per interpretare il codice serve la stele di Rosetta, infatti altri programmi basati su MusixTeX sono stati creati per facilitare l'inserimento della musica: PMX, M-Tx; però questi sono adatti alla stesura di partiture complete e nessuno ha pubblicato il modo di usarli per creare estratti da inserire in un documento LaTeX.
Un'altra possibilità che ho esplorato è sfruttare la capacità di Musescore e Noteflight di esportare in formato musicXml e creare una trasformazione xsl da musicXml al sorgente musixTeX. Ho creato e utilizzato tale trasformazione per ottenere le bozze dei sorgenti, che dovevano comunque essere completate a mano; infatti con una trasformazione xsl più di tanto non si riesce ad ottenere, dato che i formati sono estremamente diversi (musicXml è un formato pensato per il trasporto dei contenuti musicali, mentre musixTeX per la resa in stampa di spartiti); motivo per cui la trasformazione non è stata resa pubblica. Se a qualcuno interessasse usarla, mi può contattare.

Conclusioni

Anche se "solo" per scrivere un libro di musica, la strada è lunga e irta di insidie e difficoltà.
Anche per un esperto di LaTeX, scrivere le parti musicali non è affatto facile per il fatto che il linguaggio di MusixTeX è per "iniziati" di TeXLa documentazione che si può trovare su internet si limita al manuale, che è molto completo e in generale sufficiente per ogni esigenza non esoterica.
L'alternativa più interessante è lilypond-book, che può utilizzare ancora LaTeX per la produzione del documento, ma salva le parti musicali come immagini collegate; naturalmente le immagini prodotte sono perfettamente adattate al contesto. La scrittura della musica con Lilypond, pur essendo basata sempre su un codice testuale, è molto più intuitiva rispetto a quella di MusixTeX. Non l'ho usato nel mio progetto per un semplice motivo: l'ho scoperto quando il lavoro era già in fase troppo avanzata e non avevo voglia di ricominciare tutto daccapo.
Forse lo userò per una seconda edizione...

Nel prossimo articolo descriverò la mia esperienza con i già citati software per la stesura di spartiti musicali.

lunedì 2 maggio 2011

Processo di produzione audiovisiva casalinga

Condizioni al contorno

Ho appena incominciato la sperimentazione di una squadra di software per il montaggio audiovisivo. In passato ebbi un po' di esperienza con Adobe Premiere, After Effects e Encore DVD, ma questa volta ho voluto affrontare l'impresa usando esclusivamente software libero.
Guardandomi in giro, mi imbatto in Lightworks, un programma professionale rilasciato recentemente, in versione beta, come libero e open source: perfetto per farsi tanto male... mi piace! Naturalmente ho scoperto poi di aver bisogno di diversi altri strumenti.
Il punto di partenza del processo è l'acquisizione con i seguenti dispositivi a mia disposizione:
  • smatphone HTC Tattoo: aquisisce in formato 320x240 usando il contenitore 3gp con framerate variabile;
  • macchina fotografica Canon Digital IXUS 85IS: acquisisce in formato 640x480 usando la codifica MJPEG a 30 fps;
  • videocamera Sony Handycam DCR-HC19E PAL: acquisisce in formato PAL 4:3 o 16:9 su cassetta miniDV.
L'ambiente di lavoro è MS Windows 7 a 64 bit.
Il punto di arrivo è la visualizzazione da:
  • smartphone HTC Tattoo;
  • riproduttore Philips Home Theater System HTS3164 (con televisore 16:9): riproduce DVD e DivX e supporta audio AC3 e DTS.

Sperimentazione

Il primo problema da considerare è che Lightworks è un programma professionale che si è appena affacciato al grande pubblico amatoriale, quindi utilizza come formati di acquisizione i formati standard per il broadcasting e il cinema: PAL, NTSC, HD 720, HD 1080; i contenitori gestiti sono AVI e Quicktime con le compressioni DV, MPEG 2 e una caterva di formati professionali a me sconosciuti. Fine. Niente MPEG4, DivX, Theora ... ahi!
Nessun problema con la Handycam, che è riconosciuta e correttamente controllata nel processo di acquisizione: l'unica difficoltà è che Windows 7 non permette l'uso dell'interfaccia USB per l'acquisizione video (e neanche Lightworks, figurarsi!), quindi è necessario usare la IEEE 1394 (anche nota come Firewire o iLink): meglio, dato che quest'ultima è anche superiore in termini di qualità del segnale.
La IXUS ha una qualità del video un po' inferiore a quella della Handycam (e vorrei vedere, è una macchina fotografica!), ma il formato MJPEG è direttamente importabile in Lightworks. Però, siccome registra a 30 fps, Lightworks permette di importare i metraggi solo in formato NTSC o HD, perchè tale velocità non è prevista per PAL (che, per combinazione, è il formato che devo usare io): importo in HD 720, pur sapendo che il passaggio da 640x480 a 1024x720 necessiterà di un ricampionamento.
Il Tattoo ha una risoluzione molto più bassa del PAL e un framerate variabile fra circa 5 e 16 fps, oltre ad un'ottica molto "economica" e nessuna possibilità di regolazione in fase di ripresa: non mi aspetto risultati esaltanti; inoltre il contenitore 3gp appartiene ad un pianeta sconosciuto a Lightworks. Mi necessita un convertitore: dopo averne provati diversi la mia scelta cade su ffcoder, che usa K-Lite Codec Pack e Avisynth; forse non è la scelta ottimale, perché scopro in seguito che sul mio sistema operativo il programma non riesce a configurare i codec VFW per il contenitore AVI (che, guarda caso, sono proprio quelli utilizzati da Lightworks). Per risolvere questo problema, installo anche Virtualdub, che può usare i codec VfW ma non legge i 3gp. Nessuno dei due programmi da solo può convertire da 3gp ai codec Matrox usati da Lightworks, ma posso usarli insieme usando un formato comune di trasferimento. Comunque Virtualdub è utile anche per l'applicazione di filtri, quali Deshaker (stabilizzatore video), che per le riprese con il Tattoo si rivelerà salvifico.
Lightworks ha una curva di apprendimento piuttosto ripida, perché pur avendo un'interfaccia utente molto pulita e flessibile, usa un linguaggio professionale e un paradigma di montaggio che è sicuramente intuitivo per i professionisti del settore (quelli che lavoravano con le forbici e le pellicole), ma è diverso dagli altri NLE più diffusi. Il manuale utente è anch'esso rivolto ai professionisti, quindi poco masticabile per un novizio, ma, in compenso il forum del sito è molto vivo, ricco e popolato da personaggi piuttosto esperti; inoltre ci sono nella rete diversi filmati di apprendimento che mostrano le caratteristiche principali del programma e sono sufficienti per incominciare a lavorare.
Stimolato dal forum, integro Wax come plugin di Lightworks per provare un po' di effetti speciali, ma rimango un po' deluso: l'interfaccia utente, pur abbastanza semplice e classica, non permette operazioni banali come lo zoom sulle timeline o l'inserimento da tastiera dei valori dei vari effetti, rendendosi di difficile ed impreciso utilizzo. In pratica, non riesco a creare correttamente né una transizione, né un effetto speciale: spero in una prossima evoluzione. Diversamente da Lightworks, le risorse per imparare ad usarlo sono piuttosto povere.
Per tentativi e con forum sul comodino riesco a produrre un paio di filmati. Al momento dell'esportazione sono un po' imbarazzato nello scegliere il codificatore di uscita. Naturalmente, neanche a dirlo, Lightworks esporta solo nei formati e nelle codifiche già elencate per la fase di importazione. Ma ormai la strada è in discesa: basta ripercorrere al contrario la strada in salita dell'andata. Quindi, con Virtualdub esporto in DivX 720x404 (pur arrivando il PAL a 768x576, più di 720 sembra che il mio home theater non supporti) e in AVI non compresso: quest'ultimo è trasformato in e MPEG 2 (PAL Widescreen) e 3gp 320x240 con bande orizzontali mediante ffcoder.

Conclusioni

La prima evidenza scaturita da questa esperienza è (non ci vuole Kubrick per scoprirlo) che il Tattoo è assolutamente inadeguato. Penso che la prossima volta che mi appresterò ad usarlo per riprendere le evoluzioni di mia figlia sarò preso da brividi di paura. Una buona ripresa con la Handycam o al limite la IXUS è un buon punto di partenza per sentirsi a proprio agio nelle successive fasi di produzione.
Virtualdub era un mio vecchio amico e continua ad esserlo, perché non fa molto, ma il poco che fa lo fa molto bene: applicazione di filtri e conversione di formato e codifica sono semplici ed efficaci.
Sono stato deluso dall'incapacità di ffcoder di esportare in AVI VfW; per il 3gp e MPEG 2 invece nulla da eccepire.
La prima caratteristica di Lightworks che mi ha colpito è la conservazione di tutto il lavoro fatto anche in caso di crash (d'altra parte è una beta): è una balla sorpresa scoprire di non aver perso niente dopo uno spaventoso "errore critico". Se all'inizio mette un po' di soggezione il suo approccio personale al montaggio, basta entrare un po' in intimità per restarne affascinati: dà l'impressione di saper fare cose che noi umani (neanche quelli che hanno scritto il manuale) non possiamo neanche immaginare.
WAX... mah, c'è chi ne parla entusiasticamente, chi meno. Io non sono riuscito ad usarlo efficacemente come plugin di Lightworks. L'impossibilità di ingrandire l'area di lavoro nella timeline, quando si deve lavorare con precisione, è una grave pecca; ancora peggio l'impossibilità di scrivere (con la tastiera) dati numerici nelle caselle di testo delle regolazioni degli effetti, ma l'obbligo di ottenere "172,34" facendo scorrere il mouse intorno alla casella: impossibile. Inoltre, anche dopo essere riuscito a creare un effetto approssimativamente come volevo io, la sua applicazione nell'edit di Lightworks era scorretta.
Insomma, posso dire che il risultato di questa esperienza è soddisfacente, ma migliorabile.

martedì 25 novembre 2008

Separazione delle carriere in php

php è considerato un linguaggio "semplice" per lo sviluppo web, spesso contrapposto alle piattaforme "serie" come .NET e Java: questo è dovuto soprattutto all'uso semplice che la maggior parte degli sviluppatori ne fanno.
Ma anche in php si possono usare paradigmi di progettazione più evoluti del semplice incapsulamento nel codice html; ad esempio, si possono usare i template, per separare lo strato di visualizzazione da quello di elaborazione.
Il template è un file prototipo che non contiene (quasi) codice php e che può essere quindi gestito anche da chi non conosce il php: può essere un file html, xml, javascript o di qualunque altro tipo si voglia. La sua particolarità è quella di poter contenere eventuali segnaposto utilizzabili da php.
Il codice php può compilare il template con diverse tecniche (io ne mostrerò solo una, basata sulla funzione eval) e restituire il documento opportunamente modificato.
Ad esempio, si possono avere i tre file:
  • mondorux.php: la pagina che sarà richiesta dal browser e che controlla il processo;
  • component.php: contiene la classe Component, che incapsula il meccanismo di rendering dei contenuti;
  • template.html: il prototipo che "vestirà" mondorux.php.
Ecco il codice, che mi appresto a commentare.

template.html

<html>
    <head>
        <title>$titolo</title>
    </head>
    <body>
        <h1>$titolo</h1>
        <p>$saluto</p>
    </body>
</html>
Come si può vedere, in questa pagina html non c'è codice php, a parte quelle strane stringhe precedute da '$': esse sono solo dei segnaposto (nota: questo non è l'unico modo per scrivere il template).

component.php

<?php
class Component{
    var $_template;
    var $_parameters_array;

    /* costruttore, imposta il template */
    function Component($template){
        $this->_template = str_replace("\"","\\\"",implode("",file($template)));
    }

    /* legge un array associativo di nomi di variabili e loro valori */
    function setParameters($parameters_array){
        $this->_parameters_array = $parameters_array;
    }

    /* esegue la resa del template */
    function render(){
        if(is_array($this->_parameters_array)){
            foreach($this->_parameters_array as $v_name => $v_value){
                eval("$v_name = \$v_value;");
            }
        }
        eval("\$compiled = \"".$this->_template."\";");
        return $compiled;
    }
}
?>
Questa classe (perdonate lo stile PHP4, un po' obsoleto) incapsula il template e il meccanismo di rendering, che ruota tutto intorno alla funzione eval (nel metodo render), che valuta come codice php la stringa passata come parametro.
Il metodo getParameters raccoglie un array associativo di coppie (nome, valore) in modo che il codice cliente possa impostare i contenuti della pagina.

mondorux.php

<?php
require("component.php");
$pagina = new Component("template.html");
$pagina->setParameters(
    array(
        '$titolo' -> "Template php",
        '$saluto' -> "Ciao mondo, ma che belli i template!"
    )
);
$pagina->render();
?>

Come si può vedere, in questo codice non c'è traccia di come sarà reso il documento (in questo caso: html).
mondorux.php usa la classe Component, chiedendole di eseguire, tramite il template "template.html", la resa dei contenuti, ossia i parametri $titolo e $saluto i cui valori sono assegnati nell'array.
Con questa tecnica abbiamo ottenuto una quasi completa separazione del codice di elaborazione (mondorux.php) dal codice di visualizzazione (template.html), implementando così il famoso (e utile) pattern Model-View-Controller.