comunque ho iniziato a studiare un po' supercollider...è molto affascinante ed è sicuramente un linguaggio di programmazione molto più completo e astratto di csound, più vicino a Python, tant'è vero che se ho ben capito Supercollider stesso è scritto in Supercollider, è scritto con il proprio stesso linguaggio, mentre csound è scritto in c...ma l'impressione che ancora mi rimane, è che la sua stessa struttura e organizzazione renda il "batch processing" (nel senso di realizzazione di un progetto definito millimetricamente senza alcun intervanto umano) non dico "meno flessibile" che in csound, ma molto molto più complesso/scomodo. Sarà anche perchè lo stupendo corso in italiano di Andrea Valle parla di tutto in modo molto approfondito ma alla voce "scheduling"...si ferma
Forse mi sbaglio, confermi questa mia impressione Maurizio? ovvero che sia più semplice usare Supercollider in un'ottica di interazione uomo-macchina, o tutt'al più di interazione "algoritmo generativo"- "algoritmo di sintesi"? (quello che suggerisci nel tuo post, se capisco bene, è "costruire" un "oggetto sequencer" che sia in grado di organizzare la composizione secondo determinate funzioni).

Mi sto accorgendo che il problema del "sequencing" è un problema nodale...per "sequencing" (non so nemmeno se sia il termine più adatto ma non me ne veniva un altro) intendo l'organizzazione TEMPORALE degli eventi che accadono in un'opera (o performance che dir si voglia)...è un discorso complesso, se lo pensiamo in relazione ai diversi linguaggi di programmazione. Voglio tentare di analizzare il problema:

- studiando un linguaggio come Maxmsp mi è sempre risultato difficile pensare al discorso del sequencing. In max si creano in un certo senso degli OGGETTI, dei circuiti chiusi" che svolgono determinate operazioni (complesse a piacere). Una volta create queste PATCH, resta il problema di cosa farne...ovvero questi oggetti vanno manovrati da qualcuno o qualcosa. Essendo max pensato per un discorso realtime, è intuitivo pensare che maxmsp sia abitualmente utilizzato in ambito live con midicointrollers, sensori di vario genere etc. Certo in max ci sono oggetti (come timeline etc.) pensati per il sequencing...ma chissà perchè ho l'impressione che siano un po' "mezzi di fortuna", ovvero più primitivi di altri aspetti del programma (magari mi sbaglio?)

- In un linguaggio come Csound (ed è questo uno degli aspetti più interessanti), la dualità ORCHESTRA\SCORE integra in modo molto interessante le "due faccie della medaglia", ovvero organizzazione degli algoritmi di sintesi e organizzazione temporale del pezzo, stabilendo una continuità perfettamente  implicita nella musica elettronica...il confine tra timbro, nota, evento, suono diviene estremamente labile nella computer-music. Non di meno ho l'impressione che la parte SCORE del linguaggio csound sia molto molto più primitiva del linguaggio di sintesi vero e proprio. Voglio dire...alla fine il linguaggio della score è un generico linguaggio che organizza eventi, sequenze numeriche, in funzione del tempo. Però mentro per scrivere una orchestra abbiamo migliaia di opcodes, per scrivere una score ci dobbiamo avvalere unicamente di file di numeri. Non ci sono opcodes relativi all'organizzazione temporale micro e macrostrutturale...mi sembra comunque un limite...

- Mi attraeva Supercollider in quanto con la sua capacità di vero e proprio LINGUAGGIO DI PROGRAMMAZIONE molto raffinato...permette la generazione algoritmica sia di eventi che di algoritmi di sintesi veri e propri...pur non avendo approfondito questo linguaggio mi sembra di intuire però che sia più pratico utilizzarlo per creare strumenti virtuali che generano eventi in gran parte "stocastici", che poi vengono gestiti in performance live. Insomma, un po' come se  le amorfe patch di maxmsp in supercollider avessero una loro "intelligenza" artificiale che gli permette di generare musica in autonomia, sotto il controllo live di un "performer". Ancora una volta, comunque, il discorso "sequencing", in tutto quanto ha di discrezionale e sofisticata organizzazione e predeterminazione di eventi NEL TEMPO, mi sembra una cosa secondaria anche in questo linguaggio.

Perchè tutto questo discorso?

Mi chiedo semplicemente se esista un linguaggio di programmazione sofisticato come quelli soprdescritti ma unicamente orientato al SEQUENCING ovvero alla organizzazione, alla pianificazione estremamente sofisticata di eventi nel tempo che vanno a governare applicazioni come Maxmsp. A quel punto max diverrebbe lo strumento computerizzato, e il linguaggio "sequencer", l'esecutore computerizzato. Si metterebbero così in comunicazione i due linguaggi...mi sembra interessante sfruttare le potenzialità del computer anche per quanto riguarda la vera e propria performance esecutiva (che sia live o preregistrata su disco).
I classici sequencer come Nuendo mi sembrano difettare sotto molti punti di vista (non c'è la possibilità di fare script, di generare algoritmicamente, le automazioni sono primitive, le curve per gli inviluppi anch'esse molto primitive), insomma sono applicazioni buone per operazioni "standard", non di certo per esigenze complesse...Programmi come Open Music mi sembrano anch'essi molto distanti dal concetto del "tempo". Con open music si crea una patch, che genera un materiale musicale "morto"...che può diventare un file midi o una partitura, o una partitura di csound. Però siamo alle solite...quando si tratta di governare uno strumento con 80 parametri su una timeline, un file midi può fare ben poco.
Altre soluzioni sono programmi come Athenacl...che genera alla fin fine dei numeri, o Python (idem). Ultimamente mi è caduto l'occhio su questo http://www.algomusic.com/jmsl/index.html. Può comunicare anche con max...Cosa ne pensate?

Non so fino a che punto vi siete posti questi problemi, in quanto mi pare di capire che le tendenza imperante oggi con questi programmi sia l'interazione live...ovvero STRUMENTO COMPUTER ------->ESECUTORE UOMO.
Ma volendosi porre in un'ottica STRUMENTO COMPUTER------>ESECUTORE COMPUTER? (esecutore computer ma COMPOSITORE UOMO, che predetermina il materiale...non sto parlando di musica algoritmica generata AUTOMATICAMENTE del computer). Scusate il post molto lungo ma sono argomenti un po' complessi...

mamma mia...che roba , gli ho dato una occhiata veloce...mi sembra di non aver mai visto un "manuale" più approfondito ed esauriente , ragazzi dategli un'occhiata...
grazie yan

Grazie mille ragazzi...infatti mi aveva incuriosito supercollider proprio per la sua immediatezze e per la facilità di generare algoritmicamente un gran numero di ugens (l'esempio di cinespasmon dimostra). In effetti il rischio è quello di perdersi in un labirinto di linguaggi e sintassi diversi e bloccarsi un attimo di fronte a tutte queste alternative...meglio approfondire una strada bene e poi magari spaziare. Certo la tentazione di teorizzare è forte perchè quando si hanno paradigmi compositivi ben precisi c'è sempre un po' la paura di affidarsi ad un linguaggio che non collimi esattamente con le proprie esigenze...escludendo il puro fascino di scoprire e studiare (il rischio è che diventi dispersività). Per tornare ad un discorso più tecnico approfondendo il discorso degli UDopcodes recursivi in csound (in pratica bolcchi di codice che possono assumere se stessi al proprio interno), ho trovato il modo di generare grandi quantità di parametri con poche linee di codice. Ad es: ho creato un UDO che genera un numero indefinito di subarmonici in modo molto semplice. Questo per ora mi basta, visto che trovo la sintassi di csound terribilmente accattivante e intuitiva (in poche parole semplicissima!), mentre super collider mi pare molto molto più tortuoso, almeno all'inizio forse.
Penso che il modo migliore comunque, ed è quello che mi voglio imporre adesso, sia quello di cominciare a CREARE e affrontare i vari problemi e le varie necessità man mano si presentano all'interno dello stesso linguaggio e una volta trovate cose veramente scomode o impossibili eventualmente cercare altrove per integrare o sostituire. Penso quindi di approfondire meglio csound...magari posterò le mie esperienze in un thread apposito (anche di csound si parla poco! anzi, sembra un po' passato di moda , secondo me perchè oggi si vede più l'elettronica nel senso live del termine  )

Avete mai usato questo linguaggio?...fra i linguaggi al di fuori dei canonici csound e supercollider mi sembra uno dei più completi, ad un colpo d'occhio superficiale...(più di chuck e pwgl mi pare)...faccio un po' difficoltà ad usare l'interfaccia java (non si riesce a copiare-incollare il codice dall'editor di testo e direttamente da lì non riesco a far partire nulla   ), però vale la pena dargli un'occhiata che dite?, anche se per adesso non riesco esattamente a capire SE i IN COSA si può differenziare dagli altri linguaggi.

Una volta "rotto il ghiaccio" con i linguaggi di programmazione diventa quasi appassionante scoprire nuove sintassi anche senza farci nulla  .
Stabilita ormai sempre più definitivamente la mia predilezione per i linguaggi "testuali" stavo dando un'occhiata a Supercollider...che, se non erro, rappresenta lo standard di riferimento dopo Csound.

Volevo sapere se le conclusioni che ne ho tratto sono corrette, anche se non ho di certo approfondito completamente la sintassi di Supercollider:

- Se voglio riscrivere la Va di Beethoven con suoni elettronici (per fare un esempio banale), in Csound è un duro lavoro, ma alla fine avrò il controllo millimetrico su ogni nota, su ogni parametro di attacco e di timbro del suono e una possibilità espressiva e "discrezionale" assoluta. Con Supercollider prima devo impazzire, poi una volta ricoverato scopro che è impossibile. Nel senso che da quel che ho capito non si può scrivere una vera e propria "partitura", ma dei moduli che hanno determinati comportamenti, che vengono caricati sul server, e a cui vengono inviati dei messaggi in tempo reale sotto forma di linee di codice "eseguite" dall'utente selezionando una porzione di testo e premendo il tasto "enter".
L'unica possibilità che ho è suonare una tastiera MIDI e registrare (ma anche lì non è facile e bisogna usare una libreria esterna)...però non potendo suonare da solo la Va di Beethoven non c'è verso (non parlando poi del controllo dei vari parametri e della polifonia di timbri).
Per far suonare Supercollider bisogna scrivere algoritmi che generano automaticamente il brano (tipo StructuresI di Boulez, ma già Structures II sarebbe impossibile).

- Se invece voglio generare 2000 oscillatori con frequenze random (o con un altro algoritmo) e modificare i parametri globali in tempo reale con un solo clic, oppure aggiungere un riverbero "cucinato" al momento, la situazione si inverte (ovvero impazzisco con csound).

- Essendo le mie esigenze attuali orientate ad un tipo di lavoro "strutturalista", e quindi l'ascoltare in tempo reale mi interessa solo come "test provvisorio", ma il mio obbiettivo è l'elaborazione di eventi definiti in modo microscopico, totalmente controllati in ogni parametro del timbro e del tempo, e poi fissati in un file audio da trasmettere (che poi sia trasmesso su 2 o 100 canali è un altro discorso  ), la mia scelta deve naturalmente orientarsi verso Csound.

- Se avessi in futuro bisogno di far interagire strumenti acustici elaborati in tempo reale dal computer, dovrei rivolgermi a Supercollider...ma in quel caso penso che Maxmsp sia una scelta ancora più efficace. Super collider lo vedo più proiettato sulla generazione algoritmica e sulle "performances improvvisazioni" dal vivo con Ibook.

Aggiungi una versione che implementa la Phase modulation...così stupisci il tuo professore e porti avanti la causa della Pm (io però non sono riuscito ad aprire la tua patch...magari l'hai già fatto  ).

beh infatti è più intuitivo un indice di modulazione non in hertz...certo, concettualmente è abbastanza complicato definire la pm, però alla fine si riduce a qualcosa di molto semplice, dal punto di vista pratico...

-odac<numero scheda>, dovrebbe bastare questo...


sei sicuro che non sia un problema a livello di codice? prova a scrivere un file audio e vedere se la tua orchestra emette suono   , magari non ci sono errori ma per qualche motivo non suona...

Comunque eviterei di mettere +- p...prova.

Ho provato a implementare la Phase modulation in Csound...comunque anche in max e pd è semplicissimo (un phasor che legge una forma d'onda e un modulatore che viene sommato al phasor)...mi chiedo però come mai la Phase modulation sia così relativamente "poco" e mal documentata...non dovrebbe aver completamente soppiantato la FM? Da quel che ho capito la PM è più "stabile" della "vera" modulazione di frequenza soprattutto quando si usa il feedback o molti operatori con alto indice di modulazione...in quel caso con la FM compare un DC offset che provoca una deviazione delle frequenze (ho potuto sperimentare la cosa in Csound). Mi chiedo come mai nei manuali di "teoria" la FM non sia diventata completamente obsoleta...anche nei tutorial di Max-msp non viene introdotta (o viene solo citata)...forse perchè è più semplice ed intuitivo spiegare la "vera" modulazione di frequenza?
Oppure ci sono limiti o difficoltà di implementazione della Phase Modulation di cui non sono a conoscenza? Per quanto mi riguarda ho semplicemente constatato l'assoluta identità di risultato delle due tecniche...unica cosa, l'indice di modulazione che nella PM non si può "quantificare" in hertz...è forse qua il limite di implementazione? Effettivamente mi chiedo...se l'indice di modulazione nella FM viene fissato in rapporto alla frequenza della modulante, nella PM come si fissa? Se non si varia l'indice di modulazione al variare della frequenza modulante cambia il timbro al variare dell'altezza?
Io non ho notato l'effetto...usando un indice di modulazione fisso, il timbro era omogeneo...mi chiedo allora che senso abbia parlare ancora di FM se non in una prospettiva storica...

un problema più tecnico che artistico dunque...da quel che ho capito ogni filtro ha i suoi pro e contro, quindi se mi serve una risposta piatta userò un filtro, se mi serve risonanza ne userò un altro...fornendomi di un' ampia risorsa di filtri e algoritmi già "rodati" e scegliendo in base alla necessità.

provo a darmi una prima risposta da solo 
Sto sperimentando con Filtergraph di msp e biquad...l'equazione del filtro biquad mi sembra semplice, tradotta in termini "correnti", mi pare due linee di ritardo di 1 e 2 samples che vengono sommate e sottratte al segnale originale, ognuna moltiplicata par un fattore di gain (coefficente)...il problema da quanto ho capito è che prevedere come si comporta la risposta del filtro in base ai coefficienti è abbastanza complicato (ovvero coinvolge matematica complessa). Per questo con filtergraph è possibile gestire il tutto in base al rapporto frequenza-ampiezza...ma in pratica il risultato è abbastanza "classico"...si sceglie un tipo di filtro e si setta la risposta in termini di cutoff e q. Sembrerebbe esaurito il problema...ma allora che risultati porta creare filtri con altri tipi di struttura (questo mi sembra non recursivo quindi FIR se non sbaglio, ma quelli recursivi IIR?)...non riesco a capire...una volta che io posso stabilire le frequenze e stabilire di quanto vengono attenuate o accentuate, che altro serve?...

La prospettiva di lavorare con la cosiddetta "sintesi digitale diretta", aperta dall'uso del computer, mi porta necessariamente al problema dell'elaborazione di filtri...sono però spaventato dalla materia...navigando su internet non si trovano altro che equazioni differenziali complesse, integrali, una materia alla quale sono purtroppo totalmente estraneo...vorrei cercare di definire qualche punto fondamentale del discorso, vi ringrazio per la pazienza...

1) appena accostato alla musica elettronica, credevo che i filtri fossero semplicemente lowpass, highpass, banpass, bandreject...il che è piuttosto intuitivo...approfondendo il discorso ho scoperto che praticamente ci sono una infinità di algoritmi diversi, ovvero (mi pare) una infinità di possibili lowpass etc. CHE INTERESSA HA QUESTO PER IL MUSICISTA?!...mi spiego meglio, il design di un filtro rappresenta un fattore eminentemente tecnico, cioè mirato al RENDIMENTO MIGLIORE di un determinato algoritmo, oppure una vera e propria risorsa artistica? voglio dire, studiare un nuovo lowpass è un tentativo TECNICO di creare un algoritmo più efficente (come studiare un nuovo tipo motore per un'automobile, il cui scopo è però unicamente lo stesso), oppure è la volontà di creare una DETERMINATA PARTICOLARITA' di suono? se lo scopo di un lowpass è SOLAMENTE di tagliare le frequenze più acute, a questo punto si può dire che è importante utilizzare l'implementazione più di qualità di un lowpass...un musicista (per ottenere un risultato di qualità) dovrebbe scegliere un lowpass "di qualià", come un architetto che vuole costruire un edificio di lusso scieglierà materiali pregiati... forse a questo punto è inutile che il musicista si occupi dell' implementazione del filtro, può delegare il compito al tecnico e poi scegliere l'implementazione più efficace. Ma è davvero così? vedendo la pletora di algoritmi possibili, mi viene il dubbio che acquisire la capacità di disegnare un lowpass possa permettere al musicista di spaziare tra varie tipologie di suono, nonchè sperimentare diverse e inusuali configurazioni...è anche un problema di estetica, voglio dire...NON E' SEMPRE DETTO CHE UNA IMPLEMENTAZIONE EFFICACE SIA LA MIGLIORE...potrebbe darsi che una implementazione "sbilenca" o "squilibrata" IN DETERMINATI CASI possa fornire un risultato pertinene...ed effettivamente (per esempio in REAKTOR) si capisce che vari tipi di filtro presentano vari tipi di "flavour" come si suol dire...il suono che ne esce presenta caratteri sottilmente diversi...MI CHIEDO, fino a che punto giocare con gli algoritmi di un filtro rappresenta un terreno fertile artisticamente e non un mero interesse tecnico? (ovvero: raggiungere il massimo dell'efficacia per ottenere lo stesso scopo?), e FINO A CHE PUNTO UN MUSICISTA e non un tecnico può lavorare in questo senso?

2) rispondendo alla prima domanda si presentano altri problemi...E' NECESSARIO CHE UN MUSICISTA AFFRONTI IL DISCORSO DEI FILTRI IN SENSO STRETTAMENTE MATEMATICO? sempre navigando in internet ho sempre trovato spiegazioni teoriche, ma pochissime implementazioni pratiche...cioè non ho mai trovato la traduzione in termini "sonori"...se non erro un qualsiasi filtro non è che una rete di delay con e senza feedback...perchè allora nessuno affronta il discorso da questo punto di vista, cioè con diagrammi di flusso che chiariscano come IN CONCRETO si possono realizzare filtri diversi fra loro? è forse impossibile? non è possibile un approccio più EMPIRICO, senza tutte le implicazioni teoriche? e se sì, l'approccio empirico che efficacia può avere in termini di ricerca "estetica"?

3) altro problema...ho sempre trovato definizioni dei filtri "nel dominio del tempo"...ma i recenti sviluppi delle tecniche digitali (convoluzione, fft), non rendono OBSOLETO questo approccio? Voglio dire, tramite la convoluzione e l'fft non è possibile disegnare (nel dominio delle frequenze, quindi in modo assolutamente intuitivo) la curva di risposta di qualsiasi filtro, definita in termini di frequency-magnitude? A questo punto non resterebbe per il musicista che sbizzarrirsi ne definire svariate curve e per poi fare una "convoluzione" con il segnale...(resta un dubbio, andrebbe definita anche una risposta in termini di fase, mi sembra importante, ciò è possibile?). Quanto è pratico il metodo appena descritto e soprattutto, può rimpiazzare in modo totale l'implementazione "nel dominio del tempo"?

Da musicista, sono spaventato nall'affrontare il discorso dei filtri dal punto di vista strettamente matematico...però mi accorgo  sempre più che l'"anima" della musica elettronica è proprio tutto quanto coinvolge il "time shift", ovvero delays, feedback network, risuonatori, waveguides, e quindi filtri...tutte cose (se non erro) in stretta relazione tra loro, e che danno veramente "l'anima" al suono...la possibilità di poterle "dominare" a quindi piegare alle diverse esigenze artistiche mi affascina enormemente...

Sempre molto gentile, grazie