Il Suono Virtuale - Forum

Ciao a tutti, un quesito a cui potrebbero rispondermi anche i maxers meno esperti, inquanto problema di interfaccia e di "user-friendly".

Dunque, situazione classica: ho "x" linee di ingresso (credo saranno 3 mono e 2 stereo) che possono passare per "y" effetti per poi finire in 2 linee di uscita.

Sto provando a pensare ad un'interfaccia grafica per cambiare il routing audio "in tempo reale".
Quello che mi è venuto in mente è l'utilizzo di un matrix~, però non mi piace molto come soluzione.
Poniamo ad esempio che l'ingresso 1 stia passando per l'effetto 1 per poi finire direttamente nelle uscite. Io vorrei un'interfaccia che mi renderesse semplice il passaggio da questa situazione ad una situazione del tipo: ingresso1 -> effetto2 -> uscita.

Con matrix~ purtroppo se prima cancello il "pallino" nel punto "ingresso1-effetto1" e poi attacco quello "ingresso1-effetto2" poi dovrò anche crearne uno del tipo "effetto2-uscita" e togliere quello "effetto1-uscita".
Insomma, è scomodo.

Qualcosa del tipo "drag'n'drop" che permetta di ordinare una catena di "n" effetti sarebbe l'ideale ad esempio.

A qualcuno viene in mente qualcosa?

Thx :)

ciao bruno!

prova a vedere questa patch d'esempio.

è un modo semlice e chiaro per gestire queste cose...discutibile  :)

Grazie marco. Il fatto è che nella tua patch si vede come gestire un audio routing con una matrix~, che come ho scritto non è quello che voglio.
Lo trovo scomodo per una serie di motivi: oltre ad essere poco immediato graficamente, ha il difetto di necessitare di 4 passaggi per cambiare routing. Mettiamo caso che voglio passare da:
in1 -> reverb -> out1

a:

in1 -> delay -> out1

Allora dovrò fare:
1-togliere la casella "in1,reverb";
2-togliere la casella "reverb,out1";
3-aggiungere la casella "in1,delay";
4-aggiungere la casella "delay,out1".

Spero di essermi spiegato.

Non sono sicuro di aver capito quale sia il problema: matrix~ e' l'oggetto di riferimento per smistare dinamicamente i segnali, ed e' il piu' economico dal punto di vista della CPU.
Mi sembra che quello che tu trovi scomodo sia l'oggetto matrixctrl che serve a visualizzare e gestire graficamente le connessioni, ma matrix~ come certamente sai puo' essere comandato da semplici messaggi (liste di numeri) per connettere e disconnettere i segnali. Se metti tutti i messaggi  relativi all'esempio che citi in un message box li puoi inviare tutti in una volta con un singolo clic del mouse, oppure li puoi mettere in una coll o in un qlist e richiamarli con un bottone apposito, etc. insomma puoi fare tutto quello che vuoi... o mi sfugge qualcosa?

m

anche a me l'idea di una coll con i valori memorizzati da mandare ad una matrice audio sembra una buona idea...
e come interfaccia usi "n" ubumenu per ogni linea che richiamano gli index dalla coll..
..però nel modo che hai detto tu sopra non prevedi di mandare l'out di un effetto all'in di un altro effetto...
 altra cosa, non ho capito se ogni linea debba avere una sua catena di di n effetti o se la catena sia solo una e sul main out e che riceve le mandate..

Hai centrato il problema :)
Il problema in questo caso non è di come implementare qualcosa, ma di come visualizzarlo... Voglio dire, ok posso inviare dei messaggi ad un matrix~, con coll o con quello che voglio, ma come li rappresento graficamente? Come posso, in un unico gesto, cambiare l'audio routing?
La cosa bellissima sarebbe quella di avere una piccola colonna di "scatoline" con scritto "delay", "reverb" ecc.. da poter draggare in alto o in basso, e che a queste corrispondessero dei messaggi da inviare a matrix~. Esiste qualcosa del genere in Max, o magari in Jitter?

scusa mic non ho ben capito... questi ubumenu mi direbbero solo "da" dove "a" dove, ma per cambiare tutto il routing ci si mette una marea di tempo perchè, se "n" è il numero di effetti caricati, servirebbero "2n" menu da "n+2" elementi (contando 2 ingressi e 2 uscite della scheda).
O forse non ho capito che intendi.

ciao bruno...
sì la patchettina esempio che ho postato è il motore di tutto quanto che naturalmente non vedrai neanche e che verrà gestita da coll, ubu, table,
io lavorerei come un mixer normale: sopra ogni fader d'entrata ti costruisci n. ubu dove puoi inserire qualsiasi effetto. E sotto scegli l'uscita che vuoi. questa potrebbe essere una soluzione, non molto aperta (gestione di uno spazializzatore real time...), ma dipenda a cosa ti serve.

in un unico gesto? io lavorerei con degli storage master presettati.

se invece vi viene in mente qualche cosa di migliore anch'io sono interessato  :)  :)

la cosa é questa.

il motore per essere piú aperto possibile deve permettere che come IN e com OUT ci possa essere qualsiasi cosa.
quindi devo poter entrare in un delay poi le uscite tereo del delay in due chorus diversi, poi magari questi su due OUT e peró doppiandoli anche in un reverbero gigante che uscirá completamente WET solo dlle casse 3 e 4.

se questo é il livello di complessitá del routing, allora é un Matrix, anche visivo.
ti fai i tuoi preset (comunque, per esperienza, vai velocissimo con questo sistema) e poi li richiami "con un sol gesto" con un pattrsotrage o un coll....
sennó per semplificre il gesto sei costretto a semplificare anche le possibili operazioni..mi sa.

besos

lorbi

...ma allora non ho ben capito neanche io quello che volevi dire..se ti serve una cosa tipo: un canale mixer per esempio di logic o di cubase con un numero n di slot in cui inserire effetti e creare una catena allora secondo me si può fare (e mi è capitato di farlo) usando una serie di ubumenu e coppie di send~ e receive~ (l,r) che andrai ad assegnare dinamicamente con i messaggi set..se è questo che ti interessa poi l'interfaccia possono essere ubumenu o scatoline fatte con lcd o js o java ; se invece ti interessa una gruppo di effetti che possono ricevere e mandare da/a qualsiasi parte è un lavoro per matrixctrl, non ci vedo molte alternative..

Grazie a tutti delle risposte.
Dunque, il fatto è questo: matrixctrl non è un buon oggetto per fare questa cosa secondo me, per i motivi che ho già detto (fare 4 passi quando con altre soluzioni ne basterebbe uno).
Quindi, soluzioni:
1-mi salvo tutti i preset che ritengo "utili" (con pattrstorage o coll) che vadano a pilotare un matrix~.
svantaggi:
-non potrei accedere a tutte le combinazioni
-quando aggiungo un nuovo effetto, devo aggiungere gli altri possibili preset

2-una soluzione simile a framework di leatcutter john (o alla mia "ambnt" :D ) dove sostanzialmente ad ogni anello della catena c'è un ubumenu che dà la possibilità di inserire ogni effetto disponibile (mic magari tu intendevi così?)

3-come dicevo, degli oggettini grafici disposti in colonna (ad esempio può esserci una colonne per ogni uscita audio) in un certo ordine. Se ad esempio l'ordine è A-B-C, se io draggo la C sopra la B ottengo l'ordine A-C-B a cui corrisponde un certo messaggio che va ad un matrix~.
svantaggio: so come farla in html e in flash, ma non in max :D

La seconda non ha svantaggi a quanto pare, voi che dite? E ne avrei anche una versione semi-pronta... forse mi conviene prender quella strada.

Ora è chiaro il problema no?

ps: per chi non ricorda "ambnt", posto uno screenshot di una versione di qualche tempo fa, tanto per rendere l'idea (ora è parecchio diversa):

(http://www.brunozamborlin.com/temp/ambnt-screenshot.jpg)

..io avevo in mente una cosa del genere che in realtà non è un vero e proprio inserimento di un effetto ma è un routing dinamico.. è chiaro che messa giu così non è perfetta nel senso che c'è la possibilità di sbagliarsi e creare un feedback però si può risolvere la cosa..;)

..secondo me un'idea carina può essere usare degli slot di effetti come quelli di ambnt all'interno dei quali si possono caricare gli effetti desiderati, e poi il routing cioè l'ordine degli effetti lo fai con il metodo che ho postato...per cui vedrei delle scatoline che si aprono anche come menù a tendina e che poi le posso draggare per odinare come voglio la catena.. l'interfaccia la potresti fare in flash...oppure si può fare un'interfaccia con i quadratini, scatoline draggabili (fatta in lcd con gli sprites..) e i menu si tengono fuori da questa interfaccia così è ancora più semplice e si puo fare tutto in max..

Grande mic, questa idea mi piace proprio... cioè, mettere gli effetti in dei quadratini selezionabili da ubumenu, proprio come in ambnt, ma il cui ordine sia decidibile draggando degli oggetti corrispondenti che stanno in un lcd...
Pare un'ottima idea, però mi cogli impreparato. Riesci a farmi un esempio al volo di come draggare gli oggetti? Nel senso, bisogna pensare ad un modo per cui se draggo una scatolina sopra ad un'altra, quest'ultima si sposta in basso... si mi sa che si può fare però... bell'idea mic :)

  ;) si bisogna escogitare il modo per far si che quando sovrappongo due quadratini quelli di sotto scorrano di uno..stasera ci lavoro e poi vediamo cosa mettiamo insieme..ci riaggiorniamo :)

Ci stiamo riuscendo eh... tutto tramite lcd e js.
A breve qualche screenshot :)

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

si la parte grafica della cosa sta venedo fuori, il problema secondo le prime prove che ho fatto sta nel routing vero e proprio dell'audio, il metodo di send-receive dinamico che avevo proposto pur essendo molto più economico nel consumo di cpu rispetto a matrix è naturlamente molto meno flessibile e non proprio "pulito", a volte ci sono cliks pops and crakles!..natulamente bisognerà introdurre veloci fade nell'audio quando si riordina la catena.. ;)

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

No mic secondo me matrix~, oltre ad essere più semplice e flessibile, è anche più economico.
Ti ricordo che si tratterebbe di utilizzare "n" send~ e "n" receive~, molto più cari di semplici cavi audio. Senza contare tutti gli altri oggetti line~ e compagnia bella che dovresti metterci, che in matrix~ sono già implementati in C.
Il fatto è che quest'oggettino che stiamo facendo dovrebbe davvero essere il più economico possibile, perchè pensato per essere usato su qualsiasi patch.

A domani sera :)

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  ;)

mic, quando parli di send/receive intendi quelli di max, senza la tilde? In questo caso hanno il problema che non possono modificare il mittente o il destinatario, quindi anche se sono effettivamente leggeri mancano della caratteristica principale che vi serve per questo progetto.
Gli oggetti send~ e receive~ invece sono molto più pesanti anche se possono modificare il destinatario tramite il messaggio "set" e sono comunque molto meno pratici di matrix~ per smistare i dati.

La soluzione ottimale secondo me è un matrix~ collegato agli ingressi, alle uscite e ai vari effetti magari tramite dei send e receive (senza tilde, tanto sono fissati una volta per tutte) e ogni effetto è racchiuso dentro un poly~ (ad una voce) che può essere messo in mute quando non serve, per risparmiare CPU.

m

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 ;)

..ma dai..non lo sapevo mica che send/receive senza tilde mandavano anche il signale!!
vergogna!!

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 :)

rispiega?

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;

che dire, grazie mille   :D

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

per mia esperienza personale non sono mai stato un grande sostenitore dei send~ e receive~ e ho ridotto il loro utilizzo alle sole situazioni dove erano indispensabili...ho sempre preferito tirare due-quattro cavi in più perchè le volte in cui li ho usati ho notato anche un uso della cpu molto più forte. Oltretutto lessi, credo proprio sul forum di c74, che se usati in grosse quantità, possono provocare anche fastidiosi problemi di latenza interi ad msp...
Fin ora l'idea migliore, secondo me, è quella di Maurizi: usare un matrix~ con tot canali con un effetto dentro un poly~ ad una voce che va in mute e unmute, magari con un breve fade-in gestito  da matrix~ che ha come starting point l'attivazione del poly~  e lasciar perdere i send~ receive~ :)

teneteci informati sugli sviluppi eh!

La possibilità di mettere il segnale in feedback è chiaramente un vantaggio (pensa ad es. alla modulazione di fase con feedback dei synth DX7 yamaha), il fatto che il feedbk abbia un ritardo minimo di un vector size invece è un limite (anche se esiste un truccaccio per superarlo)

m

molto interessante maurizio.

ma quindi confermi che tu usi s and r e non send~ e receive~ anche per il segnale n linea di massima?


(il truccaccio la prossima volta :) )

yep

m