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