hi all, hi Miller,
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.
Is it so, because it is hard to guarantee that the state being recalled was actually stored for the recalling patch, and, that the patch has not been confusingly modified since?
However, there are several ways to validate a state against a patch, both at a time of state-file loading, and at a time of a recall. None is perfect, theoretically, but this cannot be that important, really. At least, any generic validation method would do better than specific, hand-crafted schemes, patched around textfile, etc.
Apart from load/recall validation, I do not see anything heretical, technically. There is nothing special, for example, about storing object's state using a mechanism similar to the class' save function.
Perhaps the reason is not technical at all... but what is it?
Please, help.
Krzysztof
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
On Sun, 30 Nov 2003, Frank Barknecht wrote:
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.
I think it is a very useful thing to have indeed, I could not imagine the complexity of my patches without the "state" object. But first we have to give the concept one or another thought.
Later the CVS would be a good instrument to proove its feasability. Needless to say that I support fully the ideas hc. posted some days ago about using the CVS.
So, we just have to decide what we want, and then implement it ..
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
I think it is a very useful thing to have indeed, I could not imagine the complexity of my patches without the "state" object. But first we have to give the concept one or another thought.
Yes, we should definitely collect, what might be expected of a preset system, a specification. I didn't use [state] for years, I guess, and just now looked at the help patch again, when the first problem arose. Clicking 1 gave:
state: unable to open /usr/lib/pd/doc/5.reference/state.1
This is one feature I would like to see: Saves should not automatically select a save file, but should require a (full) path to a file provided by the user. Maybe [state] allows that, I didn't look very hard, it's just something that stroke me when it happened.
Then I figure that two kinds of preset behaviour would be cool. One is of course persisting things to the disk, the other is a kind of preset in memory. If you look at my just announced memento-0.2.tgz: Here the new "substate" feature is just that, a way to switch states on the fly, without the need to store to or load from disk.
In the end this will of course lead to a tightly related thing: automation. Automation could be seen as switching states (or presets) on a higher level than just some message passing to change a float value. I shortly mailed with Thomas Grill about that and he remarked, that in complex patches changing a lot of values at once can get very costly if all this is done through messages. Moving all that data around through send/receive might be slow. (I didn't do any benchmarks yet...)
Another very important feature IMO is the saving and loading of states in child patches from the parent patch and into a single file (or several files in a single directory, but I'd strongly prefer a single file), or similar, but probably more tricky: saving the parent and all his childs from inside a child patch.
This could maybe be achieved by using something like the shared datapool in Thomas' pool: Have a [preset StateGroup] object, where "StateGroup" collects related states. The user could put a [preset StateGroup] into the abstractions, that should get saved in this group. Every [preset StateGroup] object, even in child patches, would be able to save all other presets in the same group. A default could be to just save every state in every patch.
A lot of this is possible with an abstraction, as my Memento, but it's tedious. Your state external could be extended to support above features, as well, but of course it should be able to read the state of every changeable object including IEM-GUIs, maybe tables, anything else? I have no idea what changes would be needed inside Pd, though.
ciao
On Sun, 30 Nov 2003, Frank Barknecht wrote:
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
I think it is a very useful thing to have indeed, I could not imagine the complexity of my patches without the "state" object. But first we have to give the concept one or another thought.
Yes, we should definitely collect, what might be expected of a preset system, a specification. I didn't use [state] for years, I guess, and just now looked at the help patch again, when the first problem arose. Clicking 1 gave:
state: unable to open /usr/lib/pd/doc/5.reference/state.1
This is one feature I would like to see: Saves should not automatically select a save file, but should require a (full) path to a file provided by the user. Maybe [state] allows that, I didn't look very hard, it's just something that stroke me when it happened.
yes, "state" can only load files that have been saved before, maybe I should improve the documentation, if this is not really clear. I think that states should be saved relative to the patch directory, which is the case with state. If you want to change the filename instantiate with "state mystate".
Guenter
Then I figure that two kinds of preset behaviour would be cool. One is of course persisting things to the disk, the other is a kind of preset in memory. If you look at my just announced memento-0.2.tgz: Here the new "substate" feature is just that, a way to switch states on the fly, without the need to store to or load from disk.
In the end this will of course lead to a tightly related thing: automation. Automation could be seen as switching states (or presets) on a higher level than just some message passing to change a float value. I shortly mailed with Thomas Grill about that and he remarked, that in complex patches changing a lot of values at once can get very costly if all this is done through messages. Moving all that data around through send/receive might be slow. (I didn't do any benchmarks yet...)
Another very important feature IMO is the saving and loading of states in child patches from the parent patch and into a single file (or several files in a single directory, but I'd strongly prefer a single file), or similar, but probably more tricky: saving the parent and all his childs from inside a child patch.
This could maybe be achieved by using something like the shared datapool in Thomas' pool: Have a [preset StateGroup] object, where "StateGroup" collects related states. The user could put a [preset StateGroup] into the abstractions, that should get saved in this group. Every [preset StateGroup] object, even in child patches, would be able to save all other presets in the same group. A default could be to just save every state in every patch.
A lot of this is possible with an abstraction, as my Memento, but it's tedious. Your state external could be extended to support above features, as well, but of course it should be able to read the state of every changeable object including IEM-GUIs, maybe tables, anything else? I have no idea what changes would be needed inside Pd, though.
ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo,
guenter geiger hat gesagt: // guenter geiger wrote:
yes, "state" can only load files that have been saved before, maybe I should improve the documentation, if this is not really clear.
Well, I only read it long ago, so I don't count...
I think that states should be saved relative to the patch directory, which is the case with state.
I disagree. In my opinion, such asumptions should not be made at all. We should let the user provide a save file location, and don't try to outsmart him/her.
If the user didn't provide a conzise filename we shouldn't do anything at all, because essential information is missing.
ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I think that states should be saved relative to the patch directory, which is the case with state.
I disagree.
I changed my mind: saving relative is okay, I think now. But still I don't like, if a preset mechanism just proposes a filename automatically, if nothing was specified.
I'd prefer it, if the attempt to save a setting will ask the user for a filename instead, just as Pd asks at the first "File -> Save". A way to programmatically set the filename should be included, though. Either through arguments or [set filename( messages.
ciao
On Mon, 1 Dec 2003, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I think that states should be saved relative to the patch directory, which is the case with state.
I disagree.
I changed my mind: saving relative is okay, I think now. But still I don't like, if a preset mechanism just proposes a filename automatically, if nothing was specified.
I'd prefer it, if the attempt to save a setting will ask the user for a filename instead, just as Pd asks at the first "File -> Save". A way to programmatically set the filename should be included, though. Either through arguments or [set filename( messages.
I think that the real difference in concept, between what are you describing and the state external is that
1) the state can be stored in memory 2) the state(s) are written into a single file
I see several advantages in this approach: - possible to save several state sets - its faster to load new states (they are in memory already) - the directories don't get polluted by single state files
The idea of having one file per state was to make it easier to handle single states outside of pd, renaming, copying etc. At the end I didnt use this feature too often, because it was easier to do everything from within pd.
Guenter
-- Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
I think that the real difference in concept, between what are you describing and the state external is that
- the state can be stored in memory
- the state(s) are written into a single file
I see several advantages in this approach:
- possible to save several state sets
- its faster to load new states (they are in memory already)
- the directories don't get polluted by single state files
Yes, and even these 3 (especiall #1 and #3) are major advantages, IMO.
The idea of having one file per state was to make it easier to handle single states outside of pd, renaming, copying etc. At the end I didnt use this feature too often, because it was easier to do everything from within pd.
Yes, yes, yes, yes! I totally agree. In my older sseq patches, I used a similar approach to state: Have a lot of states in lots of files, that get sequenced like:
[r whichBarToPlay?] | [float] | [load $1-sate.seq( | [sseq ...]
This has proved to be terribly to handle, for reasons you sure could think of yourself: "Where are these darn sequence-files again?" "What were the names I gave them 6 weeks ago?" and so on
My proposed version actually makes it easier to move state files around and share them, because they are a single file and do not depend on the location in the FS at all.
I think it would be nice to somehow include something like subfolder or state/preset merging features as well.
Example: My drum synth angriff comes with three presets: the same patch algorithm is changed to create snare, hihat, bass drum and clap sounds just by using another preset (realised as tables here). One might want to change just the preset of the angriff abstraction, without affecting the other states. How would such things fit into the mechanics?
ciao
multiple state-sets would be very useful to me as well. (I think I mentioned it in the early discussion) I was really thinking of something like preset that allows you to change the preset with a click of the button. For me the place for state files would be in the parent patch folder.
I'm really exited how fast this stuff is moving, I'm sure soon I'll have all my state-saving dreams come true. (very very important for v_!)
Ben
It's probably a bit early to start plugin in memento into my v_ abtractions...
----- Original Message ----- From: "guenter geiger" geiger@xdv.org To: "Frank Barknecht" fbar@footils.org Cc: "pd-dev" pd-dev@iem.kug.ac.at Sent: Monday, December 01, 2003 12:02 PM Subject: Re: [PD-dev] presets... why not?
On Mon, 1 Dec 2003, Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I think that states should be saved relative to the patch directory, which is the case with state.
I disagree.
I changed my mind: saving relative is okay, I think now. But still I don't like, if a preset mechanism just proposes a filename automatically, if nothing was specified.
I'd prefer it, if the attempt to save a setting will ask the user for a filename instead, just as Pd asks at the first "File -> Save". A way to programmatically set the filename should be included, though. Either through arguments or [set filename( messages.
I think that the real difference in concept, between what are you describing and the state external is that
- the state can be stored in memory
- the state(s) are written into a single file
I see several advantages in this approach:
- possible to save several state sets
- its faster to load new states (they are in memory already)
- the directories don't get polluted by single state files
The idea of having one file per state was to make it easier to handle single states outside of pd, renaming, copying etc. At the end I didnt use this feature too often, because it was easier to do everything from within pd.
Guenter
-- Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
I'm really exited how fast this stuff is moving, I'm sure soon I'll have all my state-saving dreams come true. (very very important for v_!)
Ben
It's probably a bit early to start plugin in memento into my v_ abtractions...
Yes, memento is meant to be something like a design study and at the same time a proof of concept. A final solution has to be much more robust and even easier to use. Especially the "commun" abstraction has to go, and ideally originator wouldn't need to know anything about $0 at all, which is currently just used to make the send/receive local, that better should go down as well in the end.
I could figure, that a marriage of the state and pool externals would be cool (maybe not even in one in- or external but by a defined communication protocol between the two). Pool in this would be the "Originator" of the Memento pattern (like the sound engineer here [1]) which saves a Memento as a file to the disk (== caretaker) whereas [state] would be just that: the State of things, that is read and written to. Something, probably [state] would have to do the actual reload of a state, as well, i.e. setting number boxes and sliders to certain values.
Another still open question is: what belongs to a state: Only the things that change state visibly, like numbers, or should the state of a [float] box be saved, too. I think, this could get hard, though.
[1] http://www.agcs.com/supportv2/techpapers/patterns/papers/tutnotes/sld025.htm
ciao
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
Hallo, rama hat gesagt: // rama wrote:
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 agree, that several ways to store state should be possible, but a built-in Pd object should rather stay with saving to disk. But DB saving is an argument for abstracting out the actual persistance into a number of "caretaker" externals/abstrations. All caretakers would just need to know how to store and restore something, whereas the rest of the preset stuff wouldn't need to know anything about that, but would just deal with some caretaker.
ciao
-
B. Bogart -
Frank Barknecht -
guenter geiger -
Krzysztof Czaja -
rama