Ciao,mi sono sempre chiesto se ha senso conoscere tanti linguaggi di sintesi del suono,non basta csound?il piu usato,versatile,in continuo aggiornamento,con un ampia documentazione?oppure esistono altri linguaggi magari adatti ad una sintesi piuttosto che un altra?o che usano una sintassi piu facile?ho sentito parlare di Commun music,Nyquiste ma in rete non ho trovato molto materiale al riguardo.....

Secondo me può aver senso a livello di "cultura personale" e di curiosità.

Ma il fatto è che, salvo forse qlc caso estremo, con ogni linguaggio dignitoso si può far tutto. Solo che alcuni linguaggi sono più comodi per alcuni aspetti, altri per altri.

Credo che ci siano vari "stadi", uno dei quali sia la scelta del linguaggio. Superato questo stadio, salvo gravi motivi, bisognerebbe cercare di imparare ad usarlo al meglio senza perdere energie in altre cose, altrimenti davvero non si produce più nulla...

Poi io parlo da musicista, magari voi avete un approccio più "orientato alla teoria"

ps: mi piacerebbe porre un quesito: trovatemi almeno due cose che si possono fare con chunk (e lo stesso potremmo fare con csound) e che con max NON si possono fare (non ho detto "è più scomodo, ma proprio NON si possono fare).
Ne sarei curioso.

Si quella è una strada possibile. Costruire delle architettura modulari dove i componenti siano scritti nei linguaggi più consoni a quelle particolari esigenze (o conoscenze del programmatore) e farli dialogare insieme. Questa è una strada molto più interessante.

Forse siamo ancora un po indietro, ma già OSC ad esempio sta tentando di spianare questa via.

in teoria sarebbe possibile con un accrocco tipo Framework, che si rivela, appunto, fallimentare visto che va in crash proprio per motivi del genere legati al DSP attivo!

Tornando a ChuCK rispetto a SuperCollider  mi sembra che non ci sia questo abisso...o sbaglio?

no no, il problema è che gli oggetti di mac (sia che siano scritti in c sia he siano scritti in java sia che siano abstraction) chiamano un metodo (in java si chiama dsp_performer mi pareva) che viene invocato ogni qualvolta viene interrotta la dsp-chain. questo metodo interrompe l'audio, esegue e poi fa riprendere l'audio.

ok qui dò ragione a maurizio, però si può trovare un escamotage... ad esempio, anzichè aggiungere un modulo finchè si suona, non è possibile scrivere una patch che contenga già il suddetto modulo, ma che sia in bypass fino a che non si decide di volerla usare?
l'effetto sarebbe identico...

e per l'ordine dei moduli, non basta usare una matrice audio?
maurizio tu ne sai molto (ma molto  ) più di me, ma non ti pare che effettivamente si possa sempre trovare una soluzione alternativa che produce lo stesso risultato?

poi ovvio la mia è una provocazione, solo per dire che mi pare un po inutile (se non a fini puramente teorici) imparare più di un linguaggio di computer music.

Simile, ma non identico. Puoi solo utilizzare i moduli che avevi previsto e caricato. Il "bello" di Chuck e Supercollider è che ti puoi inventare qualsiasi cosa e codificarla al volo, durante l'esecuzione.


L'unico modo che conosco per caricare da disco un modulo senza interrompere la catena dsp, è caricare un vst avendo previamente mandato il messaggio "disable 1" all'oggetto vst~.
A questo punto mi viene in mente che una soluzione (macchinosa) potrebbe essere:
1- far girare il sistema sulla versione runtime di MaxMSP (tanto non deve essere editato)
2- scrivere una nuova patch nella versione full di MaxMSP e salvarla come plugin
3 - caricarla nella versione runtime (dopo aver inviato il messaggio "disable 1" a vst~
4 - usare il nuovo plugin, senza interrompere la catena dsp, inviando il messaggio "disable 0" a vst~
5 - farsi ricoverare!


Su questo non sono d'accordissimo. Secondo me è certamente poco pratico studiarsi troppi linguaggi, e naturalmente si corre il rischio di passare da un linguaggio all'altro senza approfondirne nessuno. Però ogni linguaggio ha i suoi punti forti e i suoi punti deboli, e fatalmente si tende a sfruttare i punti forti e ad evitare quelli deboli e quindi a non fare determinate cose solo perché con quel linguaggio sarebbero troppo macchinose. Quello che voglio dire è che, poco o molto, il linguaggio che scegli tende anche a condizionare la tua produzione (non c'è niente di scandaloso in ciò, anche gli strumenti acustici hanno questo "difetto"): insomma, alla fine non è vero che puoi farci tutto-tutto. Anche perché puoi già fare tutto in linguaggio macchina, e quindi a che servono gli altri linguaggi?
Concludendo questo post eccessivamente lungo, credo che conoscere un paio di linguaggi (come ha anche detto franz) con caratteristiche molto diverse, come appunto Max e SC, possa essere utile, anche se poi si utilizzerà quasi esclusivamente uno dei due.

m

SC è molto amico di OSC...ma moooolto molto amico