Effetto "vinile" ?

[franz]

nella prima patch il crash si verifica in caso di elevata inerzia ed elevata velocità di scrubbing. Grossomodo mi sembra che ciò avvenga anche nella seconda patch.

Ho verificato un bel po di volte, effettivamente il problema è proprio quello che dice franz: se a line~ vengono dati troppi dati troppo in fretta, crasha.

line~ non c'entra, lui resiste a qualsiasi mole di dati, il problema è nella quantità di dati che riceve sfplay~ tramite line~ insieme ai vari preload secondo me

ma siamo proprio sicuri che non sia un problema di windows xp?

be se fosse così sarebbe abbastanza scandaloso però... vorrebbe dire che anche gli oggetti della libreria di base di msp sono stati implementati in maniera differente per le due piattaforme (come molti externals). Vado di report alla cycling?
[/quote]

oppure vuol dire semplicemente che Windows e Mac hanno librerie di qualche tipo differenti ed è probabile che pur essendo sfplay~ compilato in maniera corretta nella versione per Win, il SO in questione abbia delle API o altre cose del genere, non proprio ottimizzate...in qualche modo sarebbe svelato l'arcano, non mi sembra una cosa così improbabile, secondo me vai di report a Cycling74

Comunque su Mac assolutamente nessun crash anche in casi estremi.

[Maurizio Giri]

prova a vedere se una patch minimale tipo quella che riporto qua sotto ti dà problemi. Se sì, è il caso di segnalarlo a cycling (magari conoscono già la soluzione).

m

PS: il cambio di velocità è limitato tra -8 e 8, se non va in crash prova a togliere i limiti al number box.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 254 84 65 196617 3 click here;
#P comment 338 83 123 196617 4 change speed - crash?;
#P comment 131 82 65 196617 2 click here;
#P newex 252 128 27 196617 b;
#P button 252 105 15 0;
#P flonum 337 103 35 9 -8. 8. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 84 104 30 196617 open;
#P message 285 154 14 196617 2;
#P user gain~ 269 244 21 89 158 0 1.071519 7.94321 10.;
#P message 176 363 27 196617 stop;
#P message 176 346 67 196617 startwindow;
#P newex 249 363 29 196617 dac~;
#P user gain~ 245 244 21 89 158 0 1.071519 7.94321 10.;
#P message 245 156 37 196617 loop 1;
#P message 129 104 112 196617 preload 2 0 50000 1 1;
#P newex 337 129 66 196617 pack 0. 100.;
#P newex 337 151 30 196617 line~;
#N sfplay~  2 60000 1 ;
#P newobj 245 183 95 196617 sfplay~ 2 60000 1;
#B color 5;
#P comment 58 84 62 196617 1 open file;
#P connect 15 0 5 0;
#P connect 4 0 1 0;
#P connect 11 0 1 0;
#P connect 5 0 1 0;
#P connect 12 0 1 0;
#P connect 1 0 6 0;
#P connect 9 0 7 0;
#P connect 8 0 7 0;
#P connect 6 0 7 0;
#P connect 14 0 15 0;
#P connect 10 0 7 1;
#P connect 1 1 10 0;
#P connect 6 1 10 0;
#P connect 15 1 11 0;
#P connect 2 0 1 1;
#P connect 13 0 3 0;
#P connect 3 0 2 0;
#P window clipboard copycount 19;

[brunozamborlin]

Maurizio potrei chiederti di postare le versioni perfezionate dello scrubber per sfplay~ ?

Mi interesserebbero per un lavoro che sto facendo, mi faresti un favore! 

[happyjoint]

l'ultima patch postata mi ha mandato in crash max su windows mentre sul mac funziona benissimo

[brunozamborlin]

Mi rispondo da solo, pare che il problema fosse il line~. Sostituendolo con un triste "speed $1" (quindi usando un segnale di max anzichè di msp) non crasha.

Tra l'altro crasha anche con i Mac Intel, mentre con i PPC no 

[Maurizio Giri]

argh, è vero! Va in crash anche sui mac intel!!
Ho scoperto comunque che e' la velocità: non deve essere troppo bassa. Prova a dargli un messaggio "speed 0.000001", a me va in crash. "speed 0" ovviamente funziona.
Ho scritto alla mailing list di max, quasi sicuramente è una divisione per 0 all'interno di sfplay~ (i processori ppc gestiscono la divisione per 0 senza andare in crash, gli intel no)

m

ps. bruno, mi dispiace ma non ho più perfezionato le patch di scrub dalla prima volta che le ho postate.