l'idea è ottima, fateci vedere che siete riusciti a combinare, mi raccomando

gli inviluppi per evitare i clicks fatelli con wave~ e forme d'onda hanning, è la cosa migliore!

dunque bru il discorso è questo, sulla flessibilità ti dò ragione sull'economicità avrei da osservare qualcosa: l'oggetto matrix in realtà non è altro che un mega mixer che poi noi lo usiamo in pratica in modalità binaria 0/1 ma ogni canale può avere tutti i valori tra 0. e 1. per cui quando noi deselezioniamo un canale non è che mettiamo in mute quel canale, cioè non è che metti in mute la parte dsp che non usi, per cui se vuoi fare una catena mettiamo di 10 effetti e, come nel nostro caso non ti interessa poter connettere tutto con tutto, avrai un sacco di "canali" che non userai che peseranno sulla cpu..a proposito avevo letto alcuni post sulla lista ed effettivamente se fai la prova, il metodo con i send/receive è un po più leggero..bisogna fare un po di prove e trovare il giusto compromesso adatto al nostro caso 

intendevo quelli di msp..scusate non avevo messo la tilde, solo che quando sono fuori casa e uso il pc non mi ricordo mai come si mette

Si lo mandano, solo che non fanno alcuni controlli sul vector da quel che ricordo.
Si quella è senz'altro la soluzione più economica... Tra l'altro matrix~ pesa poco... Dai fatta

Come sicuramente sai MSP non elabora il segnale un campione alla volta per poi passarlo al mondo esterno, ma esegue i calcoli a blocchi, detti signal vector, la cui dimensione può essere impostata nella finestra DSP Status.
In generale più piccola è la dimensione del signal vector maggiore è il consumo della CPU (il contrario non è sempre vero).
Gli oggetti MSP che lavorano a coppie, come send~ e receive~, comunicano tra loro tramite un buffer interno che ha la dimensione di un signal vector: ovvero l'oggetto send~ scrive nel buffer interno il blocco di campioni che riceve e l'oggetto receive~ legge questo blocco quando arriva il suo turno di gestire il segnale. Questa procedura non produce alcun ritardo perché l'operazione di lettura e scrittura avviene all'interno del calcolo di un singolo blocco (signal vector). Il vantaggio è che possiamo mettere in feedback il circuito, ovvero possiamo prendere il segnale che arriva a receive~ e rimandarlo a send~: quello che riceve send~ però è il contenuto del buffer precedente (in quanto il nuovo lo deve ancora scrivere!) e quindi il feedback ha un ritardo pari alla dimensione di un signal vector.
Gli oggetti send e receive (senza tilde) invece non sanno niente dei segnali e non comunicano tramite un buffer interno ma mettono direttamente gli oggetti a cui sono collegati in comunicazione tra loro (per questo sono più leggeri per la CPU). Per questo motivo è impossibile metterli in feedback, in quanto dovrebbero passarsi dei dati che non sono ancora stati calcolati.
Questa patch dovrebbe aiutare a chiarire il concetto:

#P window setfont "Sans Serif" 9.;
#P window linecount 5;
#P comment 292 368 173 196617 se trasformate il send~ e il receive~ di questa patch in send e receive il motore DSP andrà in mute perché viene eseguito un feedback non consentito;
#P user gain~ 371 220 21 89 158 0 1.071519 7.94321 10.;
#P user gain~ 144 205 21 89 158 0 1.071519 7.94321 10.;
#P window linecount 2;
#P comment 359 60 100 196617 4) fare clic sul bang button;
#P window linecount 5;
#P comment 441 189 100 196617 5) i click di feedback arrivano alla distanza di un vettore l'uno dall'altro;
#P window linecount 3;
#P comment 167 179 100 196617 3) i due click arrivano contemporaneamente;
#P window linecount 2;
#P comment 164 49 100 196617 2) fare clic sul bang button;
#P window linecount 1;
#P message 298 323 27 196617 stop;
#P message 298 306 67 196617 startwindow;
#P newex 372 344 29 196617 dac~;
#P user gain~ 411 219 21 89 158 0 1.071519 7.94321 10.;
#P newex 329 179 41 196617 *~ 0.9;
#P newex 329 151 95 196617 receive~ tanticlick;
#P button 328 62 15 0;
#P newex 328 87 37 196617 click~;
#P newex 328 127 81 196617 send~ tanticlick;
#P message 46 326 27 196617 stop;
#P message 46 309 67 196617 startwindow;
#P newex 119 326 29 196617 dac~;
#P user gain~ 119 206 21 89 158 0 1.071519 7.94321 10.;
#P newex 144 153 84 196617 receive~ unclick;
#P button 142 50 15 0;
#P newex 142 78 37 196617 click~;
#P newex 142 125 70 196617 send~ unclick;
#P window linecount 4;
#P comment 9 36 100 196617 1) impostare un signal vector size pari a 1024 campioni o più;
#P window linecount 1;
#P comment 372 181 66 196617 feedback;
#P window linecount 4;
#P comment 46 356 173 196617 se trasformate il send~ e il receive~ di questa patch in send e receive senza tilde non noterete alcuna differenza;
#P fasten 4 0 7 0 147 109 124 109;
#P connect 10 0 8 0;
#P connect 9 0 8 0;
#P connect 7 0 8 0;
#P connect 24 0 8 1;
#P connect 5 0 4 0;
#P connect 4 0 3 0;
#P connect 6 0 24 0;
#P connect 7 1 24 0;
#P connect 13 0 12 0;
#P connect 12 0 11 0;
#P fasten 15 0 11 0 334 205 322 205 322 119 333 119;
#P connect 14 0 15 0;
#P fasten 12 0 25 0 333 111 308 111 308 210 376 210;
#P connect 18 0 17 0;
#P connect 19 0 17 0;
#P connect 25 0 17 0;
#P connect 16 0 17 1;
#P fasten 14 0 16 0 334 172 416 172;
#P connect 25 1 16 0;
#P window clipboard copycount 27;

molto interessante, graze mille.

io sapevo che S an R gestivano anche il segnale solo perché lo ho visto fare in alcuni patch di altri...ma non ne ho mai capito il motivo..
risparmio CPU mi sembra un ottimo motivo.

il vantaggio del feedback del vector size invece non lo capisco 


e poi non capisco quindi un'altra cosa: in un utilizzo normale di invio di un segnale..che so..a un mixer finale del patch piuttosto che solo ai lead di visualizzazione della dinamica...voi suggerite di usare s and r e non send~ e receive~ in quanto piú leggeri?


grassie mille

lorbi