Hello,
Just for kicks I implemented a sort of primitive associative array [1] (also called a 'map' or 'hash' in some languages, depending on the implementation) in pure Pd:
http://mccormick.cx/viewcvs/*checkout*/s-abstractions/s-map.pd?root=svn http://mccormick.cx/viewcvs/*checkout*/s-abstractions/s-map-help.pd?root=svn
It maps symbols/floats to lists. So you can enter a bunch of lists into it and the first element of each list is the key and the rest of the list is the value. You can recall values (lists) by their key.
Don't look at the internals or your eyeballs might explode.
Hmmm, I wonder if this could be used with SSSAD to make some kind of pure Pd pool/memento replacement? Maybe I'm getting ahead of myself.
Best,
Chris.
[1] http://www.wikipedia.org/wiki/Associative_array
Hi Chris,
This sounds like a great thing for vanilla Pd. I've had need of something just like this more than once.
Having worked a bit with [pool] recently, especially as it is used in Memento, I'd venture that you'd have to go quite a bit further to match its functionality, though. It's like a miniature in-memory file system, with directories, clipboard editing, and more. It would be laudable to do a "pure" Memento, but I think much of the hierarchic potential of [pool] for state-saving has barely been scratched, and in that direction lie some very interesting capabilities.
Phil Stone www.pkstonemusic.com
Chris McCormick wrote:
Hello,
Just for kicks I implemented a sort of primitive associative array [1] (also called a 'map' or 'hash' in some languages, depending on the implementation) in pure Pd:
http://mccormick.cx/viewcvs/*checkout*/s-abstractions/s-map.pd?root=svn http://mccormick.cx/viewcvs/*checkout*/s-abstractions/s-map-help.pd?root=svn
It maps symbols/floats to lists. So you can enter a bunch of lists into it and the first element of each list is the key and the rest of the list is the value. You can recall values (lists) by their key.
Don't look at the internals or your eyeballs might explode.
Hmmm, I wonder if this could be used with SSSAD to make some kind of pure Pd pool/memento replacement? Maybe I'm getting ahead of myself.
Best,
Chris.
[1] http://www.wikipedia.org/wiki/Associative_array
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Phil,
On Tue, Mar 25, 2008 at 05:11:35PM -0700, Phil Stone wrote:
This sounds like a great thing for vanilla Pd. I've had need of something just like this more than once.
Great! I hope it comes in handy.
Having worked a bit with [pool] recently, especially as it is used in Memento, I'd venture that you'd have to go quite a bit further to match its functionality, though. It's like a miniature in-memory file system, with directories, clipboard editing, and more. It would be laudable to do a "pure" Memento, but I think much of the hierarchic potential of [pool] for state-saving has barely been scratched, and in that direction
Yeah for sure, that was way too optimistic of me. I think trying to re-implement all the functionality of [pool] in Pd would be a huge stretch of Pd and definately not what Pd is best at. [pool] is a great external already - no point in re-inventing the wheel.
However I guess what I'm thinking is that it may be possible to extend the functionality of the SSSAD system a bit with this associative list thing to the point where some of the functionality of memento can be brought into SSAD. I guess only Frank can really tell us if this will be any use!
Best,
Chris.
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
On Tue, Mar 25, 2008 at 05:11:35PM -0700, Phil Stone wrote:
This sounds like a great thing for vanilla Pd. I've had need of something just like this more than once.
Great! I hope it comes in handy.
Having worked a bit with [pool] recently, especially as it is used in Memento, I'd venture that you'd have to go quite a bit further to match its functionality, though. It's like a miniature in-memory file system, with directories, clipboard editing, and more. It would be laudable to do a "pure" Memento, but I think much of the hierarchic potential of [pool] for state-saving has barely been scratched, and in that direction
Yeah for sure, that was way too optimistic of me. I think trying to re-implement all the functionality of [pool] in Pd would be a huge stretch of Pd and definately not what Pd is best at. [pool] is a great external already - no point in re-inventing the wheel.
However I guess what I'm thinking is that it may be possible to extend the functionality of the SSSAD system a bit with this associative list thing to the point where some of the functionality of memento can be brought into SSAD. I guess only Frank can really tell us if this will be any use!
With SSSAD I try to be "backend-agnostic": SSSAD is just the protocol to get and set the state of sssad-watched parts of a Pd patch. How to save it in the end is up to the user and will probably stay that way. Your associative container could function as a backend for SSSAD, as a more comfortable version of [textfile] or message boxes.
Some background on my motivation: I don't like the strong coupling of Memento with [pool]. I even think it was a mistake on my part. While [pool] is very powerful, it also pushes you in a certain direction. For example some things, like preset morphing/interpolation, are hard to do with [pool], but they would be easy if the backend was just some custom container written in Lua.
Ciao
Frank Barknecht _ ______footils.org__
On Wed, 2008-03-26 at 10:12 +0100, Frank Barknecht wrote:
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
On Tue, Mar 25, 2008 at 05:11:35PM -0700, Phil Stone wrote:
This sounds like a great thing for vanilla Pd. I've had need of something just like this more than once.
Great! I hope it comes in handy.
Having worked a bit with [pool] recently, especially as it is used in Memento, I'd venture that you'd have to go quite a bit further to match its functionality, though. It's like a miniature in-memory file system, with directories, clipboard editing, and more. It would be laudable to do a "pure" Memento, but I think much of the hierarchic potential of [pool] for state-saving has barely been scratched, and in that direction
Yeah for sure, that was way too optimistic of me. I think trying to re-implement all the functionality of [pool] in Pd would be a huge stretch of Pd and definately not what Pd is best at. [pool] is a great external already - no point in re-inventing the wheel.
However I guess what I'm thinking is that it may be possible to extend the functionality of the SSSAD system a bit with this associative list thing to the point where some of the functionality of memento can be brought into SSAD. I guess only Frank can really tell us if this will be any use!
With SSSAD I try to be "backend-agnostic": SSSAD is just the protocol to get and set the state of sssad-watched parts of a Pd patch. How to save it in the end is up to the user and will probably stay that way. Your associative container could function as a backend for SSSAD, as a more comfortable version of [textfile] or message boxes.
yo, sorry to drop in. let me just add a little note about the state saving of netpd: it turned out, that it was a mistake to cover both tasks, collecting/setting states and reading/writing data from/to files, in the same system. some people got frustrated, because this system didn't allow them to save their presets in the way/format they wanted. we decided to redo all the state saving stuff and just skip file IO handling part, so that people can choose themselves, what they are going to do with this data. for flexibility's sake, i think the route that SSSAD is following totally makes sense, at least in my opinion.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
yo, sorry to drop in. let me just add a little note about the state saving of netpd: it turned out, that it was a mistake to cover both tasks, collecting/setting states and reading/writing data from/to files, in the same system. some people got frustrated, because this system didn't allow them to save their presets in the way/format they wanted. we decided to redo all the state saving stuff and just skip file IO handling part, so that people can choose themselves, what they are going to do with this data. for flexibility's sake, i think the route that SSSAD is following totally makes sense, at least in my opinion.
Interesting. I shall have another look at netpd's state handling again, maybe we can unify our approaches.
Ciao
Frank Barknecht
On Wed, 2008-03-26 at 16:40 +0100, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
yo, sorry to drop in. let me just add a little note about the state saving of netpd: it turned out, that it was a mistake to cover both tasks, collecting/setting states and reading/writing data from/to files, in the same system. some people got frustrated, because this system didn't allow them to save their presets in the way/format they wanted. we decided to redo all the state saving stuff and just skip file IO handling part, so that people can choose themselves, what they are going to do with this data. for flexibility's sake, i think the route that SSSAD is following totally makes sense, at least in my opinion.
Interesting. I shall have another look at netpd's state handling again, maybe we can unify our approaches.
those are actually only plans and most likely not going to be implemented until i will have finished school (next summer), except if someone else wants to do the work, of course. please don't look at it right now ;-). unifying approaches is definitely a good idea. i will certainly have a closer look at SSSAD, before i start. i think, an important advantage of unifying approaches is that backends could be used for both systems.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
yo, sorry to drop in. let me just add a little note about the state saving of netpd: it turned out, that it was a mistake to cover both tasks, collecting/setting states and reading/writing data from/to files, in the same system. some people got frustrated, because this system didn't allow them to save their presets in the way/format they wanted. we decided to redo all the state saving stuff and just skip file IO handling part, so that people can choose themselves, what they are going to do with this data. for flexibility's sake, i think the route that SSSAD is following totally makes sense, at least in my opinion.
hi
i am sorry for the inconvenience with the netpd's state saving manager. i wrote 2 systems that should have made life easier when dealing with presets in netpd.
the first was an abstraction that creates names for the netpd-x to load and save presets. a feature is that it can save all instruments, then it makes 1 preset for each instrument.
later i wanted to optimize the system in order to store all data in 1 single preset. also i didn't like that each abstraction carried it's own gui, that made the abstraction very big (40kb)
while i implemented all my desired features into p-admin it happend that the new presets were not compatible with the old one's. instead of <key><value> it was now <instrument><key><value>
it is still possible to use both ways by replacing an abstraction and adjusting the version tag. but that's really not userfriendly. after some talk we decided to downgrade back to the first approach.
the plan at the moment is that one day we use the OSC format. so we could work in a very flexible way with the data. i wonder if people have good experience with OSC or are there any problem one should be aware of? compatibility, bugs, etc?
so actually i just wanted to say i'm sorry if somebody got frustrated because of the preset-manager in netpd :)
here some thinking:
http://www.netpd.org/FutureOfStateSaving
http://www.netpd.org/NextSteps
eni
-
Chris McCormick -
Enrique Erne -
Frank Barknecht -
Phil Stone -
Roman Haefeli