Pagine: [1] 
|
 |
|
Autore
|
Topic: Supercollider (Letto 722 volte)
|
aledl
Jr. Member
Posts: 69
|
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. |
|
|
|
|
Loggato
|
|
|
|
cecinestpasmonID
Newbie
Posts: 7
|
[…] 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).
Non è esattamente così: se controlli le sezioni "Streams-Patterns-EventsN.html" dell'help (N sta per un numero da 1 a 7) vedi che puoi fare anche con sc una bella esecuzione della 5a  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).
Non ho mai usato Csound, diciamo che sc ha un sacco di facilitazioni per provare in fretta i risultati dei nostri esperimenti. In particolare la sintassi Function.play permette di sentire subito come suonano: es sciocco: s.boot;
{ Mix.fill(8, { arg i; SinOsc.ar( exprand(110, 440) * (i+1), 2pi.rand ! 2, 0.1/(i+1) ) }) }.play;
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 Grossa risata), la mia scelta deve naturalmente orientarsi verso Csound.
può darsi, resta sempre da tener presente che spesso specificare al minimo dettaglio tutti i parametri di una composizione può far perdere "slancio". con sc mi trovo a lasciare che alcuni parametri siano guidati dal caso. l'esempio sopra ne è (in piccolo) una dimostrazione. spesso i suoni "naturali" che troviamo così belli lo sono perchè ciascuno di essi differisce dal precedente per dettagli che spesso non possiamo controllare uando suoniamo uno strumento. lasciando che di alcuni particolari di sintesi se ne occupi un processo stocastico aggiunge naturalezza - secondo me ovviamente. ritengo quindi sc molto adatto allo scopo. Comunque questo discorso esula dalle tue richieste. scusa 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.
MaxMSP (rispetto a csound) invece l'ho usato. Se nell'esempio precedente voglio (il primo esempio che mi passa per la testa) 1000 armonici scrivo 1000 al posto di 8; crea 1 oscillatore sinusoidale in MAX MSP e poi cambia idea, ne voglio 16!: copia-incolla, copia-incolla, copia-incolla, copia-incolla, etc… al posto di oscillatore sinusoidale posso dire abstraction per rendere meglio l'idea. Qualcosa che ho fatto con sc: http://corrado.tirelli.googlepages.com/Zzz.mp3http://corrado.tirelli.googlepages.com/Misembravabellissima.mp3contattami pure offlist se hai bisogno di una mano con sc, per quello che so ti aiuterei volentieri. CT |
|
|
|
« Ultima modifica: Settembre 30, 2007, 02:34:47 pm da cecinestpasmonID »
|
Loggato
|
|
|
|
franz
AAA1
Hero Member
Posts: 828
|
MaxMSP (rispetto a csound) invece l'ho usato. Se nell'esempio precedente voglio (il primo esempio che mi passa per la testa) 1000 armonici scrivo 1000 al posto di 8; crea 1 oscillatore sinusoidale in MAX MSP e poi cambia idea, ne voglio 16!: copia-incolla, copia-incolla, copia-incolla, copia-incolla, etc…
al posto di oscillatore sinusoidale posso dire abstraction per rendere meglio l'idea.
Non è proprio esatto, MaxMSP effettivamete è più "scomodo" rispetto ad altri linguaggi nella gestione della polifonia, replicare più volte la stessa abstraction o lo stesso external. Nel primo caso si può fare utilizzando l'oggetto poly~, pensato per la gestione di instanze polifoniche ma utile anche ad altri scopi, il cui utilizzo consiste solamente nel richiamare al suo interno un'abstraction di nostra fattura contenente l'oggetto thispoly~. Se invece si vuole duplicare un'abstraction o un externals n volte, in MaxMSP come in Pd, è possibile ricorrere allo "scripting" interno, controllabile su max tramite l'oggetto thispatcher o via javascript, in pd semplicemente con il messaggio ;pd seguito dagli argomenti desiderati simili a quelli presenti in max 
contattami pure offlist se hai bisogno di una mano con sc, per quello che so ti aiuterei volentieri.
CT
sarebbe carino se continuaste IN-LIST visto che di SuperCollider si parla poco ed è un linguaggio estremamente interessante a presto franz p.s. corrado, veramente carini i tuoi pezzi! |
|
|
|
« Ultima modifica: Settembre 30, 2007, 07:34:45 pm da franz »
|
Loggato
|
|
|
|
cecinestpasmonID
Newbie
Posts: 7
|
Non è proprio esatto, MaxMSP effettivamete è più "scomodo" rispetto ad altri linguaggi nella gestione della polifonia, replicare più volte la stessa abstraction o lo stesso external.
Nel primo caso si può fare utilizzando l'oggetto poly~, pensato per la gestione di instanze polifoniche ma utile anche ad altri scopi, il cui utilizzo consiste solamente nel richiamare al suo interno un'abstraction di nostra fattura contenente l'oggetto thispoly~.
Se invece si vuole duplicare un'abstraction o un externals n volte, in MaxMSP come in Pd, è possibile ricorrere allo "scripting" interno, controllabile su max tramite l'oggetto thispatcher o via javascript, in pd semplicemente con il messaggio ;pd seguito dagli argomenti desiderati simili a quelli presenti in max
mi riferivo non tanto alla polifonia quanto a fare copia e incolla di un abstraction con, poniamo, 2 inlet e 2 outlet, da attaccare ad un modulo con 16 inlet: copio e incollo 8 volte (vabbè, copio e incollo la prima volta 1 abstraction e ne ottengo 2, copio e incollo queste due e ne ottengo 4, copio e incollo queste 4 e ne ho 8, copio e incollo queste 8 e ne ho 16 con 4 copia e incolla ma il succo è questo). comunque, semplicemente, ogni software è meglio per alcune cose e peggio per altre. sc è più orientato alla creazione di musica composta algoritmicamente, attraverso mutazioni che sono solo parzialmente sotto il controllo dell'utente e ciò - la facilità (forse meglio la sveltezza) con cui lo si fa non che si possa fare solo con sc, eh - lo rende musicale in senso naturale. in questo l'utente aledl ha ragione. È però possibile anche fare sequencing in sc, sfruttando le capacità algoritmiche a livello micro (singoli eventi sonori) piuttosto che macro (sequenze di note, accordi, etc…). un esempio del secondo tipo: a = Buffer.read(s, "/Users/Corrado/SUONI/NewDm/Akai_XR-10 Folder/Akai XR-10/XR10bd01.wav"); // carica 4 campioni (MONO) di batteria a tua scelta nella ram; Cassa
b = Buffer.read(s, "/Users/Corrado/SUONI/NewDm/Akai_XR-10 Folder/Akai XR-10/XR10bd02.wav"); // Cassa
c = Buffer.read(s, "/Users/Corrado/SUONI/NewDm/Akai_XR-10 Folder/Akai XR-10/XR10bd03.wav"); // Cassa
d = Buffer.read(s, "/Users/Corrado/SUONI/NewDm/Akai_XR-10 Folder/Akai XR-10/XR10sd01.wav"); // Rullante
( // carica lo strumento per usarlo con i pattern
SynthDef(\play,{ arg out=0,bufnum=0, r=1.0, amp=0.1;
var playbuf;
playbuf = PlayBuf.ar(1, bufnum, BufRateScale.kr(bufnum) * r ) ! 2;
FreeSelfWhenDone.kr(playbuf);
Out.ar(out, playbuf * amp);
}).memStore;
)
TempoClock.default.tempo_(1.11) // tempo
Pdef(\qwerty).play; // crea un pattern vuoto e lo avvia
( // definisce il pattern
Pdef(\qwerty, Ptpar([
0.0, Pbind(
\instrument, \play,
\bufnum, Prand([a, b, c].collect(_.bufnum), inf),
\dur, PdurStutter(
Pn(Pshuf([ Prand([1, 2, 4, 8], 1), 4, 2, Prand([1, 3, 6, 0, 4, 2], 1), 1 ], 1), inf), Pseq([0.5, 0.25, 0.25, 0.75, 0.25], inf)
)
),
0.25, Pbind(
\instrument, \play,
\bufnum, d.bufnum,
\dur, 1
)
], inf)))
Pdef(\qwerty).stop; // ferma
Alla fine tutto si basa sulla cellula ritmica [0.5, 0.25, 0.25, 0.75, 0.25], però, insomma, ha la sua varietà; e uno del primo: (
{
var freq = 220;
var saw = SinOsc.ar(freq);
var mouseX = LFNoise2.kr([1, 0.8], 0.99, 1);
var mouseY = LFNoise1.kr([0.97, 1.1], 0.9, 1);
var filtsaw = BLowPass4.ar(saw, freq * 0.49, 1.0) * ((freq.reciprocal * 0.499)*mouseX) + ((freq.reciprocal) * mouseY);
var comb = Out.ar(0, LeakDC.ar(CombC.ar(saw, 1, filtsaw, 2, 0.01).minNyquist));
comb
}.play
)
CIAO OT: ascolto Echus Chasma intanto. |
|
|
|
« Ultima modifica: Settembre 30, 2007, 10:57:45 pm da cecinestpasmonID »
|
Loggato
|
|
|
|
franz
AAA1
Hero Member
Posts: 828
|
comunque, semplicemente, ogni software è meglio per alcune cose e peggio per altre. sc è più orientato alla creazione di musica composta algoritmicamente, attraverso mutazioni che sono solo parzialmente sotto il controllo dell'utente e ciò - la facilità (forse meglio la sveltezza) con cui lo si fa non che si possa fare solo con sc, eh - lo rende musicale in senso naturale. d'accordo, non del tutto ma sono discorsi lunghi e poco interessanti (intendo i miei, non il topic) grazie pe gli esempi CIAO OT: ascolto Echus Chasma intanto.
OT: roba vecchissimissima! tra un pò metterò cose nuove |
|
|
|
|
Loggato
|
|
|
|
franz
AAA1
Hero Member
Posts: 828
|
comunque, per rispondere ad aledl: io credo che la cosa fondamentale sia ricorrere all'utilizzo di questi mezzi nella giusta misura, senza restarne schiavi e sentirsi costretti ad utilizzarli sempre e comunque. Insomma: nulla ti vieta di usarli tutti per produrre materiale sonoro che poi andrai ad assemblare diversamente, anche se, per come la vedo io, la soluzione migliore tra imparare tutti questi linguaggi "così così", o studiarsene uno approfonditamente e spremerlo fino alla fine, è la seconda. In sostanza, non credo che ci siano cose che con SC si possono fare e con Max no... semmai ci sono cose che puoi fare più facilmente con SC rispetto a Max e viceversa, ma se già conosci Max o Csound metti molto meno ad imparare un procedimento nuovo nel linguaggio che hai studiato, che per imparare un linguaggio nuovo per una necessità specifica |
|
|
|
|
Loggato
|
|
|
|
|
|
aledl
Jr. Member
Posts: 69
|
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  ) |
|
|
|
|
Loggato
|
|
|
|
|
|
|
|
aledl
Jr. Member
Posts: 69
|
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 |
|
|
|
|
Loggato
|
|
|
|
|
|
|
|
|
|
Pagine: [1] 
|
|
|
|
|
