[PD-dev] presets... why not?

[rama]

eo, i'm interested in this preset thing.

what about interfacing pd to a database (ie: mysql) for this?
might affect performance/response or that shouldn't be a problem?

i was thinking about databases for this in order to have easier
administration for presets, like naming, describing, easy access from
remote PD nodes to download "published" presets,  +

there we could save version of the "state saver interface" and show a
"modified saver" warning upon a recall within saver/saved-data version
mismatch for example.

let me know if useful, in fact, what about the database consideration
mainly in a realtime context?

cheers,
rama

El dom, 30-11-2003 a las 18:18, Frank Barknecht escribió:
> Hallo,
> 
> Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
> 
> > just managed to scan over all the recent talk about state saving,
> > presets, etc. on the pd list...
> > 
> > ...no doubt I am thinking slow.  In fact, I have not even figured
> > out yet, why any generic, user-friendly mechanism for storing and
> > recalling run-time state is bad in principle.
> > 
> > Perhaps the reason is not technical at all... but what is it?
> 
> I'd be interested in that, too, but regardless of what Miller will
> decide: After reading all the talk, the vote of the public seems to be
> strongly pro-saving. So it will have to be done one way or the other.
> Doing it as abstraction is tedious. The most simple and still flexible
> an general solution I could come up with so far is available here: 
> http://www.pure-data.org/Members/fbar/patches/memento-0.1.tgz/view
> 
> Even that is actually complicated and requires the pool external (plus
> prepend).
> 
> I'd love to throw it in the trash can if we could instead get a more
> general solution inside Pd.
> 
> ciao
-- 
rama <medialist at xicnet.com>