Hello all,
I just wanted a run down on state-saving patches (especially techniques not requiring external libs...)
I'd like to have state-saving in my Gem abstractions (because there are ohhh so many controls) Ideally this would mean being able to save different state sets in one patch and recall them by name. (which probably means hierarchical storage, ie pool) The data could take the form of OSC names, symbols and floats.
external suggestions are welcomed as well, since I'd rather get it to work than entirely cut down the lib dependancies (currently prepend, zexy, osc)
nifty thing is that with the interpolations (special thanks to Thomas), the state changes will make a smooth transition...
Thanks Ben
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
nifty thing is that with the interpolations (special thanks to Thomas), the state changes will make a smooth transition...
May I ask what interpolations you are talking about here?
Frank Barknecht _ ______footils.org__
Hey frank,
pool is what was just on my mind, but your multiple pool instance idea is really brilliant! I may actually be able to do this. :) Are you giving names for each state-set saved in one file, or are you leaving that up to the filename management in pool? I'll have to take a close look at your examples.
the "interpolation" I refer to is thomas's idea to use a lop~ filter on control data to smooth it out. he sent me "smooth" (abstraction) and its bundled with my gem gops. I have one on each of my controllers... Seems to work very well, and I think it makes sense to offload some processing onto DSP land, since I use it rarely.
I've attached "smooth"
Ben ----- Original Message ----- From: "Frank Barknecht" fbar@footils.org To: pd-list@iem.at Sent: Thursday, November 27, 2003 5:32 PM Subject: Re: [PD] state-saving (again)
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
nifty thing is that with the interpolations (special thanks to Thomas),
the
state changes will make a smooth transition...
May I ask what interpolations you are talking about here?
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
pool is what was just on my mind, but your multiple pool instance idea is really brilliant! I may actually be able to do this. :) Are you giving names for each state-set saved in one file, or are you leaving that up to the filename management in pool? I'll have to take a close look at your examples.
Actually there is only one, well, pool pool in my example, so there's only one file to save. But you could just as well use several, wellwell, pool pools. As the pool name is passed as argument to the abstraction it is all up to the user.
I do intend however to use "pool subdirectories" (folders inside pool, not in the filesystem) to organize things and to make local settings possible. I did not yet think through this fully, but the motivation is, that I would like to be able to change sequences in my sseq patches over time. So they would probably need to have their own, constantly changing data pool. Maybe subdiretories should be organized like:
pool sseq: bar1: step1: 92 step2: 0 ... step16: 60 bar2: sttep1: 0
and so on. Then an external timer (metro) would switch states accordingly.
But maybe pool is not the right tool here, as that is more like sequencing and not like statefulness.
the "interpolation" I refer to is thomas's idea to use a lop~ filter on control data to smooth it out. he sent me "smooth" (abstraction) and its bundled with my gem gops. I have one on each of my controllers... Seems to work very well, and I think it makes sense to offload some processing onto DSP land, since I use it rarely.
Now I remember reading that discussion, thanks.
Frank Barknecht _ ______footils.org__