Il Suono Virtuale - Forum

ciao a tutti,
sto ritrasformando una mia patch per gestire da una master p.storage tutti i tools che si trovano sparsi in giro (che anche loro funzionano con un altro p.storage) : riverbero, dly, harm, playlist, spazializzatore.........

sì mi funzionano tutti i tools (nell'esempio che ho allegato solo 1 tools con 2 preset), quindi mi appaiono tutte le modifiche ma non mi cambia il nome dei preset.

potete aiutarmi?

ciao
marco

p.storage http://www.pelado.co.uk/?p=36
in allegato la mia patch

ciao marco

ho dato uno sguardo al volo e credo he il problema dipenda dal fatto che i p.storage che hai messo nei tools non sono controllati dal pattrstorage principale, quindi servono a salvare i parametri ma il restoring di questi non passa attraverso loro. Non so se mi sono spiegato bene, comunque continuo a dare un'occhiata per cercare di capire il problema, magari intanto si fa vivo qualcun'altro.
Hai provato a mandare una mail a pelado?

ciao franz, no, non ho ancora scritto a pelado...

se vai nel p.view del master vedi che lui 'vede' master::tools1 e giustamente modifica tutti i pattr contenuti nei tools (valore 1 e valore 2).
Infatti  così la cosa è molto pratica, appena costruisci un tools da un bpatcher non devi far niente; il master lo vede.

dobbiamo solo modificare non so come (o aggiungere un pattr....) il salvataggio dei preset...

...sì, non è facile da spiegare........

esattamente, quello che il pattr non vede è l'ubumenù contenuto nel p.storage in tools, che è quello che serve a te.
Una situazione non troppo carina ma funzionale può essere quella di aggiungere un ulteriore ubumenù, direttamente dentro il tuo bpatcher e collegato all'ubumenù di p.storage e collegarlo ad un oggetto pattr.

ci avevo pensato, potrebbe essere una soluzione, se non troviamo altro.....

secondo me l'inghippo sta qui: tutte le volte che si richiama con il menù recall si interroga con un messaggio "getslotname" il pattstorage collegato alla bpatcher p.storage, mentre quando il recall di un preset "locale" viene fatto in modo remoto da un pattrstorage master, il messaggio "gestslotname" non viene mandato per cui il menu display con il nome del preset non viene aggiornato..io c'ho guardato un po velocemente e a dirvi la verità non riesco a trovare in che subpatch c'è il trigger del messaggio sopracitato...per cui la mia è un ipotesi però mi sembra plausibile ;)

il trigger viene dal route interno mi sembra, il problema è esattamente quello che dici tu come dicevamo anche prima in altri termini: il p.storage e il relativo ubumenù nel bpatcher del tool non vengono contemplati (ovviamente) dal pattrstorage principale quindi per non "hackare" l'abstraction di pelado, conviene mettere un ubumenù ulteriore da popolare con i nomi dei preset relativi che di volta in volta vengono salvati e triggerarli quando serve  :)
insomma o si edita il p.storage o si risolve in maniera "esterna". Probabilmente è un'abstracion non pensata per uno scopo simile oppure è una features cui pelado non ha pensato

fixed ;)
eheh

grande mic!  :D

giusto un problema: i files contengono il seguente testo

niente non riesco ad incollare il contenuto, è formattato in una maniera strana, non appropriata a max, come hai salvato le patch?

scusate non avevo allegato l'abstraction di pelado che ho "minimamente" modificato..che poi è lì che pelado non aveva previsto la feature...

la roba di marco rimane uguale, ho fatto solo una piccola modifica alla patch fondamentale che sta dentro alla p.storage.BP.pat :)

chiaro, ma comunque i files che hai allegato non si aprono ed hanno una strana formattazione, ero curioso di capire il perchè

..mmm...tutti?..boh

grandi grandi !!!!!!!

vi lascio un paio d'ore e mi risolvete tutto!!!!!!!!

grazie mille

 :-*

...e funziona anche con 2 tools uguali......

adesso allego il file.....

Bad news per Windows...

ubumenu: 'setcheck' is not supported in Windows
ubumenu: 'setcheck' is not supported in Windows
ubumenu: 'setcheck' is not supported in Windows
ubumenu: 'setcheck' is not supported in Windows
p.storage::file:: concertomaster.xml 1
p.storage::file:: tools1.xml 1
ubumenu: 'setcheck' is not supported in Windows
ubumenu: 'setcheck' is not supported in Windows
ubumenu: 'setcheck' is not supported in Windows
ubumenu: 'setcheck' is not supported in Windows
p.storage::file:: concertomaster.xml 1
p.storage::file:: tools1.xml 1


Peccato Marco se no lo usavamo per le patch dei bimbi... quando ho tempo vedo se riesco a sistemarlo.

..non ho capito cosa intendi marco per funziona anche con due tools uguali..adesso sono fuori casa, stasera dò un occhiata alla tua patch...cioè è un problema se funziona con due tools uguali?..mi raccomando, non devono avere al loro interno il pattrstorage con lo stesso nome (nel tuo caso era "tools1" perchè altrimenti caricano gli stessi preset e immagino che cambino nello stesso tempo..devi usare degli argomenti variabili #...

bruno non ho un win per provare... fammi sapere

mic: naturalmente i 2 tools uguali hanno lo stesso nome di pattrstorage, sono la stessa patch.
infatti è per questo che son contento: la master li riconosce come se fossero diversi
una volta tanto funziona tutto bene!!!!

vi allego il solito patch MASTER.pat che gestisce 2 riverberi [gigaverb] e come vedete dal master preset1 carica 2 riverberi 'alloff', master preset2 carica 2 riverberi diversi.

spero di essermi spiegato  :)

bella storia!!! li per li non c'avevo pensato che poteva vederli come due tools "distinti" però pensandoci bene mi torna..cmq mi rimane solo una cosa che secondo me andrebbe sistemata: come hai fatto tu il file xml gigaverb è la collection dei preset di default standard dell'effetto, però può capitare che in una patch io modifichi i parametri di default per esempio e voglio salvarli in modo che si carichino solo conla patch che sto usando per quella performance, insomma con quel set-up...è una cosa normale, però in realtà non è proprio semplice...spero di essermi spiegato..

..per questo se io aggiungo un preset per esempio "my-room" solo a un tool gigaverb e non voglio però aggiungerlo ai preset di default, devo salvare un nuovo file gigaverb2.xml e salvare naturalmente con il preset aggiornato anche il master...poi la volta successiva che riapro quella patch devo caricare a mano il file gigaverb2.xml...

sì, mic hai proprio ragione... effettivamente io lavoravo così, prima, con il mio m.storage...ma il casino era appunto ogni volta dargli un valore #1 nel bpatcher ... .... ....... e alla fine non mi è mai capitato di usare differenti preset per lo stesso tools ripetuto (mi trovo tutti i preset e mi uso solo quello che mi serve).

p.storage in questo caso li distingue ma non puoi fare 2 liste diverse. questo però mi ha velocizzato molto la costruzione del patch: non devo più inserire #1 #2 .... ma solamente bpatcher e fare open suoi miei tools.

ancora grazie  :)

..ma figurati ;D..più che altro grazie a te che hai portato l'attenzione su questo modo di usare pattrstorage..a essere sincero io non avevo mai notato che un master poteva storare l'index dei preset richiamati nei pattrstorage sotto di lui..figa sta cosa, ora il passo successivo è quello di fare in modo che in automatico il master salvi anche il nome (ed eventualmente relativo path) dei file xml dei pattrstorage dei tools per ovviare all'ultima questione che dicevamo e per essere proprio perfettini :)

si può usare anche la modalità greedy di pattrstorage per questo proposito

..giusto..

dai franz, posta una patchettina con modalità greedy !!!  :)

..però a me greedy non mi ha mai convinto fino in fondo..bisogna fare un po di prove..

in che senso non ti ha mai convinto?

mi spiego, è una feature importantissima però quando attivata ottieni un mega file gigante xml con tutti gli oggetti esposti con pattr (a quel punto non ricordo se i pattrstorage dentro i vari moduli continuano a essere visti o se proprio vengono ignorati, contrariamente si dovrebbe dare a questi una priority più bassa per non interferire con il recall generale), non mi sembra che si possa azionare greedy in maniera selettiva cioè scegliendo quali pattrstorage "fagocitare" e quali no..alla fine è una questione di lana caprina!

veniamo ad esempio pratico..come Reason, ogni modulo ha i suoi banks di preset default (nel nostro esempio di max sarebbero i  file dei singoli pattrstorage tools),  le impostazioni dei parametri specifiche solo di una song vengono salvate nel progetto o song (che sarebbe il pattrstorage master con greedy attivato)..mi sembra che sia sensato..hai ragione franz!

io in un patchettone veramente un po' gigantesco ho usato la funzione greedy ed è stato comodissimo e efficace.

consiglio vivamente.


lorbi