[PD] state-saving (again)

[Frank Barknecht]

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.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__