[PD-dev] presets... why not?
rama
medialist at xicnet.com
Tue Dec 2 04:56:21 CET 2003
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>
More information about the Pd-dev
mailing list