I just thought I'd propose an idea I had driving home : ):
As a supplement to the subpatcher functionality, what about having a [pddefine] object that took a name as its argument, and a patch built inside would then be callable within the parent patch patch, acting functionally equivalent to an abstraction (i.e. arguments, etc).
The advantage of this would to simplify distribution of pd-patches that would like to use abstractions, but don't want to have to include 15 files for one program. It would also be great for "1-off" abstractions that aren't usable elsewhere, but are needed multiple times in the same patch.
Anyhow, I can't write it, so I guess it's just an idea for able devs to consider.
Luke
I've been thinking about some other ways to do that (also would like to figure out how to bundle externs, files for 'qlist', etc in a single gesture) but there's something about this particular idea I like...
(OK here are some others:
- Have a "bundle" file type that causes Pd actually to build a
directory for a patch to run in complete with any other files needed
- fix file reading so that the Pd file format can pre-define nonexistent
file pathnames that "binbuf_read" and "sys_load_lib", etc. would check for and pretend were there
- write a general state-saving mechanism of some sort
)
Anyway, there's something elegant about the "pddefine" mechanism - if I could just generalize it to cover at least some of the other situations I'd do it right away :)
thanks Miller
On Thu, Dec 14, 2006 at 10:29:53PM -0700, Luke Iannini (pd) wrote:
I just thought I'd propose an idea I had driving home : ):
As a supplement to the subpatcher functionality, what about having a [pddefine] object that took a name as its argument, and a patch built inside would then be callable within the parent patch patch, acting functionally equivalent to an abstraction (i.e. arguments, etc).
The advantage of this would to simplify distribution of pd-patches that would like to use abstractions, but don't want to have to include 15 files for one program. It would also be great for "1-off" abstractions that aren't usable elsewhere, but are needed multiple times in the same patch.
Anyhow, I can't write it, so I guess it's just an idea for able devs to consider.
Luke
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Did I have too much wax in my ears, or did I just hear Miller say something about integrating a state saving system in Pd!?!?! Is it April 1st?
Please do this! It would make my decade.
~Kyle
On 12/15/06, Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
- write a general state-saving mechanism of some sort
thanks Miller
--
http://theradioproject.com http://perhapsidid.blogspot.com
(((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO
On Dec 15, 2006, at 12:16 PM, Miller Puckette wrote:
I've been thinking about some other ways to do that (also would
like to figure out how to bundle externs, files for 'qlist', etc in a single gesture) but there's something about this particular idea I like...(OK here are some others:
- Have a "bundle" file type that causes Pd actually to build a
directory for a patch to run in complete with any other files needed
This bundle could be easily the same format as the libdir. We'd just
need a way to create them from within the Pd GUI. Right now, in the
folder "mylib", there is "mylib-meta.pd". The presence of this file
marks the folder as a libdir.
In the not-to-distant future, this file will be parsed for
requirements for that library, like whether it needs a python, CLR,
etc. loader; the author, license, and description of the library, and
so on and so forth.
One question is whether this should be in a .jar-like compressed
tarball or not.
.hc
- fix file reading so that the Pd file format can pre-define
nonexistent file pathnames that "binbuf_read" and "sys_load_lib", etc. would check for and pretend were there
- write a general state-saving mechanism of some sort
)
Anyway, there's something elegant about the "pddefine" mechanism -
if I could just generalize it to cover at least some of the other
situations I'd do it right away :)thanks Miller
On Thu, Dec 14, 2006 at 10:29:53PM -0700, Luke Iannini (pd) wrote:
I just thought I'd propose an idea I had driving home : ):
As a supplement to the subpatcher functionality, what about having a [pddefine] object that took a name as its argument, and a patch built inside would then be callable within the parent patch patch, acting functionally equivalent to an abstraction (i.e. arguments, etc).
The advantage of this would to simplify distribution of pd-patches that would like to use abstractions, but don't want to have to
include 15 files for one program. It would also be great for "1-off" abstractions that aren't usable elsewhere, but are needed multiple times in the same patch.Anyhow, I can't write it, so I guess it's just an idea for able devs to consider.
Luke
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I've been thinking about some other ways to do that (also would like to figure out how to bundle externs, files for 'qlist', etc in a single gesture) but there's something about this particular idea I like...
(OK here are some others:
- Have a "bundle" file type that causes Pd actually to build a
directory for a patch to run in complete with any other files needed
That would actually be a wonderful thing to have. Personally I don't care about really embedding abstractions into a patch, they can stay seperate files as far as I'm concerned. Any major application today consists of lots of different files and not just one executable, too.
However with a growing number of abstractions I built and use all the time, it's becoming a bit hard to 1) share the patches with others and 2) make a kind of snapshot of a project complete with all abstractions used, for example to do easy backups.
A "Save as bundle" would solve both problems. A bundle could just be a directory, optionally (t)archived into a single file (but please only optionally: I'd want to store bundles in a versioning system.
- write a general state-saving mechanism of some sort
That's of course the part that's a little bit tricky. A good start IMO would be to include the power of something like [OSCroute] into Pd to easily access state variable hidden deep inside abstraction trees, preferably with wildcards (like: "/*/slider_[abc] 127") and to have a dictionary- or map-like data type to quickly store and restore values by the name of a key instead of having to walk through a list as in textfile.
A further step would be some easy way to read and write the state of objects without having to watch their communication through senders and receivers, but that's the hard part, because it touches philosophical questions like: What actually is a state? ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Dec 15, 2006, at 5:14 PM, Frank Barknecht wrote:
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I've been thinking about some other ways to do that (also would
like to figure out how to bundle externs, files for 'qlist', etc in a single gesture) but there's something about this particular idea I like...(OK here are some others:
- Have a "bundle" file type that causes Pd actually to build a
directory for a patch to run in complete with any other files needed
That would actually be a wonderful thing to have. Personally I don't care about really embedding abstractions into a patch, they can stay seperate files as far as I'm concerned. Any major application today consists of lots of different files and not just one executable, too.
However with a growing number of abstractions I built and use all the time, it's becoming a bit hard to 1) share the patches with others and 2) make a kind of snapshot of a project complete with all abstractions used, for example to do easy backups.
A "Save as bundle" would solve both problems. A bundle could just be a directory, optionally (t)archived into a single file (but please only optionally: I'd want to store bundles in a versioning system.
From what I gather you are looking for, a libdir is almost ready for
that. AFAIK, the only missing piece is a mechanism to open a libdir
like a patch. I think this could be done in the mybundle-meta.pd
file. If Pd loaded that file when it opens a libdir, then you could
add a tiny bit of code into it to load any other patch you might
want. Something like:
[loadbang] | [; pd open mypatch.pd(
- write a general state-saving mechanism of some sort
That's of course the part that's a little bit tricky. A good start IMO would be to include the power of something like [OSCroute] into Pd to easily access state variable hidden deep inside abstraction trees, preferably with wildcards (like: "/*/slider_[abc] 127") and to have a dictionary- or map-like data type to quickly store and restore values by the name of a key instead of having to walk through a list as in textfile.
A further step would be some easy way to read and write the state of objects without having to watch their communication through senders
and receivers, but that's the hard part, because it touches philosophical questions like: What actually is a state? ;)
I am a big fan of the way that you have done it, Frank, using only
existing objects. I think to make the whole thing complete, there
should be a set of GOP GUI objects with your state saving stuff
inside. Then people just use those GOP objects if they want state-
saving.
This gives me an idea of where having the IEMGUI separate would be
handy: if you have a set of GUIs all named the same as the IEMGUIs,
then you could add state-saving to a patch just by changing [import
iemgui] to [import sssadgui]. Then [hslider] would change from
[iemgui/hsl] to [sssadgui/hsl]
.hc
Access to computers should be unlimited and total. - the hacker ethic
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
From what I gather you are looking for, a libdir is almost ready for
that. AFAIK, the only missing piece is a mechanism to open a libdir
like a patch. I think this could be done in the mybundle-meta.pd
file. If Pd loaded that file when it opens a libdir, then you could
add a tiny bit of code into it to load any other patch you might
want. Something like:[loadbang] | [; pd open mypatch.pd(
Actually I think opening isn't such a problem, saving as bundle however is. If I have lots of abstractions in different (lib)dirs, then currently I'd need to search then by hand.
I am a big fan of the way that you have done it, Frank, using only
existing objects. I think to make the whole thing complete, there
should be a set of GOP GUI objects with your state saving stuff
inside. Then people just use those GOP objects if they want state- saving.
Chris McCormick's collection has some of these. (I also have but they aren't published yet because I'm lazy...)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Similarly with encapsulation, I am still thinking that being able to encapsulate a selected group of objects into a pd object while preserving the connections would be great. From there, it's not too difficult to create an abstraction either.
I really like that justification of 'decoupling' the iemGUI, Hans. That's EXACTLY why it's a good idea.
~Kyle
On 12/15/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
From what I gather you are looking for, a libdir is almost ready for that. AFAIK, the only missing piece is a mechanism to open a libdir like a patch. I think this could be done in the mybundle-meta.pd file. If Pd loaded that file when it opens a libdir, then you could add a tiny bit of code into it to load any other patch you might want. Something like:
[loadbang] | [; pd open mypatch.pd(
Actually I think opening isn't such a problem, saving as bundle however is. If I have lots of abstractions in different (lib)dirs, then currently I'd need to search then by hand.
I am a big fan of the way that you have done it, Frank, using only existing objects. I think to make the whole thing complete, there should be a set of GOP GUI objects with your state saving stuff inside. Then people just use those GOP objects if they want state- saving.
Chris McCormick's collection has some of these. (I also have but they aren't published yet because I'm lazy...)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 15 Dec 2006, Kyle Klipowicz wrote:
Similarly with encapsulation, I am still thinking that being able to encapsulate a selected group of objects into a pd object while preserving the connections would be great.
This is called "subpatcherising". It would have been already finished in DesireData by now, and Chun has started working on it, but this and several other features are waiting for another feature that I'm supposed to implement (client-server sync messages), that several pending features of DesireData are also waiting for. I think that subpatcherising will be implemented before xmas.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Dec 15, 2006, at 5:44 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
From what I gather you are looking for, a libdir is almost ready for that. AFAIK, the only missing piece is a mechanism to open a libdir like a patch. I think this could be done in the mybundle-meta.pd file. If Pd loaded that file when it opens a libdir, then you could add a tiny bit of code into it to load any other patch you might want. Something like:
[loadbang] | [; pd open mypatch.pd(
Actually I think opening isn't such a problem, saving as bundle however is. If I have lots of abstractions in different (lib)dirs, then currently I'd need to search then by hand.
I get it, so it would be like a "Save As Bundle.." option in the File
menu which would then save everything needed to make it work into one
bundle. One tricky thing would be determining which should be
included. In the context of Pd-extended, should this save
abstractions that come with Pd-extended into the bundle? Or just
ones external to Pd-extended?
That could get into issues with versioning. I suppose this could be
viewed as the "compiled app" for Pd. So it would include all objects
in the Bundle, including binary files (.dll, .pd_*). Then it new
versions of any of the dependencies wouldn't break patch in the
bundle, since the bundle would have all the static versions. It
would basically be like static linking for a Pd patch.
I am a big fan of the way that you have done it, Frank, using only existing objects. I think to make the whole thing complete, there should be a set of GOP GUI objects with your state saving stuff inside. Then people just use those GOP objects if they want state- saving.
Chris McCormick's collection has some of these. (I also have but they aren't published yet because I'm lazy...)
That would be a very useful library to have, poke poke. :)
.hc
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Hi,
Just to add to the noise, I'd like to say that I wholeheartedly support this feature request.
On Fri, Dec 15, 2006 at 11:44:54PM +0100, Frank Barknecht wrote:
I am a big fan of the way that you have done it, Frank, using only
existing objects. I think to make the whole thing complete, there
should be a set of GOP GUI objects with your state saving stuff
inside. Then people just use those GOP objects if they want state- saving.Chris McCormick's collection has some of these. (I also have but they aren't published yet because I'm lazy...)
You can get my GOPified modifications of Frank's sssad abstractions here:
http://mccormick.cx/viewcvs/s-abstractions/sssad/ http://mccormick.cx/viewcvs/s-abstractions/sssad.tar.gz?view=tar
I use these a lot in my own patches at the moment in order to do in-patch state saving of all sliders without any externals. It works very nicely with no fuss. Here's a four step program to follow if you want in-patch state saving with no extra files, assuming that you have saved the sssad/ directory somewhere in your Pd path:
- All of your abstractions' widgets should have a receive called
$1/whatever and a send called $0/whatever.
- All of your abstractions should include:
[sssad/auto $0/whatever $1/whatever] for each widget.
- When you create a new top level performance/composition patch, you
should add a box called [pd datastore].
- Instansiate [sssad/datastore] once in your top level
performance/composition patch, and use the save and load buttons to save/load the state of all widgets in all abstractions into the [pd datastore] subpatch of your main patch.
As far as I'm concerned this means that Pd has state saving already. If you add a [loadbang] to the load bang of [sssad/datastore] and if there was a [savebang] which banged whenever a patch was saved, then it would be possible to make this process completely transparent. One of these days I'll get round to writing [savebang].
Have fun!
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
On 17/12/2006, at 5.13, Chris McCormick wrote:
I use these a lot in my own patches at the moment in order to do in- patch state saving of all sliders without any externals. It works very
nicely with no fuss.
That and the consensus expressed in other emails in this tread that
the definition of state is subjective might be good reasons for not
implementing state saving? Ie.: We want to save different things, and
we can, isn't that enough?
Another thing related to this; i don't understand why it is so
important to bundle "things" into one file? The freedom that resides
in modularity i (at least) hold quite dear.
On Sun, Dec 17, 2006 at 11:35:58AM +0100, Steffen wrote:
On 17/12/2006, at 5.13, Chris McCormick wrote:
I use these a lot in my own patches at the moment in order to do in- patch state saving of all sliders without any externals. It works very
nicely with no fuss.That and the consensus expressed in other emails in this tread that
the definition of state is subjective might be good reasons for not
implementing state saving? Ie.: We want to save different things, and
we can, isn't that enough?
Well I agree with you for the most part. I think that the existing solutions are enough for me personally, but they're not enough for everyone. What about saving the 'state' of a big list of midi controller changes? And all of the use-cases that Frank presents, too. These make things more complicated.
We've already seen that amazing state saving things can be done with existing internals, so my preference would be for a few small additions to be made to the Pd core vocabulary that allow users to create their own state saving mechanisms using Pd itself. I guess the question then is what are those additions that give the greatest flexibility to people who want to create state saving mechanisms? I think this was addressed best by Frank earlier:
http://lists.puredata.info/pipermail/pd-list/2006-12/045251.html
Whoops, recursive mailing list loop. :)
Another thing related to this; i don't understand why it is so
important to bundle "things" into one file? The freedom that resides
in modularity i (at least) hold quite dear.
I think that it's about having the freedom of choice about which way you'd like to work. Some people want to create custom patches which use lots of their own library abstractions many times, and this feature isn't useful for them. Other people want to distribute their patches to others, and this feature becomes very useful. If the feature is there you can choose.
Chris.
chris@mccormick.cx http://mccormick.cx
On Sun, 2006-12-17 at 11:35 +0100, Steffen wrote:
On 17/12/2006, at 5.13, Chris McCormick wrote:
I use these a lot in my own patches at the moment in order to do in- patch state saving of all sliders without any externals. It works very
nicely with no fuss.That and the consensus expressed in other emails in this tread that
the definition of state is subjective might be good reasons for not
implementing state saving? Ie.: We want to save different things, and
we can, isn't that enough?Another thing related to this; i don't understand why it is so
important to bundle "things" into one file? The freedom that resides
in modularity i (at least) hold quite dear.
to have the opportunity of bundling things doesn't mean the must to bundle things, so nobody would loose any freedom. but it would make sharing patches a lot easier, *especially* if you are using extensively the freedom that modularity gives you (ie. if you use a lot of selfmade abstractions).
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Dec 17, 2006, at 7:06 AM, Roman Haefeli wrote:
On Sun, 2006-12-17 at 11:35 +0100, Steffen wrote:
On 17/12/2006, at 5.13, Chris McCormick wrote:
I use these a lot in my own patches at the moment in order to do in- patch state saving of all sliders without any externals. It works very nicely with no fuss.
That and the consensus expressed in other emails in this tread that the definition of state is subjective might be good reasons for not implementing state saving? Ie.: We want to save different things, and we can, isn't that enough?
Another thing related to this; i don't understand why it is so important to bundle "things" into one file? The freedom that resides in modularity i (at least) hold quite dear.
to have the opportunity of bundling things doesn't mean the must to bundle things, so nobody would loose any freedom. but it would make sharing patches a lot easier, *especially* if you are using
extensively the freedom that modularity gives you (ie. if you use a lot of
selfmade abstractions).roman
There is something lost with too many features, and that is the
readability of the code. If there are too many features, then you
will need to know every single feature to understand people's code.
An example here is Java Jars. The same format is used to bundle a
class, a bunch of classes, a whole program, or a library. You only
need to learn about jars, and you can do all of those.
.hc
¡El pueblo unido jamás será vencido!
However with a growing number of abstractions I built and use all the time, it's becoming a bit hard to 1) share the patches with others and 2) make a kind of snapshot of a project complete with all abstractions used, for example to do easy backups.
I should think this wouldn't be too difficult to do just with a little bash or Python script, even... I guess it would be a convenience for Pd to do it, but I could see it not being too difficult to develop an external program to create "bundles" like this.
As for the actual file format, what about just linking to something like libtar and using already-available routines? For instance, if pd is told to run a file test.tar.gz, it would automatically load the file "test.pd" inside that tar file, and then any abstractions would also assume to be available within that tarball. I guess this wouldn't work so well for externals, however, since the OS couldn't load them from a tarball.
Steve
There is a max external for the Wii remote here http://www.iamas.ac.jp/~aka/max/#aka_wiiremote
How big a job would it be to port it to PD - anyone up for it ? my coding skills are minimal.
Merry Christmas
NIck
Hallo, nick weldin hat gesagt: // nick weldin wrote:
There is a max external for the Wii remote here http://www.iamas.ac.jp/~aka/max/#aka_wiiremote
How big a job would it be to port it to PD - anyone up for it ? my coding skills are minimal.
I guess, the best would be to just wait until the HID drivers stabilize a bit and then use [hid] to talk to the Wii, maybe adding some specialized abstractions later. Here are some interesting URLs:
http://www.wiili.org/index.php/Wiimote http://www.wiili.org/index.php/Wiimote_driver
I'll get a Wii next year, so I'd be trying that route for sure then.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Dec 16, 2006, at 7:18 AM, Frank Barknecht wrote:
Hallo, nick weldin hat gesagt: // nick weldin wrote:
There is a max external for the Wii remote here http://www.iamas.ac.jp/~aka/max/#aka_wiiremote
How big a job would it be to port it to PD - anyone up for it ? my coding skills are minimal.
I guess, the best would be to just wait until the HID drivers stabilize a bit and then use [hid] to talk to the Wii, maybe adding some specialized abstractions later. Here are some interesting URLs:
http://www.wiili.org/index.php/Wiimote http://www.wiili.org/index.php/Wiimote_driver
I'll get a Wii next year, so I'd be trying that route for sure then.
Right now [hid] and the next gen [hidio] use the HID APIs on Mac OS X
and Windows, and the Linux input.h API. So those APIs would have to
support that device in order to use the WiiRemote. From what I have
seen, it seems to be a different API. Now that I see it, I'll need
to think about how to best handle it. Plus the different OS's
implementations could be very, very different.
The port seems to be pretty straightforward, most Max objects are
pretty easy to port to Pd, and vice versa. It builds but with a ton
of compiler warnings. It seems as tho the original programmer
ignored them with the Max object. Give it a try and let me know if
it works for you:
Also, write up a help file and an example patch and I'll include it.
This will be part of the nightly builds on Mac OS X now in the "io"
libdir. FYI: I dropped the "aka." prefix on the Pd version.
.hc
All information should be free. - the hacker ethic
On Fri, 15 Dec 2006, Frank Barknecht wrote:
A further step would be some easy way to read and write the state of objects without having to watch their communication through senders and receivers, but that's the hard part, because it touches philosophical questions like: What actually is a state? ;)
There's nothing funny or joke-like in that. I ask you: what is a state?
I'd say, a state is whatever you may want to save. Is that a good definition?
However, for a general state-saving mechanism, you need more than just a concept of state, you need specifically take care of the part of the state that doesn't get saved already as part of the constructor. The constructor may be defined as the contents of the objectbox, regardless of whether it's visible or not; the concept can be extended to mean the whole line as it appears in a .pd file, and furthermore to include any #A lines and other possible extras.
If you save a IEMGUI object, such as an [hsl], you are saving a lot of things that may be considered as state already. All those things get saved as if they were part of an objectbox. In the case of floatboxes (Ctrl+3) and symbolboxes (Ctrl+4) it's similar except that it's not technically an objectbox (pd has strange exceptions like this; you can see that by reading .pd files).
What do you think?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Fri, 15 Dec 2006, Frank Barknecht wrote:
A further step would be some easy way to read and write the state of objects without having to watch their communication through senders and receivers, but that's the hard part, because it touches philosophical questions like: What actually is a state? ;)
There's nothing funny or joke-like in that. I ask you: what is a state?
What I think is funny about this question is that often it seems people would think the answer is obvious, while I agree with you that it's not obvious at all!
I'd say, a state is whatever you may want to save. Is that a good definition?
This would be my basic definition as well. Even this has some direct consequences: What I want to save is different from what you want to save. What I want to save also somehow defines what I don't want to save. So the next questions are: How to tell Pd what should be saved and what not? Or: Can Pd make educated guesses about what should and shouldn't be saved? Should Pd guess at all?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Exactly. If I could answer those questions I'd code it up right now...
cheers Miller
On Sun, Dec 17, 2006 at 01:21:29AM +0100, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Fri, 15 Dec 2006, Frank Barknecht wrote:
A further step would be some easy way to read and write the state of objects without having to watch their communication through senders and receivers, but that's the hard part, because it touches philosophical questions like: What actually is a state? ;)
There's nothing funny or joke-like in that. I ask you: what is a state?
What I think is funny about this question is that often it seems people would think the answer is obvious, while I agree with you that it's not obvious at all!
I'd say, a state is whatever you may want to save. Is that a good definition?
This would be my basic definition as well. Even this has some direct consequences: What I want to save is different from what you want to save. What I want to save also somehow defines what I don't want to save. So the next questions are: How to tell Pd what should be saved and what not? Or: Can Pd make educated guesses about what should and shouldn't be saved? Should Pd guess at all?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
(IMHO) State saving would nominally be all data stored in
- Toggle
- Number
- Number2
- Symbol
- Internally in [f ]/[i ] objects (and permutations involving [t ])
- Messages exactly as they are at save time
- V/Hslider
- V/Hradio
- Tables
- Arrays
Optionally |_> Add a mechanism to the API so that externals can support registering their parameters as belonging to the state. The above only applies to canonical Pd.
Of course if I am incorrect or presumptuous, then I'm certain others will correct and discuss. Breaking the ice is fine too.
./d5
On Dec 16, 2006, at 6:29 PM, Miller Puckette wrote:
Exactly. If I could answer those questions I'd code it up right now...
cheers Miller
On Sun, Dec 17, 2006 at 01:21:29AM +0100, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Fri, 15 Dec 2006, Frank Barknecht wrote:
A further step would be some easy way to read and write the state of objects without having to watch their communication through senders and receivers, but that's the hard part, because it touches philosophical questions like: What actually is a state? ;)
There's nothing funny or joke-like in that. I ask you: what is a state?
What I think is funny about this question is that often it seems people would think the answer is obvious, while I agree with you that it's not obvious at all!
I'd say, a state is whatever you may want to save. Is that a good definition?
This would be my basic definition as well. Even this has some direct consequences: What I want to save is different from what you want to save. What I want to save also somehow defines what I don't want to save. So the next questions are: How to tell Pd what should be saved and what not? Or: Can Pd make educated guesses about what should and shouldn't be saved? Should Pd guess at all?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, day 5 hat gesagt: // day 5 wrote:
(IMHO)
State savingwould nominally be all data stored in
...
State saving in [sssad] is only saving the data stored in the main [list] object in every [sssad] object, using the $1 of every [sssad] object as a key to save and retrieve this specific [list]'s content.
Creating and connecting the [sssad] objects is in the hand of the patch author, who decides what should be saved and what not.
Basically Memento does the same and a similar approach is used in netpd.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
I don't want to sound pretentious. But i think that there's an easy answer: save *everything* as a default behavior. I should load a patch and have the very same situation I had when I saved it.
It's true that we all use Pd in different ways and to accomplish various things. But it would be the most intuitive implementation to consider a patch in this way. I already use Pd like this, toggling the 'init' property for every slider and such. If I need to save the state of an abstraction I make a GOP that expose all the parameters I need so they're saved in the state they were when in the patch where I'm using them. If I want to reset something when the patch is loaded I use the loadbang.
An abstraction is a patch and so it should have its entire state stored when I save it. When I use a patch as an abstraction from another patch, saving the latter should save the state of the abstraction as it is.
To cut a long story short, I'm hearing the output of a patch now and I like what I hear. I hit ctrl-s, close Pd. When I reopen the patch I should hear the very same output. For backwards compatibility we can make a toggle in the settings for this new behavior and maybe separate the implementation from the state in the patch file format.
Maybe there are some drawbacks in this approach that I haven't considered. Let's discuss it.
c.
Miller Puckette wrote:
Exactly. If I could answer those questions I'd code it up right now...
cheers Miller
On Sun, Dec 17, 2006 at 01:21:29AM +0100, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Fri, 15 Dec 2006, Frank Barknecht wrote:
A further step would be some easy way to read and write the state of objects without having to watch their communication through senders and receivers, but that's the hard part, because it touches philosophical questions like: What actually is a state? ;)
There's nothing funny or joke-like in that. I ask you: what is a state?
What I think is funny about this question is that often it seems people would think the answer is obvious, while I agree with you that it's not obvious at all!
I'd say, a state is whatever you may want to save. Is that a good definition?
This would be my basic definition as well. Even this has some direct consequences: What I want to save is different from what you want to save. What I want to save also somehow defines what I don't want to save. So the next questions are: How to tell Pd what should be saved and what not? Or: Can Pd make educated guesses about what should and shouldn't be saved? Should Pd guess at all?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
I don't want to sound pretentious. But i think that there's an easy answer: save *everything* as a default behavior. I should load a patch and have the very same situation I had when I saved it.
It sounds simple and simple always is good, but not this time. To take one example why not: Suppose you use an abstraction in two different patches. Saving the state of this abstraction in one patch will overwrite a saved state of the same abstraction as used in another patch. Or even in the same patch, if you use the same abstracion twice in the same patch: Which state of the two abstraction instances is the right one? And how dare you overwrite the state, the original abstraction author has saved in the first place? ;)
There are more reasons why saving only snapshots isn't The Right Thing for everything. Some values may change during a patch's runtime but you may want to save a default value from the past instead. With some kinds of patches even the patch's contents may change e.g if you use nqpoly4 etc.
Snapshot-saving can be useful, of course. Max' "preset" object is in use for years and it does exactly that. But even Max got a new state saving mechanism in recent versions which is actually remarkably similar to the approach of Memento, netpd and sssad.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
I don't want to sound pretentious. But i think that there's an easy answer: save *everything* as a default behavior. I should load a patch and have the very same situation I had when I saved it.
It sounds simple and simple always is good, but not this time. To take one example why not: Suppose you use an abstraction in two different patches. Saving the state of this abstraction in one patch will overwrite a saved state of the same abstraction as used in another patch.
No. Because the state is saved in the patch which use the abstraction. The abstraction itself is another patch and when you open it or create an object with it you get the state in which the abstraction was saved as a standalone patch. There's no ambiguity.
Or even in the same patch, if you use the same abstracion twice in the same patch: Which state of the two abstraction instances is the right one?
Same as above. Think about the behavior of a Graph On Parent.
And how dare you overwrite the state, the original abstraction author has saved in the first place? ;)
This approach would do no harm to your abstractions :-P When I load them in my patch I have the default state that you (the author of the abstraction) saved. If I tweak some parameters I'm sure that they'll be saved with my own patch.
There are more reasons why saving only snapshots isn't The Right Thing for everything. Some values may change during a patch's runtime but you may want to save a default value from the past instead. With some kinds of patches even the patch's contents may change e.g if you use nqpoly4 etc.
I haven't studied nqpoly4 inner workings but it allocates the abstractions dinamically (even if it does it just once, when you create the object). You need to control the abstractions from the ouside anyways.
Snapshot-saving can be useful, of course. Max' "preset" object is in use for years and it does exactly that. But even Max got a new state saving mechanism in recent versions which is actually remarkably similar to the approach of Memento, netpd and sssad.
Ciao
I see. But, especially for beginners, saving the patch as a snapshot would be great. You would be able to handle the exceptions with a loadbang. This is the most intuitive behaviour, IMO.
Anyway, now that I'm thinking about it, Pd already does most of this. Sliders and such already act in this way (but having the 'init' property on by default would be an improvment, so if I forget to turn it on there's no risk I loose that setting). There was a problem I've encountered once with a GOP inside another but I don't remember exactly what it was.
c.
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
Anyway, now that I'm thinking about it, Pd already does most of this. Sliders and such already act in this way (but having the 'init' property on by default would be an improvment, so if I forget to turn it on there's no risk I loose that setting).
I never use the init-feature of IEM-GUI objects, so I wouldn't like it to be on as default.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
No. Because the state is saved in the patch which use the abstraction.
But which state should be saved if you edit an abstraction itself?
Ciao
You mean if you open it from inside a patch which use the abstraction? Well... uhm... :-[
I'm tempted to answer that if you open an abstraction, and you modify it (even adding object and repatching other objects) you need to save the abstraction for the main patch to acknowledge it as it has been changed. You're saving the state of the abstraction itself. But for me an abstraction is like a function in a library. I don't need to edit it in everyday use. To me it should be like a built-in object. If I need to abstract a part of a patch on-the-fly there's the subpatch thing.
Anyway, I'm not proposing to change how Pd behaves. At least for me, there's nothing more we need in this area. I don't even feel the need to have presets since for me the patch itself is the preset. Presets are useful if you want to distribute something like a soft synth or any other instrument or effect that mimics some hardware counterpart. And you know better than me that we already have the tools to do this.
So what was Miller thinking about when he mentioned this general state-saving mechanism? And how come you don't use the 'init' functionalty of gui objects? For me it is so useful.
c.
Hallo, Cesare Marilungo hat gesagt: // Cesare Marilungo wrote:
Frank Barknecht wrote: You mean if you open it from inside a patch which use the abstraction? Well... uhm... :-[
I'm tempted to answer that if you open an abstraction, and you modify it (even adding object and repatching other objects) you need to save the abstraction for the main patch to acknowledge it as it has been changed. You're saving the state of the abstraction itself. But for me an abstraction is like a function in a library. I don't need to edit it in everyday use. To me it should be like a built-in object. If I need to abstract a part of a patch on-the-fly there's the subpatch thing.
Well, sometimes I find a bug in an abstraction while I'm using it, and then I fix the abstraction.
Maybe another example to better explain what I mean: Suppose you have a synth-abstraction, which has some settings to change its general sound. But then it also can play notes, which will change during the course of a piece of music. Obviously the settings variables would be candidates for state saving, but the notes the synth is playing at the moment it was saved don't really belong to the state. It's like a hardware synth: The knobs you turn keep their positions even when the synth is switched off, the keys however don't stay pressed down.
In Pd both "note messages" and "controller change" messages are just the same kind of things: messages with floating point numbers for example. It's the patch's author who decides the actual meaning of the numbers and thus the need to save them or not save them.
And how come you don't use the 'init' functionalty of gui objects? For me it is so useful.
Probably it's a patching style thing, but generally, for example a slider in my patches is just one "view" of something happening somewhere else, something at the end of a receive-object for example. My way to "init" such happenings is independent from the fact that there also is a slider which can change and display a certain "happening". Also I prefer explicit actions so I'd rather use a loadbang than a slider's invisible init function if I want to initialize for example a panning slider going from 0 to 1 to a default of 0.5.
Because I use sssad and Memento, defauls values often are read from a textfile into a [sssad] object or into a Memento-variable anyways.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sun, 17 Dec 2006, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
I'd say, a state is whatever you may want to save. Is that a good definition?
This would be my basic definition as well. Even this has some direct consequences: What I want to save is different from what you want to save.
Maybe we could came up with some kind of classification of state and state-like members of objects... something like:
- state that doesn't have any impact on anything except efficiency of the
program. this means caches/memoizers, prefetch buffers, precalculations, etc.
- state that doesn't have any impact on anything if you run the program
without a GUI.
- other state.
A. state that gets already saved automatically in .pd files B. state that doesn't.
So that makes 6 categories: 1A 1B 2A 2B 3A 3B. The category of something can depend on which level you look it at. Things that happen inside an abstraction or other class, can mean something at one level and then disappear (be invisible) from outside.
So the next questions are: How to tell Pd what should be saved and what not? Or: Can Pd make educated guesses about what should and shouldn't be saved? Should Pd guess at all?
Pd can't guess whether any state is category 1: that's a meaning created by the contract of the class. A "contract" is a set of guarantees about input, and a set of guarantees about output, for which the deal is that as long as input are correct, outputs ought to be correct. There's no way to encode such meanings in pd as it is now (except as comments).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Me too :) I really like this idea, finally I can shut up about converting between subpatches and abstractions.
On Fri, 15 Dec 2006 09:16:07 -0800 Miller Puckette mpuckett@imusic1.ucsd.edu wrote:
I've been thinking about some other ways to do that (also would like to figure out how to bundle externs, files for 'qlist', etc in a single gesture) but there's something about this particular idea I like...
(OK here are some others:
- Have a "bundle" file type that causes Pd actually to build a
directory for a patch to run in complete with any other files needed
A real directory on the filesystem, or some kind of "virtual" temporary directory. Otherwise it needs to clean up after itself.
-
Cesare Marilungo -
Chris McCormick -
day 5 -
Frank Barknecht -
Hans-Christoph Steiner -
Kyle Klipowicz -
Luke Iannini (pd) -
Mathieu Bouchard -
Miller Puckette -
nick weldin -
padawan12 -
Roman Haefeli -
Steffen -
Stephen Sinclair