annosa questione del timing

[mic]

volevo riportare l'attenzione sulla questione dell timing in max e della non accuratezza che a volte questo può avere
http://www.cycling74.com/forums/index.php?t=msg&th=22112&start=40&rid=0&S=4afaddfa3a9473510a00c5b3820e9f72

..come vedete lo stesso jkc (uno dei programmatori della c74) ammette che trasformare un segnale: phasor>edge>bang per ottenere un metro, pur essendo spesso più affidabile di un metro normale in definitiva vanifica la sample accuracy 

[brunozamborlin]

Non ho letto il topic, però credo che questa questione si potrebbe riportare alla più generale quesitone della "priorità dei thread" che funzionano, da quello che so, solo internamente a Max.
E in realtà credo sia tutto li il problema...

[franz]

dovrebbe essere così in effetti, problemi legati allo scheduling dei dati e alle priorità, qui è spiegato tutto quanto:

http://www.cycling74.com/story/2005/5/2/133649/9742

[mic]

..questa purtroppo è una delle poche cose che mi fanno scendere max..voglio dire, come quel topic lì nell'archivio della lista c'e ne sono molti altri, questo dovrebbe far pensare parecchio gli sviluppatori su come questo problema sia sentito e frustri moltissimi users, e non capisco come alcuni si ostinino a dire che se non riesci a ottenere un metro solido il problema è tuo che non sei capace di programmare..mah..secondo il mio umile parere il timing interno e il timing con devices esterni non dovrebbero rientrare tra quelle cose per cui uno si deve scervellare e provare decine e decine di setaggi e possibilità..cioè dovrebe essere una cosa scontata o quasi..

[brunozamborlin]

Si hai ragione. Il metro dovrebbe andare a x ms, e stop...

Non centra ma ogni tanto bisogna ripeterlo: l' UNDO ! 

[franz]

eh...aggiungiamoci l'UNDO che non fa mai male...!

Comunque è vero, anche perchè in alcuni casi l'instabilità di [metro] è qualcosa di seriamente intollerabile e compromettente e perdere magari un'ora a stabilizzare una funzione di timing, secondo me, è veramente tempo buttato...
Appena ho tempo voglio indagare se questo problema si verifica anche in PureData, SuperCollider e Csound: per il primo purtroppo temo di si, per il secondo credo di no, per il terzo sono abbastanza sicuro della stabilità in fatto di timing per via della variabile di inzializzazione "kr"...qualcuno ne sa di più?

[brunozamborlin]

non so se csound risenta di questo problema di priorità dei thread, ma non centra la variabile kr... quella è solo una variabile, c'è anche in max ed è settata nel dsp status.

[franz]

c'è una variabile per impostare il control rate nel dsp status? 

[Maurizio Giri]

c'è una variabile per impostare il control rate nel dsp status? 

Beh, in maxmsp un control rate vero e proprio (alla csound) non c'è. C'e' il "max scheduler" che normalmente è indipendente dall'audio. E' però possibile sincronizzarlo con l'audio rate impostando il parametro "Scheduler in Audio Interrupt" nel dsp status, in questo modo i messaggi max vengono trasmessi prima del calcolo di ogni signal vector, è quindi una specie di control rate legata alla lunghezza del vettore. Da notare che quando questo parametro è attivato anche i messaggi max pesano sulla cpu.

m

[franz]

Ah ok il max-scheduler! Avevo capito mi fosse sfuggita una vera e propria variabile "ksmps-style" che mettesse in rapporto la frequenza di campionamento con la "frequenza-k" dei controlli!

[brunozamborlin]

Si franz ma è circa la stessa cosa... il problema cmq non sta li, ma nella priorità.

Dico al metro di bangare ogni 100ms, ok, ma se poi ho l'antivirus che mi piglia la cpu per 3 ms, in quei 3 ms in contatore di max si ferma, quindi avrò un ritardo di 3 ms sul prossimo bang...
L'audio ha priorità più alta perchè considerato dallo scheduler un processo realtime.

[Maurizio Giri]

Ok, ma se metti lo scheduler in audio interrupt questo problema non si pone, giusto? Max acquisisce la stessa priorità dell'audio.
Ho fatto un esempio che, almeno sul mio mac, lo dimostra: sottraggo un segnale generato esclusivamente via audio ad un altro generato tramite un bang e, se il signal vector è pari a 1 e lo scheduler è in audio interrupt i due segnali si annullano a vicenda e non si sente niente (ovvero sono sincronizzati al campione).

Occhio che la patch ti cambia i settaggi del dsp status (signal vector e overdrive): poi devi rimetterli come li usi di solito.

m

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 152 120 60 196617 loadmess 1;
#P comment 171 175 575 196617 signal vector di 1 campione - Scheduler in audio interrupt - i click sono in sinc e NON sono udibili!;
#P comment 171 161 575 196617 signal vector di 1 campione - Scheduler NON in audio interrupt - i click non sono in sinc e sono udibili;
#N vpreset 3;
#X append 1 2 16 198 326 umenu int 6 \; 17 122 87 flonum float 12. \; 20 247 329 umenu int 1 \; 22 228 329 umenu int 1 \;;
#X append 2 2 16 198 326 umenu int 0 \; 17 122 87 flonum float 12. \; 20 247 329 umenu int 0 \; 22 228 329 umenu int 1 \;;
#X append 3 2 16 198 326 umenu int 0 \; 17 122 87 flonum float 12. \; 20 247 329 umenu int 1 \; 22 228 329 umenu int 1 \;;
#P preset 152 148 17 37;
#P comment 189 230 134 196617 Max Scheduler in Overdrive;
#P comment 189 248 135 196617 Scheduler in Audio Interrupt;
#P user umenu 329 228 49 196645 1 64 244 0;
#X add Off;
#X add On;
#P hidden newex 452 228 94 196617 adstatus overdrive;
#P user umenu 329 247 49 196645 1 64 263 0;
#X add Off;
#X add On;
#P hidden newex 452 247 89 196617 adstatus takeover;
#P comment 231 200 90 196617 Signal Vector Size;
#P flonum 87 122 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P user umenu 326 198 72 196645 1 64 214 0;
#X add 1;
#X add 2;
#X add 4;
#X add 8;
#X add 16;
#X add 32;
#X add 64;
#X add 128;
#X add 256;
#X add 512;
#X add 1024;
#P hidden newex 484 198 73 196617 adstatus sigvs;
#P window setfont "Sans Serif" 18.;
#P comment 156 290 52 196626 Max;
#P window setfont "Sans Serif" 9.;
#P newex 70 318 58 196617 delay~ 1 1;
#P newex 70 266 37 196617 *~ -1;
#P newex 139 269 36 196617 edge~;
#P message 47 489 27 196617 stop;
#P message 47 472 67 196617 startwindow;
#P newex 120 489 29 196617 dac~;
#P user gain~ 120 369 21 89 158 0 1.071519 7.94321 10.;
#P newex 87 204 42 196617 ==~ -1;
#P newex 87 177 46 196617 change~;
#P newex 87 142 46 196617 phasor~;
#P newex 139 321 37 196617 click~;
#P window setfont "Sans Serif" 18.;
#P comment 10 289 52 196626 MSP;
#P window setfont "Sans Serif" 9.;
#P window linecount 3;
#P comment 53 65 350 196617 un click costante in audio rate viene sottratto ad un click guidato dal max scheduler: se fossero perfettamente in sync non dovrei sentire niente perché si annullerebbero a vicenda;
#P window linecount 1;
#P comment 171 147 576 196617 signal vector di 64 campioni - Scheduler in Audio interrupt - i click non sono in sinc e sono udibili;
#P connect 6 0 12 0;
#P connect 12 0 13 0;
#P connect 17 0 4 0;
#P connect 4 0 5 0;
#P connect 5 0 6 0;
#P connect 3 0 7 0;
#P connect 13 0 7 0;
#P hidden connect 25 2 7 0;
#P connect 7 0 8 0;
#P connect 10 0 8 0;
#P connect 9 0 8 0;
#P connect 6 0 11 0;
#P connect 11 0 3 0;
#P connect 7 0 8 1;
#P connect 28 0 25 0;
#P hidden fasten 15 0 16 0 489 219 472 219 442 194 331 194;
#P hidden fasten 21 0 22 0 457 248 419 248 389 226 334 226;
#P hidden fasten 19 0 20 0 457 267 440 267 410 245 334 245;
#P hidden fasten 22 0 21 0 334 246 393 246 419 225 457 225;
#P hidden fasten 20 0 19 0 334 265 414 265 440 244 457 244;
#P hidden fasten 16 0 15 0 331 217 446 217 472 196 489 196;
#P window clipboard copycount 29;

[brunozamborlin]

Grande maurizio, effettivamente non si sente niente. Però..... non ho ben capito perchè

Dunque io vedo un segnale generato con MSP, che viene moltiplicato per "-1" e poi viene ritardato di un campione.

E poi vedo un segnale generato da un click~ che viene pilotato tramite bang, quindi ambito Max.
Ma perchè, con vector size = 1, il click~ e l'altro segnale sono esattamente in controfase?

[Maurizio Giri]

allora, vengono generate due serie di clic, una pilotata da MSP e l'altra da Max.
I clic (che sono dei singoli campioni di valore 1 all'interno di una sequenza di 0) sono scanditi (teoricamente) alla stessa frequenza.
La serie pilotata da MSP viene moltiplicata per -1, in modo da avere dei clic con segno negativo (che dal punto di vista uditivo sono la stessa cosa) che quando sono perfettamente in sincrono con i clic positivi di Max si sommano algebricamente a questi annullandosi (come nello scontro tra materia e antimateria  ).
Il ritardo di un campione l'ho trovato empiricamente, evidentemente nel passaggio da MSP a Max e viceversa si perde un un ciclo, ma questo ritardo è costante e viene compensato dall'oggetto delay~ nel "lato MSP"

m

[brunozamborlin]

Perfetto.
E, scusa la goffaggine, perchè questo avviene solo con il signal vector pari ad 1?