cool!
Thomas Grill wrote:
Hi all, finally, here is a new release of the pool object, with a number of bug fixes and some new features:
- makes use of flext attributes
- added "geti" message for retrieval of a value at an index
- use of hashing for keys and directories to speed up access
- save/load operations in XML format
- relative file names will be based on the folder of the current patcher
(not for Max/MSP at the moment)
a question about this... if i have an abstraction fileio.pd that uses pool, then i have a song1.pd which is a song that uses a [fileio] object in it, and they are both in different directories (every song of mine is kept in its own folder to keepthings neat) will the pool save file end up in the fileio.pd directory, or the song1.pd directory?
thanks!
- added printall, printrec, printroot messages for console printout
- added mkchdir, mkchsub to create and change to directories at once
- fixed bug with stored numbers starting with - or +
- maybe more things that i already forgot.....
download from: http://grrrr.org/ext
have fun, Thomas
PD-announce mailing list PD-announce@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-announce
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
a question about this... if i have an abstraction fileio.pd that uses pool, then i have a song1.pd which is a song that uses a [fileio] object in it, and they are both in different directories (every song of mine is kept in its own folder to keepthings neat) will the pool save file end up in the fileio.pd directory, or the song1.pd directory?
Just try it. ;)
Now seriously: I tested this with a slightly older pool from CVS (but tagged 0.2.0something) It saves in the directory of [fileio]. I don't see how an abstraction could know in which other patch it is used and what the directory of this patch is, but maybe there is a way. Generally I would recommend to stick to absolute paths where possible because of this. At least I expect this for Memento.
Ciao
Frank Barknecht _ ______footils.org__
Hi,
Now seriously: I tested this with a slightly older pool from CVS (but tagged 0.2.0something) It saves in the directory of [fileio]. I don't see how an abstraction could know in which other patch it is used and what the directory of this patch is, but maybe there is a way. Generally I would recommend to stick to absolute paths where possible because of this. At least I expect this for Memento.
this behavior has not changed since 0.2.0something. I see from your example that relative paths have their caveats. I'm open for better solutions though - any suggestions?
best greetings, Thomas
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
this behavior has not changed since 0.2.0something. I see from your example that relative paths have their caveats. I'm open for better solutions though - any suggestions?
I don't think, it's a problem with pool, it's a caveat for users. If they take care about where their paths point to it's not a real problem. I always use absolute paths anyway (which could be stored in a pool btw.).
Ciao
Frank Barknecht _ ______footils.org__
it is a usability problem for systems like bitvitriol (my perf env) and rrradical if you try to share songs with other people, since the hardcoded absolute path's will be wrong when you move the song anywhere. that being said, i dont know a solution (yet) ...
Frank Barknecht wrote:
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
this behavior has not changed since 0.2.0something. I see from your example that relative paths have their caveats. I'm open for better solutions though - any suggestions?
I don't think, it's a problem with pool, it's a caveat for users. If they take care about where their paths point to it's not a real problem. I always use absolute paths anyway (which could be stored in a pool btw.).
Ciao
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
it is a usability problem for systems like bitvitriol (my perf env) and rrradical if you try to share songs with other people, since the hardcoded absolute path's will be wrong when you move the song anywhere. that being said, i dont know a solution (yet) ...
Well, in RRADical you normally select the pool file to load with openpanel, which returns full paths.
Ciao
Frank Barknecht _ ______footils.org__
hi list!, is there any declicker object or abstraction in pd?
thanx
siggmus
Frank Barknecht wrote:
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
it is a usability problem for systems like bitvitriol (my perf env) and rrradical if you try to share songs with other people, since the hardcoded absolute path's will be wrong when you move the song anywhere. that being said, i dont know a solution (yet) ...
Well, in RRADical you normally select the pool file to load with openpanel, which returns full paths.
Ciao
which is a nice hack around the problem, but name another major song writing environment that you have to remind where the songs meta data lives every time you move the folder :) right now in bitvitriol you *have* to open your song's pd file through its little openpanel wrapper object, which then gleans the data directory from that path.... it works, but its less than slick.
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
Frank Barknecht wrote:
Well, in RRADical you normally select the pool file to load with openpanel, which returns full paths.
which is a nice hack around the problem, but name another major song writing environment that you have to remind where the songs meta data lives every time you move the folder :) right now in bitvitriol you *have* to open your song's pd file through its little openpanel wrapper object, which then gleans the data directory from that path.... it works, but its less than slick.
So you do it the same way as I do. I agree it's less than slick, but on the other hand, major applications like Word work the same way. You first navigate to a file you intend to work on, then you change that file. The good thing about this is, that you can even save the file in another location under another name. So you can keep two working copies or even use the same patch for several pieces.
Ciao
Frank Barknecht _ ______footils.org__
So you do it the same way as I do.
if i ever get around to releasing bitvitriol to the public you'll probably chuckle at the similarities :) i think you and i started doing almost exactly the same thing in the same way at the same time... talk about convergant evolution. at some point i will probably attempt a merge with rrradical, but i havnt used rrradical too much, so im not sure our two metaphores are 100% identical. plus, with the way i think pd handles abstractions, there is actually no more overhead to use both rrad objects and bitvit objects in the same song file, since even though theyd be using redundant state saving objects, the code is replicated in every instance of the same abstraction anyhow. so maybe the best solution is for me to just write a memento->bv.state conduit...
I agree it's less than slick, but on the other hand, major applications like Word work the same way. You first navigate to a file you intend to work on, then you change that file.
right, but in word your data (the text of the letter) and the metadata (font info, etc) are in the same file, whereas a "song" in bitvit (and i suspect rrradical) consists of a .pd file which is the "data", the connections if bitvit objects and such, and a couple of other .txt pool files, which is the metadata. so as long as you open up the .pd file through the bitvit provided wrapper, all is well, but if the user uses the tempting "file->open" command on the pd window (which a friend of mine did) then the patch will open and freak out not knowing where to find its metadata. i've contemplated using tot to overload the file->open menu to load it through my abstraction, unless you can think of a smarter way to intercept the open action...
The good thing about this is, that you can even save the file in another location under another name. So you can keep two working copies or even use the same patch for several pieces.
two song files sharing the same metadata? or two metadata's sharing the same file? interesting, but confusing :)
bis spater. -j
if i ever get around to releasing bitvitriol to the public you'll probably chuckle at the similarities :) i think you and i started doing almost exactly the same thing in the same way at the same time... talk about convergant evolution.
Which means that there are at least three such systems (guess what i wrote pool for initially....)
T
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Which means that there are at least three such systems (guess what i wrote pool for initially....)
Oh, I forgot you, of course. ;) There also is state saving in IEM and in this large abstraction collection whose name I always forget.
Anyway apart from your unpublished collection which I don't know I think (but might be wrong), that rradical/memento is the only (published) one which actually handles hierarchies. (I suppose, yours will or does handle this, too.) For example I have a adsr patch, which could be used stand-alone, but can also be used inside other rradical patches with full state saving and OSC control. I do this for example in rrad.fm2~.pd
This is an important advantage over the preset in Max or [state] in GGEE.
And: Memento is very easy to use even for Pd beginners. The manual only contains three simple rules:
- create an [originator $1 $0],
- cross-connect things needing save with [commun /yourName $0] objects.
- Use your abstractions with a unique first argument starting with a /slash.
This simplicity is very intentional. State saving must not hurt, it must feel natural, while still being flexible enough even for uses the designer did not think of in advance.
In the end I hope, Memento will die because Pd offers something similar built in. So Memento is just a working suggestion how state saving and remote control could feel.
Ciao
Frank Barknecht _ ______footils.org__
there seems to be a general stigma associated with publishing patches. there are some on em411.com (some super dope patches there, though) as well as some on pure-data.info. true performance oriented patches, insturments, etc there are few.
why is this? it's interesting from the point of view of learning pd because it does require that you spend some time programming if you want something in these categories, but odd none the less.
because people don't want to spend the time supporting them?
revisiting an old thread, people want to protect ip/sale patches a la pluggo?
what are yall's thoughts on it?
-star
On Wed, 2004-08-11 at 18:03, Frank Barknecht wrote:
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Which means that there are at least three such systems (guess what i wrote pool for initially....)
Oh, I forgot you, of course. ;) There also is state saving in IEM and in this large abstraction collection whose name I always forget.
Anyway apart from your unpublished collection which I don't know I think (but might be wrong), that rradical/memento is the onl (published) one which actually handles hierarchies. (I suppose, yours will or does handle this, too.) For example I have a adsr patch, which could be used stand-alone, but can also be used inside other rradical patches with full state saving and OSC control. I do this for example in rrad.fm2~.pd
This is an important advantage over the preset in Max or [state] in GGEE.
And: Memento is very easy to use even for Pd beginners. The manual only contains three simple rules:
- create an [originator $1 $0],
- cross-connect things needing save with [commun /yourName $0] objects.
- Use your abstractions with a unique first argument starting with a /slash.
This simplicity is very intentional. State saving must not hurt, it must feel natural, while still being flexible enough even for uses the designer did not think of in advance.
In the end I hope, Memento will die because Pd offers something similar built in. So Memento is just a working suggestion how state saving and remote control could feel.
Ciao
because people don't want to spend the time supporting them?
i'm too lazy for a long answer. the short answer would be that everyone has its own motivation but it would be possible (would take a long time though) to list all the stereotyped behaviours from the psycho developer and his 100% pure geek patches that would not obviously mean a lot to be shared, to the "normal" user too shy to post/announce anything on the main list but has his "secret pd life" somewhere on a some sites/forums (and we should not forget to mention the patcher who will never release his absolute holy grail killing tool he's working on for 4 years now ... good luck buddy you will succeed ... eventually)
Now the good question would be, what if there would be a way to close the content of a patch ? would there be more performance patches shared ? well ... i'm afraid yes.
There are simply people who just don't want to share their work, researches, tools ... though they may just copy paste from what a few others are ok to share. It's been like this for ages, it's like this for a lot of creation fields.
Sure it's disappointing, but well ... can't help i guess and it will not avoid me to sleep tonight.
what are yall's thoughts on it?
hip hop and you don't stop.
Frank (aka DJ Frank "Funky Town" Barknecht) and I are working on a pd/Gem flyer that will announce shortly a friendly pd demo online contest that will last from mid august till end of september. More infos soon.
I think it will be a good benchmark for the pd patcher community, how much patches will we receive ? 2 ? 1000 ?
On Wed, 2004-08-11 at 20:00, aym3ric wrote:
because people don't want to spend the time supporting them?
i'm too lazy for a long answer.
indeed... ;)
the short answer would be that everyone has its own motivation but it would be possible (would take a long time though) to list all the stereotyped behaviours from the psycho developer and his 100% pure geek patches that would not obviously mean a lot to be shared, to the "normal" user too shy to post/announce anything on the main list but has his "secret pd life" somewhere on a some sites/forums (and we should not forget to mention the patcher who will never release his absolute holy grail killing tool he's working on for 4 years now ... good luck buddy you will succeed ... eventually)
personaly, i think it's the "pure geek" patches that are the most interesting. but that aside, i'd also think that the "holy grail" patchers would eventually want to release thier tools driven by the same "ultrageek" status-seeking and peer review pathos that drive the open source community. this last bit is the source of my question, because it doesn't seem like that's how it works out in the patcher world.
Now the good question would be, what if there would be a way to close the content of a patch ? would there be more performance patches shared ? well ... i'm afraid yes.
prolly true, but really unfortunante. i guess there must be some other reason then the cost that they use pd instead of max. data structures? ;)
interesting enough, this dovetails with another thought i'm sure has kicked arround a bit... using pd as a modeling tool, and having an external that takes the patch and the pd source, generating c code that could then be compliled and released under whatever license the author sees fit.
There are simply people who just don't want to share their work, researches, tools ... though they may just copy paste from what a few others are ok to share. It's been like this for ages, it's like this for a lot of creation fields.
Sure it's disappointing, but well ... can't help i guess and it will not avoid me to sleep tonight.
same, and true.
what are yall's thoughts on it?
hip hop and you don't stop.
lottydotty. weliketopahty. wedontcausetrouble. wedontbothernobody.
Frank (aka DJ Frank "Funky Town" Barknecht) and I are working on a pd/Gem flyer that will announce shortly a friendly pd demo online contest that will last from mid august till end of september. More infos soon.
cool - that sounds awsome! sure to be some insteresting stuff to come of that.
I think it will be a good benchmark for the pd patcher community, how much patches will we receive ? 2 ? 1000 ?
survey says: 42
hi, i just have read a text about residualism , or the possibilities of some digital tools about exploring the non-audible part of sound: "sound is never described in what is absent, missing or overlooked: negative space...most of the digital detritus gets noise reduced, multi-band compressed, brickwall filtered out...but we now find ourselves immersed in the next wave of digital audio...new tools have emerged that are capable of exploring both the signal and what's behind it..."
do anybody have tried that in pd? which options do i have to explore this?
many thanks
siggmus
On Thu, 12 Aug 2004, Frank Barknecht wrote:
will or does handle this, too.) For example I have a adsr patch, which could be used stand-alone, but can also be used inside other rradical patches with full state saving and OSC control. I do this for example in rrad.fm2~.pd
This is an important advantage over the preset in Max or [state] in GGEE.
You can do this easily with state using $ arguments for your abstractions. The naming for each state file is name.state where "name" and "state" can be chosen freely.
You can even generate all your envelopes with just one envelope abstraction and later handle the setting on a file system level by copying them around , duplicating, renaming and reusing in other abstraction instances.
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Thu, 12 Aug 2004, Frank Barknecht wrote:
will or does handle this, too.) For example I have a adsr patch, which could be used stand-alone, but can also be used inside other rradical patches with full state saving and OSC control. I do this for example in rrad.fm2~.pd
This is an important advantage over the preset in Max or [state] in GGEE.
You can do this easily with state using $ arguments for your abstractions. The naming for each state file is name.state where "name" and "state" can be chosen freely.
But can I save the state(s) of a full patch which uses various levels of abstractions into a single file using [state]?
You can even generate all your envelopes with just one envelope abstraction and later handle the setting on a file system level by copying them around , duplicating, renaming and reusing in other abstraction instances.
But isn't this exactly the problem? It forces a user to depend on something like the filesystem and its tools and thus is inherently platform dependent.
Ciao
Frank Barknecht _ ______footils.org__
On Thu, 12 Aug 2004, Frank Barknecht wrote:
You can do this easily with state using $ arguments for your abstractions. The naming for each state file is name.state where "name" and "state" can be chosen freely.
But can I save the state(s) of a full patch which uses various levels of abstractions into a single file using [state]?
You can even generate all your envelopes with just one envelope abstraction and later handle the setting on a file system level by copying them around , duplicating, renaming and reusing in other abstraction instances.
But isn't this exactly the problem? It forces a user to depend on something like the filesystem and its tools and thus is inherently platform dependent.
Sorry, I didn't want to convince you to use state. state is dead. I was just correcting a misconception about state that you had.
You are free to use the above mentioned arguments (which are definitely valid) to demonstrate the superiority of pool.
Guenter
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
So you do it the same way as I do.
if i ever get around to releasing bitvitriol to the public you'll probably chuckle at the similarities :) i think you and i started doing almost exactly the same thing in the same way at the same time...
We're not alone. Dave McCallum is also doing stuff in this area as is Ben Bogart somehow. Actually I'm sure, everyone is using some kind of state saving and GOP. ;)
so as long as you open up the .pd file through the bitvit provided wrapper, all is well, but if the user uses the tempting "file->open" command on the pd window (which a friend of mine did) then the patch will open and freak out not knowing where to find its metadata.
This problem is not existing in RRADical. Unless a user decides to save path information inside the RRADical pool (for example the location of samples) everything is independent of the location in the filesystem.
I did it by "abstracing" out the actual "saving", which is now called "caretaking" and done by various caretakers. In fact, if you look into the current CVS I already work on a state saver which doesn't save to the filesystem at all, but can save *into* an OSC connection, that is it send the whole state to a network connection. Other caretakers like for example a CVS checkin caretaker are also possible.
The good thing about this is, that you can even save the file in another location under another name. So you can keep two working copies or even use the same patch for several pieces.
two song files sharing the same metadata? or two metadata's sharing the same file? interesting, but confusing :)
Two state files for the same Pd patch. For example I have the beginnings of a performance patch at http://footils.org/pkg/showcase.tgz which contains some samplers, drum machines and an FM synth. I can play various tracks with this by just loading another state file into the pool. It's like a sequencer where I just load another score.
Ciao
Frank Barknecht _ ______footils.org__
-
aym3ric -
Frank Barknecht -
guenter geiger -
Josh Steiner -
shift8 -
siggmuss -
Thomas Grill