hi ben,
try the method that frank barknecht uses in his angriff/seq stuff. it writes the values of guis to a textfile and can therefore be reloaded dead quick. ( http://footils.org/cgi-bin/cms/ ;thank you frank!) regards, flo
Hallo, florian grassl hat gesagt: // florian grassl wrote:
try the method that frank barknecht uses in his angriff/seq stuff. it writes the values of guis to a textfile and can therefore be reloaded dead quick. ( http://footils.org/cgi-bin/cms/ ;thank you frank!)
Actually I'm converting all my patches to use Thomas Grill's "pool" currently, which has several advantages above all other methods of persistence I tried so far and is now my "Memento" of choice. A new release of angriff & co using that approach may be ready next week.
Memento here refers to a software design pattern. Using pool it is possible to abstract the persistance from the algorithm, that's needs to persist a state somehow. The way I (intend to) use pool here is to have a pool object somewhere in an abstraction that is used in e.g. angriff and that gets a user defined name, so it can share it's settings with all other pool objects. The actual saving is removed from angriff and will be the responsibility of the patch author. But with pool it's dead simple. It's a bit difficult to explain in words, though, so I'll better attach an example:
tester.pd is the main patch, that uses the pool-abs abstraction two times. Each pool-abs contains a named pool object, that gets its name from the first argument ($0-storage in example). The second argument is just a key that makes both abstractions use unique names, so that you can store different settings in each.
tester.pd also has a named pool object, that bares the same name as the other two pools. This creates a magic global and instantaneous connection between all the pools (like the tunneling effect in quantum physics)
So all saving of all used patches can be done in a central place. Dave MacCallum had to overcome a lot of ugly obstacles to do largely the same just with builtin objects in his reworked d-angriff patches and a lot of other patches, but with pool it's so much more simple, that it's worth the extra external. Dave, don't you agree after seeing the attached example?
In the end angriff et al. will make use of pool hierarchies but that's too much to explain here and now.
ciao
Frank Barknecht _ ______footils.org__
Frank,
Actually, I'd also come to the same idea of using Pool to cover my state saving. The only problem was that Pool saved in a path relative to the Pd dir and I needed it to save relative to the patch dir, but I think that's being changed.
I've currently got a really ugly (but it works!) method for saving abstraction states in files in the path of whatever parent patch is making use of the abstractions. This way each of your patches can have unique state settings. I've got a modular mixer strip setup that makes heavy use of this.
Interesting with what you've done about using one file to hold the settings for multiple abstractions, though... I'll have to think more about that... Actually, that's going to be awesome. You could have *all* possible drum settings all stored in just one settings file... hmmmm... Good work, Frank. :)
David . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
Frank Barknecht wrote:
So all saving of all used patches can be done in a central place. Dave MacCallum had to overcome a lot of ugly obstacles to do largely the same just with builtin objects in his reworked d-angriff patches and a lot of other patches, but with pool it's so much more simple, that it's worth the extra external. Dave, don't you agree after seeing the attached example?
Hallo, David NG McCallum hat gesagt: // David NG McCallum wrote:
Interesting with what you've done about using one file to hold the settings for multiple abstractions, though... I'll have to think more about that... Actually, that's going to be awesome. You could have *all* possible drum settings all stored in just one settings file... hmmmm... Good work, Frank. :)
Well, actually it's just using a feature that Thomas had already built in with far sight. I just only now discovered it. With only one file it doesn't matter at all anymore, where the patch data is saved. You could save it anywhere, it's just a single file.
Actually I was investigating pool as a means of standard persistance for a project I will work on the whole December, that I could just as well present shortly now, because I'd love to get help from you and others doing similar graph on parent patches.
My goal is to create a collection of patches, that make Pd easier and faster to use for people who are more used to software like Reason or Reaktor. For that I would like to create patches, that solve real-world problems on a higher level of abstraction than the standard Pd objects do. All these high level abstractions should come with (detachable and changable) GUIs built in and must use a common way of saving states. That's were pool came in.
So for example instead of a basic lop~ low pass filter something more complete like a recreation of the Sherman filter bank should be included in that collection. My sseq and angriff patches followed this idea in general, but there are much more patches needed.
Like
- a sample player (adapt Gyre?)
- Various OSC/LFO with preset waveforms
- drum machine
- guitar simulator
- grain sample player
- more sequencers
- basically a lot of things like that: http://www.propellerheads.se/products/reason/closeup.html
Not that I want to make Pd be Reason, no way. But pre-fabricated high-level abstractions are what I want to collect because I see a use for it.
My project also has gotten a marketing name already:
RRADical Pd
with RRAD as an acronym for "Reusable and Rapid Audio Development" with Pd. RRADical Pd will (very likely) be presented at the next Linux Audio Developer conference in Germany at the end of April so there is still some time to actually make it take off before.
I'd like to discuss ideas for this project here. Next week I will also set up a Wiki-area on pure-data.org where thoughts and results for this can be made public (and persistent).
ciao
Frank Barknecht _ ______footils.org__
This is just the same reason why I've been doing my Gem abstractions (where the same issues of higher-level working chunks help students learn pd/gem and make things easier (even for myself!).
I think it does make sense to coordinate efforts. I propose that we make a *standard* GOP state-saving abstraction using pool. this way other applications can build on top of these objects and we have some great consistancy. I don't think it will be too much of an issue to have one design that works for all our GOP needs... I think flexibility is a plus here.
oh and david, you can get pool for windows on Thomas's site:
http://www.parasitaere-kapazitaeten.net/Pd/ext/
Ben.
Hallo, David NG McCallum hat gesagt: // David NG McCallum wrote:
Interesting with what you've done about using one file to hold the settings for multiple abstractions, though... I'll have to think more about that... Actually, that's going to be awesome. You could have *all* possible drum settings all stored in just one settings file... hmmmm... Good work, Frank. :)
Well, actually it's just using a feature that Thomas had already built in with far sight. I just only now discovered it. With only one file it doesn't matter at all anymore, where the patch data is saved. You could save it anywhere, it's just a single file.
Actually I was investigating pool as a means of standard persistance for a project I will work on the whole December, that I could just as well present shortly now, because I'd love to get help from you and others doing similar graph on parent patches.
My goal is to create a collection of patches, that make Pd easier and faster to use for people who are more used to software like Reason or Reaktor. For that I would like to create patches, that solve real-world problems on a higher level of abstraction than the standard Pd objects do. All these high level abstractions should come with (detachable and changable) GUIs built in and must use a common way of saving states. That's were pool came in.
So for example instead of a basic lop~ low pass filter something more complete like a recreation of the Sherman filter bank should be included in that collection. My sseq and angriff patches followed this idea in general, but there are much more patches needed.
Like
- a sample player (adapt Gyre?)
- Various OSC/LFO with preset waveforms
- drum machine
- guitar simulator
- grain sample player
- more sequencers
- basically a lot of things like that: http://www.propellerheads.se/products/reason/closeup.html
Not that I want to make Pd be Reason, no way. But pre-fabricated high-level abstractions are what I want to collect because I see a use for it.
My project also has gotten a marketing name already:
RRADical Pd
with RRAD as an acronym for "Reusable and Rapid Audio Development" with Pd. RRADical Pd will (very likely) be presented at the next Linux Audio Developer conference in Germany at the end of April so there is still some time to actually make it take off before.
I'd like to discuss ideas for this project here. Next week I will also set up a Wiki-area on pure-data.org where thoughts and results for this can be made public (and persistent).
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Only 0.1.0 is compiled on the site. There's a feature in 0.2.0 (saving in the path of the parent) that I very much need to have and can't really start working on changing my state-saving patches until it's implemented. :-/
David . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
ben@ekran.org wrote:
oh and david, you can get pool for windows on Thomas's site:
http://www.parasitaere-kapazitaeten.net/Pd/ext/
Ben.
hmmm!
don't have you MSVC++ at school? the project files are all in CVS...
Ben
PS: I don't have access to that compiler, so I'd also love the new version. (as I have not played with it enough to relize the feature is missing!)
Only 0.1.0 is compiled on the site. There's a feature in 0.2.0 (saving in the path of the parent) that I very much need to have and can't really start working on changing my state-saving patches until it's implemented. :-/
David . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
ben@ekran.org wrote:
oh and david, you can get pool for windows on Thomas's site:
http://www.parasitaere-kapazitaeten.net/Pd/ext/
Ben.
Not that I want to make Pd be Reason, no way. But pre-fabricated high-level abstractions are what I want to collect because I see a use for it.
My project also has gotten a marketing name already:
RRADical Pd
with RRAD as an acronym for "Reusable and Rapid Audio Development" with Pd. RRADical Pd will (very likely) be presented at the next Linux Audio Developer conference in Germany at the end of April so there is still some time to actually make it take off before.
well, what you are trying to create is similar to loopool (although it's using subpatches instead of abstractions) ...
anyway, there should be any way in combining both approaches, i can implement the abstractions you collected, and you could try to convert loopool's subpatches to GOP abstractions...
take care...
Tim mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.nyds-exp-discogs.tk -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
well, what you are trying to create is similar to loopool (although it's using subpatches instead of abstractions) ...
Yes, loopool is in many way similar to RRADical, but at the core of its idea is the use of abstractions, and not subpatches. That's the prerequisite for the first letter in its acronym: Reusablility. Subpatches aren't reusable enough to be flexible outside a certain patch.
I love what loopool does, but is hard to adapt it to other uses in its current form.
anyway, there should be any way in combining both approaches, i can implement the abstractions you collected, and you could try to convert loopool's subpatches to GOP abstractions...
Yes, that's a good idea. I think, that once a coarse concept is done, most of the work is best spend ripping existing patches apart. ;)
ciao
Frank Barknecht _ ______footils.org__
hi frank, list
i've been moving toward this type of reusable idea with my patches, and i think it's a good idea to support something like this as a group. the problem has always been creating abstractions than can mingle. everyone has varying programming styles, and with a system as open as pd, having abstractions communicate in a common way can be difficult.
one thing i've found useful is routing abstractions using OSC. each abstraction is given a name as it's first argument, and it can automatically be referenced from that point on with:
/pd/synth/(name)
so the user just needs to know how to create the abstraction and give it a name, and then set a sequencer to send OSC commands to that synth using a standard interface. this way, i can have lots of different synth abstractions controlled the same way.
i'll try to post some examples soon, but i guess what i'd like to see is some collaboration on a higher level framework. i'm with you on this idea frank.
-- eric
My goal is to create a collection of patches, that make Pd easier and faster to use for people who are more used to software like Reason or Reaktor. For that I would like to create patches, that solve real-world problems on a higher level of abstraction than the standard Pd objects do. All these high level abstractions should come with (detachable and changable) GUIs built in and must use a common way of saving states. That's were pool came in.
So for example instead of a basic lop~ low pass filter something more complete like a recreation of the Sherman filter bank should be included in that collection. My sseq and angriff patches followed this idea in general, but there are much more patches needed.
Like
- a sample player (adapt Gyre?)
- Various OSC/LFO with preset waveforms
- drum machine
- guitar simulator
- grain sample player
- more sequencers
- basically a lot of things like that: http://www.propellerheads.se/products/reason/closeup.html
Not that I want to make Pd be Reason, no way. But pre-fabricated high-level abstractions are what I want to collect because I see a use for it.
My project also has gotten a marketing name already:
RRADical Pd
with RRAD as an acronym for "Reusable and Rapid Audio Development" with Pd. RRADical Pd will (very likely) be presented at the next Linux Audio Developer conference in Germany at the end of April so there is still some time to actually make it take off before.
I'd like to discuss ideas for this project here. Next week I will also set up a Wiki-area on pure-data.org where thoughts and results for this can be made public (and persistent).
ciao
------ http://USFamily.Net/info - Unlimited Internet - From $8.99/mo! ------
Hallo, e skogen hat gesagt: // e skogen wrote:
i've been moving toward this type of reusable idea with my patches, and i think it's a good idea to support something like this as a group. the problem has always been creating abstractions than can mingle. everyone has varying programming styles, and with a system as open as pd, having abstractions communicate in a common way can be difficult.
one thing i've found useful is routing abstractions using OSC. each abstraction is given a name as it's first argument, and it can automatically be referenced from that point on with:
/pd/synth/(name)
so the user just needs to know how to create the abstraction and give it a name, and then set a sequencer to send OSC commands to that synth using a standard interface. this way, i can have lots of different synth abstractions controlled the same way.
That's interesting. I never thought of that, cool idea. And it even works over networks, so that two or more people could jam together.
i'll try to post some examples soon, but i guess what i'd like to see is some collaboration on a higher level framework. i'm with you on this idea frank.
I'd love to see some examples. So there are already proposed solutions for:
- persistance (state saving): pool
- communication (send messages in a unified way between patches):
OSC, send/receive,...
ciao
Frank Barknecht _ ______footils.org__
My Gem GOPs all have OSC hooks (named by the creation argument) I also have two objects v_oscin and v_oscout that route the messages over network. I'm also using OSC names interally to control the GOPs...
I'll put up the current state of the abstractions in CVS and in pure-data later tonight.
Ben
Hallo, e skogen hat gesagt: // e skogen wrote:
i've been moving toward this type of reusable idea with my patches, and i think it's a good idea to support something like this as a group. the problem has always been creating abstractions than can mingle. everyone has varying programming styles, and with a system as open as pd, having abstractions communicate in a common way can be difficult.
one thing i've found useful is routing abstractions using OSC. each abstraction is given a name as it's first argument, and it can automatically be referenced from that point on with:
/pd/synth/(name)
so the user just needs to know how to create the abstraction and give it a name, and then set a sequencer to send OSC commands to that synth using a standard interface. this way, i can have lots of different synth abstractions controlled the same way.
That's interesting. I never thought of that, cool idea. And it even works over networks, so that two or more people could jam together.
i'll try to post some examples soon, but i guess what i'd like to see is some collaboration on a higher level framework. i'm with you on this idea frank.
I'd love to see some examples. So there are already proposed solutions for:
- persistance (state saving): pool
- communication (send messages in a unified way between patches): OSC,
send/receive,...
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Over on the Piksel list all have been talking about OMC (open media control), and a shared OSC namespace for all the possible effects. It's not very PD compatible though.
I've added OSC names to my GOP abstractions as /v/[name]/[param] I did not put in another level to group the different abtractions /v/rotate/[name]/[param]. (I just do that stuff with naming in the patch /r? for rotate etc..)
I have been using these OSC names interally as well, to control things programatically at the same time as through the GUI. These have the same names without the /v/ part (I was having feedback loop issues!)
It would be pretty cool if these Gem GOP controls could be compatible with the audio stuff... (over network or locally)...
as the sound position changes the cube rotates.. (over-simplistic!)
I've put my current version of gem abstractions on pure-data:
http://www.pure-data.org/Members/bbogart/v_abstractions2/view
Pay most attension to the abstractions named v_* I included some early examples. I'm also open to critisisms as it comes to my usage of OSC, since I have made it impossible to send OSC controls that go beyond the scale of the GUI objects... (because I want the GUI to update based on the OSC commands)
I'll put this stuff in CVS as soon as I can.
Ben
----- Original Message ----- From: "e skogen" eskogen@usfamily.net To: "Frank Barknecht" fbar@footils.org Cc: pd-list@iem.at Sent: Friday, November 28, 2003 12:40 PM Subject: Re: [PD] Announcing "RRADical Pd"
hi frank, list
i've been moving toward this type of reusable idea with my patches, and i think it's a good idea to support something like this as a group. the problem has always been creating abstractions than can mingle. everyone has varying programming styles, and with a system as open as pd, having abstractions communicate in a common way can be difficult.
one thing i've found useful is routing abstractions using OSC. each abstraction is given a name as it's first argument, and it can automatically be referenced from that point on with:
/pd/synth/(name)
so the user just needs to know how to create the abstraction and give it a name, and then set a sequencer to send OSC commands to that synth using a standard interface. this way, i can have lots of different synth abstractions controlled the same way.
i'll try to post some examples soon, but i guess what i'd like to see is some collaboration on a higher level framework. i'm with you on this idea frank.
-- eric
My goal is to create a collection of patches, that make Pd easier and faster to use for people who are more used to software like Reason or Reaktor. For that I would like to create patches, that solve real-world problems on a higher level of abstraction than the standard Pd objects do. All these high level abstractions should come with (detachable and changable) GUIs built in and must use a common way of saving states. That's were pool came in.
So for example instead of a basic lop~ low pass filter something more complete like a recreation of the Sherman filter bank should be included in that collection. My sseq and angriff patches followed this idea in general, but there are much more patches needed.
Like
- a sample player (adapt Gyre?)
- Various OSC/LFO with preset waveforms
- drum machine
- guitar simulator
- grain sample player
- more sequencers
- basically a lot of things like that: http://www.propellerheads.se/products/reason/closeup.html
Not that I want to make Pd be Reason, no way. But pre-fabricated high-level abstractions are what I want to collect because I see a use for it.
My project also has gotten a marketing name already:
RRADical Pd
with RRAD as an acronym for "Reusable and Rapid Audio Development" with Pd. RRADical Pd will (very likely) be presented at the next Linux Audio Developer conference in Germany at the end of April so there is still some time to actually make it take off before.
I'd like to discuss ideas for this project here. Next week I will also set up a Wiki-area on pure-data.org where thoughts and results for this can be made public (and persistent).
ciao
------ http://USFamily.Net/info - Unlimited Internet - From
$8.99/mo! ------
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, B. Bogart hat gesagt: // B. Bogart wrote:
I've added OSC names to my GOP abstractions as /v/[name]/[param] I did not put in another level to group the different abtractions /v/rotate/[name]/[param]. (I just do that stuff with naming in the patch /r? for rotate etc..)
I have been using these OSC names interally as well, to control things programatically at the same time as through the GUI. These have the same names without the /v/ part (I was having feedback loop issues!)
It would be pretty cool if these Gem GOP controls could be compatible with the audio stuff... (over network or locally)...
I don't see why they couldn't be compatible. It's seems to be just a matter of coordination.
I've put my current version of gem abstractions on pure-data:
http://www.pure-data.org/Members/bbogart/v_abstractions2/view
I got a small error while unpacking it, but mostly it seems okay. (Btw: could you give v_abstractions2 a name with a suffix like .tgz? This will make it easier to find out what kind of file it is for others.)
This are very cool patches and highly qualify to be called "RRADical" ;)
Pay most attension to the abstractions named v_* I included some early examples. I'm also open to critisisms as it comes to my usage of OSC, since I have made it impossible to send OSC controls that go beyond the scale of the GUI objects... (because I want the GUI to update based on the OSC commands)
I'm not the one to critizise OSC yet, as I'm still learning it, but I'm already very fond of it after seeing how you and Eric use it.
I played a bit with your patches and it way dead simple to add persistance with pool to it. I attached my quick-hack first version. The example is a slightly modified v_color renamed to osctest.pd. I moved the canvas a bit lower so that the patch args are visible, which is something I prefer. Otherwise the only change inside was, that I abstracted out the [pd OSC] subpatch to be a standalone abstraction called pdOSC (bad name, but easy to use here). This way my beloved Reusability is easier to achieve.
Interestingly pool persistance, saving and reloading was possible without any further changes to your v_color patch. So there was not even a need to put a second pool object into it. It highly seems as if OSC and pool are an ideal couple and made for each other to be married. I used prepend (from whichever lib) and glue (zexy) to make things easier to read here. With both, arbitrary value lengths will be possible.
Reloading in my exploration still requires an "OSCroute /v", but that could probably be cut out, too.
ciao
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Interestingly pool persistance, saving and reloading was possible without any further changes to your v_color patch. So there was not even a need to put a second pool object into it. It highly seems as if OSC and pool are an ideal couple and made for each other to be married. I used prepend (from whichever lib) and glue (zexy) to make things easier to read here. With both, arbitrary value lengths will be possible.
Ah, there is an error with the ordering of the crossed connections between pool and glue. I'll need to fixed that..
ciao
Frank Barknecht _ ______footils.org__
Hallo,
attached if main.pd with a fixed triggering.
ciao
Frank Barknecht _ ______footils.org__
Hey Frank,
I don't see why they couldn't be compatible. It's seems to be just a matter of coordination.
I agree, what you did with using my OSC routes (in and out) is what I was hoping to be able to do. This could be a good way for approching the design for RRADical. I started making a new object for v_ that uses the internal OSC messages to control other GOPs. Problem is that I did not put OSC directly in this thing, because the Gops with it is controlling are the ones that send the OSC commands. It would be redundant (and probably problematic) to have both sending OSC commands that end up doing the same thing. Because v_fade does not have OSC sending commands (it does have OSC receiving) then the state could not be saved using this method...
Any ideas for a solution? I can see how a "meta-controller" that just controls other abstractions could be useful for other applications...
I got a small error while unpacking it, but mostly it seems okay. (Btw: could you give v_abstractions2 a name with a suffix like .tgz? This will make it easier to find out what kind of file it is for others.)
done. (I'm not sure why the mime-type is not enough.
This are very cool patches and highly qualify to be called "RRADical" ;)
Thanks! It will be pretty cool to have an integrated suite of such things.
I'm not the one to critizise OSC yet, as I'm still learning it, but I'm already very fond of it after seeing how you and Eric use it.
Visible abstraction arguments is for sure an issue, I took them out because the only argument (the name) is in the canvas name, and because it takes up too much screen-space (these damn v_ things really need at least a 1024 high screen!) It does make it hard to change the name after creating the object...
I played a bit with your patches and it way dead simple to add persistance with pool to it. I attached my quick-hack first version. The example is a slightly modified v_color renamed to osctest.pd. I moved the canvas a bit lower so that the patch args are visible, which is something I prefer. Otherwise the only change inside was, that I abstracted out the [pd OSC] subpatch to be a standalone abstraction called pdOSC (bad name, but easy to use here). This way my beloved Reusability is easier to achieve.
very nice. The reason why OSC was not an abstraction is that each GOP have a different number of controlls, so ideally an OSC abstraction would dynamically created the right number of inlets and outlets and know what to do with the data. (This is the only reason why OSC is not an abstraction in the first place!)
Interestingly pool persistance, saving and reloading was possible without any further changes to your v_color patch. So there was not even a need to put a second pool object into it. It highly seems as if OSC and pool are an ideal couple and made for each other to be married. I used prepend (from whichever lib) and glue (zexy) to make things easier to read here. With both, arbitrary value lengths will be possible.
It does sound great, I'm looking forward to what comes out of all this.
Reloading in my exploration still requires an "OSCroute /v", but that could probably be cut out, too.
This is so that the OSC-in and OSC-out namespace is different, otherwise the GOPs respond to outgoing messages!! and some bizarre feedback ensues..
Ben
ciao
Frank Barknecht _ ______footils.org__
Hallo Ben, B. Bogart hat gesagt: // B. Bogart wrote:
I agree, what you did with using my OSC routes (in and out) is what I was hoping to be able to do. This could be a good way for approching the design for RRADical. I started making a new object for v_ that uses the internal OSC messages to control other GOPs.
After thinking about this for quite some time I now ditched the OSC solution again, but maybe only temporarily. I ditched it, because it occured ot me, that even with OSC there still was a fundamental problem: Too many global sends/receive pairs! Global sends are a major obstacle in getting things reusable, IMO, and even with named sends like in the OSC examples, the global namespace gets polluted. Okay, with OSC it's not that bad, because it's sends inside OSC and not in the regular send/receive, but still I wasn't too happy with it.
Thinking even hard I now made a first try at a reference implementation of my prior Memento idea. You can get and try it at http://www.pure-data.org/Members/fbar/patches/memento-0.1.tgz/view
It comes with an extensive README.txt, and still includes some unfinished testing. The main patch to look at is called "mainpatch", which in turn uses an example abstraction called "rradical". Here's an shortened excerpt from the README:
This is a work-in-progress collection of a unified preset system for Pd patches. It tries to loosely follow the Memento [1] design pattern from the Gang of Four book.
I propose that a Memento here is realised as a directory in a data pool inside a [pool] object.
The Memento is only changed or read through the [originator] abstraction.
It is not allowed to bypass [originator] to change the values inside the RRADICAL pool, with one exception:
The [caretaker] abstraction is responsible for saving and loading pool data from harddisk.
Communication between [originator] and anything that wants to save anything is done through the [commun] abstraction.
[commun] accepts anything and spits out anything if [originator] tells it too (with [originator]'s "set" message).
_ Usage _
Every abstraction, that wants to take part in saving its settings with Memento needs to:
- include a single [originator Memento $0] object
- wrap all variables with [commun id $0] objects
A single [caretaker] then can save and reload settings. (In the parent patch.)
(Btw: could you give v_abstractions2 a name with a suffix like .tgz? This will make it easier to find out what kind of file it is for others.)
done. (I'm not sure why the mime-type is not enough.
The MIME type, at least on Windows and Linux, isn't known anymore after the file was saved to harddisk. So unless you directly open it from the browser (possible security risk) you have to find out the filetype without knowing the extension, on Linux for example with "file".
This are very cool patches and highly qualify to be called "RRADical" ;)
Thanks! It will be pretty cool to have an integrated suite of such things.
RRADical then now official is called "Reusable and Rapid APPLICATION Development" ;)
very nice. The reason why OSC was not an abstraction is that each GOP have a different number of controlls, so ideally an OSC abstraction would dynamically created the right number of inlets and outlets and know what to do with the data. (This is the only reason why OSC is not an abstraction in the first place!)
Yep, after looking at more of your patches, I've also seen that. It made me abstract out this functionality into a [commun] abstraction for Memento 0.1
ciao
Frank Barknecht _ ______footils.org__
Funny, this is extremely similar to the system I implemented... :)
I've also in my setup assumed that all GUIs have the send and receive pairs as $0-guiname_s and $0-guiname_r, and all GUIs 0-127.
David . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
Frank Barknecht wrote:
_ Usage _
Every abstraction, that wants to take part in saving its settings with Memento needs to:
- include a single [originator Memento $0] object
- wrap all variables with [commun id $0] objects
A single [caretaker] then can save and reload settings. (In the parent patch.)
Hallo, David NG McCallum hat gesagt: // David NG McCallum wrote:
Funny, this is extremely similar to the system I implemented... :)
I've also in my setup assumed that all GUIs have the send and receive pairs as $0-guiname_s and $0-guiname_r, and all GUIs 0-127.
Yes, it's very similar in the way things are localized. Memento however can persist everything (symbols, floats, lists,...) in a consistent way thanks to pool. So you could for example store a whole sseq-row in one line:
| | | ... [pack 0 0 0 ...] | [commun s8 $0] | [unpack 0 0 0 ...] | | | ...
In the example "s8" would store a list of numbers.
BTW: I'm currently trying out subfolders named with floats to get a fast state changing (== automation)
ciao
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Hallo, David NG McCallum hat gesagt: // David NG McCallum wrote:
Funny, this is extremely similar to the system I implemented... :)
I've also in my setup assumed that all GUIs have the send and receive pairs as $0-guiname_s and $0-guiname_r, and all GUIs 0-127.
Yes, it's very similar in the way things are localized. Memento however can persist everything (symbols, floats, lists,...) in a
Actually it doesn't save symbols. I've got a bug somewhere...
ciao
Frank Barknecht _ ______footils.org__
Frank, This is a way cool idea and something I've been working on in my spare time to help out friends who are new to Pd. If I wanted to contribute a bunch of small GOP modular-synth units (very simple things, just abstracting svf~ + slider, simple gop delay unit etc.), where would I do that?
Regards,
Chris.
On Fri, Nov 28, 2003 at 02:31:08PM +0100, Frank Barknecht wrote:
Hallo, David NG McCallum hat gesagt: // David NG McCallum wrote:
Interesting with what you've done about using one file to hold the settings for multiple abstractions, though... I'll have to think more about that... Actually, that's going to be awesome. You could have *all* possible drum settings all stored in just one settings file... hmmmm... Good work, Frank. :)
Well, actually it's just using a feature that Thomas had already built in with far sight. I just only now discovered it. With only one file it doesn't matter at all anymore, where the patch data is saved. You could save it anywhere, it's just a single file.
Actually I was investigating pool as a means of standard persistance for a project I will work on the whole December, that I could just as well present shortly now, because I'd love to get help from you and others doing similar graph on parent patches.
My goal is to create a collection of patches, that make Pd easier and faster to use for people who are more used to software like Reason or Reaktor. For that I would like to create patches, that solve real-world problems on a higher level of abstraction than the standard Pd objects do. All these high level abstractions should come with (detachable and changable) GUIs built in and must use a common way of saving states. That's were pool came in.
So for example instead of a basic lop~ low pass filter something more complete like a recreation of the Sherman filter bank should be included in that collection. My sseq and angriff patches followed this idea in general, but there are much more patches needed.
Like
- a sample player (adapt Gyre?)
- Various OSC/LFO with preset waveforms
- drum machine
- guitar simulator
- grain sample player
- more sequencers
- basically a lot of things like that: http://www.propellerheads.se/products/reason/closeup.html
Not that I want to make Pd be Reason, no way. But pre-fabricated high-level abstractions are what I want to collect because I see a use for it.
My project also has gotten a marketing name already:
RRADical Pd
with RRAD as an acronym for "Reusable and Rapid Audio Development" with Pd. RRADical Pd will (very likely) be presented at the next Linux Audio Developer conference in Germany at the end of April so there is still some time to actually make it take off before.
I'd like to discuss ideas for this project here. Next week I will also set up a Wiki-area on pure-data.org where thoughts and results for this can be made public (and persistent).
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
This is a way cool idea and something I've been working on in my spare time to help out friends who are new to Pd. If I wanted to contribute a bunch of small GOP modular-synth units (very simple things, just abstracting svf~ + slider, simple gop delay unit etc.),
That's exactly what I think should be in RRADical.
where would I do that?
I just now did set up a folder on pure-data.org for the project. You can find it in "community -> projects", the full path is:
http://www.pure-data.org/community/projects/rradical/
Currently this includes a Wiki page with mostly copied mailings, and a "topic", that automatically collects files and documents containing the Keyword: "rradical"
So you just have to create an account on pure-data.org, unless you already did so. Then upload your patches to your home folder there. Don't forget to give them names with correct suffixes like .pd or .zip
After uploading open up the "properties" tab of your file and select "rradical" as keyword. You can also select "patch" as well, then it will appear under "community - Pd patches", too.
After that just change the "state" of your file and "Publish" it to make it available to all other visitors.
I'm really glad, that so many folks already expressed their interest in this project. I couldn't have hoped for that many initially...
ciao
Frank Barknecht _ ______footils.org__
On Fri, Nov 28, 2003 at 07:57:44PM +0100, Frank Barknecht wrote:
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
This is a way cool idea and something I've been working on in my spare time to help out friends who are new to Pd. If I wanted to contribute a bunch of small GOP modular-synth units (very simple things, just abstracting svf~ + slider, simple gop delay unit etc.),
That's exactly what I think should be in RRADical.
where would I do that?
I just now did set up a folder on pure-data.org for the project. You can find it in "community -> projects", the full path is:
http://www.pure-data.org/community/projects/rradical/
Currently this includes a Wiki page with mostly copied mailings, and a "topic", that automatically collects files and documents containing the Keyword: "rradical"
So you just have to create an account on pure-data.org, unless you already did so. Then upload your patches to your home folder there. Don't forget to give them names with correct suffixes like .pd or .zip
After uploading open up the "properties" tab of your file and select "rradical" as keyword. You can also select "patch" as well, then it will appear under "community - Pd patches", too.
After that just change the "state" of your file and "Publish" it to make it available to all other visitors.
I'm really glad, that so many folks already expressed their interest in this project. I couldn't have hoped for that many initially...
Ok, I've uploaded my GOP mini-effects units onto p-d.org. The patches lack persistance and OSC functionality as discussed, but I think they are a good start. I'll start adding pool persistance and OSC shortly.
I think as well as making pool & OSC standard in these units it would be cool to establish the following guidelines when designing Rrad units:
- All sliders/controls have a standard range (i.e. 0 to 1 or 1 to 0) -
the patches will internally scale the value to what they need. (eg. x20000 for filter cutoff)
- All sliders/controls will send/receive on the channel $1-slidername
So for example in my s-filter~ i have two sliders resonance and cutoff. resonance can be modified from outside the unit using $1-resonance. So if the unit is:
[s-filter~ fx1] you can modify the value of cutoff by sending to 'fx1-cutoff'.
What do you guys think of that idea?
Chris. _________________________________ chris@mccormick.cx http://www.mccormick.cx http://www.hypercube.com.au http://www.sciencegirlrecords.com
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
Ok, I've uploaded my GOP mini-effects units onto p-d.org. The patches lack persistance and OSC functionality as discussed, but I think they are a good start. I'll start adding pool persistance and OSC shortly.
I think as well as making pool & OSC standard in these units it would be cool to establish the following guidelines when designing Rrad units:
- All sliders/controls have a standard range (i.e. 0 to 1 or 1 to 0) -
the patches will internally scale the value to what they need. (eg. x20000 for filter cutoff)
Actually I probably would prefer them to stay at 0-127 because of midi comatibility, but maybe this even wouldn't be necessary to unify...
- All sliders/controls will send/receive on the channel $1-slidername
So for example in my s-filter~ i have two sliders resonance and cutoff. resonance can be modified from outside the unit using $1-resonance. So if the unit is:
[s-filter~ fx1] you can modify the value of cutoff by sending to 'fx1-cutoff'.
What do you guys think of that idea?
There might very well be values that are useful to send but that are not needed to be contained in a GUI object. For example in your s-distortion the filename of the shaper array could come from outside.
I would prefer to keep things localized through $0-arguments as much as possible. What are the areas, where global access is needed? I could think of the following ones:
Persistance. Saving probably should be centralized as much as possible.
External control: After seeing some OSC patches, I'm very fond of the idea to use OSC for all communication outside the abstractions. Inside of them I think, normal send/receives would be enough, but OTOH once you start to do OSC, there might not be much need for it.
More?
I could figure an approach where you have one highly reused abstraction that would be used to wrap above points:
[r $0-somevalue-read] | [persistance_and_control_wrapper $1] <= use $1 for all global actions | [s $0-somevalue-write]
ciao
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I could figure an approach where you have one highly reused abstraction that would be used to wrap above points:
[r $0-somevalue-read] | [persistance_and_control_wrapper $1] <= use $1 for all global actions
Maybe better name that [communicate $1] because it just should provide a communication hook to the outside world (where saving, controlling and maybe more happens)
ciao
Frank Barknecht _ ______footils.org__
incidentally i am also pretty deep in the process of building a modular sequencer that saves the state of all the objects in a song using [maphash] which suffers from the same "saves the textfile releatve to the pd dir, not the patch dir" problem. how can you share a little more detail on how your solved this issue? also, what advantages does the [pool] object have over [maphash]?
-josh
David NG McCallum wrote:
Frank,
Actually, I'd also come to the same idea of using Pool to cover my state saving. The only problem was that Pool saved in a path relative to the Pd dir and I needed it to save relative to the patch dir, but I think that's being changed.
I've currently got a really ugly (but it works!) method for saving abstraction states in files in the path of whatever parent patch is making use of the abstractions. This way each of your patches can have unique state settings. I've got a modular mixer strip setup that makes heavy use of this.
Interesting with what you've done about using one file to hold the settings for multiple abstractions, though... I'll have to think more about that... Actually, that's going to be awesome. You could have *all* possible drum settings all stored in just one settings file... hmmmm... Good work, Frank. :)
David . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
Frank Barknecht wrote:
So all saving of all used patches can be done in a central place. Dave MacCallum had to overcome a lot of ugly obstacles to do largely the same just with builtin objects in his reworked d-angriff patches and a lot of other patches, but with pool it's so much more simple, that it's worth the extra external. Dave, don't you agree after seeing the attached example?
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
incidentally i am also pretty deep in the process of building a modular sequencer that saves the state of all the objects in a song using [maphash] which suffers from the same "saves the textfile releatve to the pd dir, not the patch dir" problem. how can you share a little more detail on how your solved this issue? also, what advantages does the [pool] object have over [maphash]?
I never used maphash, so I can't be to deep about that, but some of the cool pool features are:
shared storage pool possible: just give a name as first argument, and all pool's with the same name share all data and actions. With this the state-file location in the filesystem becomes rather irrelevant, because loading just one file with the full path is no PITA anymore.
saves and loads xml data, too.
Hierarchical data structure.
Pool hierarchies in XML look like this (indentation by me):
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE pool SYSTEM "pool.dtd">
<pool> <value key="1">60</value> <value key="2">51</value> <dir key="bla"> <value key="2">66</value> <value key="1">44</value> </dir> <dir key="check"> <value key="2">69</value> <value key="1">41</value> </dir> <dir key="bass"> <value key="2">8</value> <value key="1">96</value> </dir> </dir> <dir key="1"> <value key="a_symbol">0</value> <value key="b_symbol">89</value> <dir key="subfolder"> <value key="subkey">with a list inside</value> </dir> </dir> </pool>
Maybe there's even more inside...
ciao
Frank Barknecht _ ______footils.org__
Hey, i'm surprised, does XML loading actually work? I'm going to look into it.....
greetings, Thomas
----- Original Message ----- From: "Frank Barknecht" fbar@footils.org To: pd-list@iem.at Sent: Friday, November 28, 2003 10:05 PM Subject: Re: [PD] re: state saving
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
incidentally i am also pretty deep in the process of building a modular sequencer that saves the state of all the objects in a song using [maphash] which suffers from the same "saves the textfile releatve to the pd dir, not the patch dir" problem. how can you share a little more detail on how your solved this issue? also, what advantages does the [pool] object have over [maphash]?
I never used maphash, so I can't be to deep about that, but some of the cool pool features are:
shared storage pool possible: just give a name as first argument, and all pool's with the same name share all data and actions. With this the state-file location in the filesystem becomes rather irrelevant, because loading just one file with the full path is no PITA anymore.
saves and loads xml data, too.
Hierarchical data structure.
Pool hierarchies in XML look like this (indentation by me):
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE pool SYSTEM "pool.dtd">
<pool> <value key="1">60</value> <value key="2">51</value> <dir key="bla"> <value key="2">66</value> <value key="1">44</value> </dir> <dir key="check"> <value key="2">69</value> <value key="1">41</value> </dir> <dir key="bass"> <value key="2">8</value> <value key="1">96</value> </dir> </dir> <dir key="1"> <value key="a_symbol">0</value> <value key="b_symbol">89</value> <dir key="subfolder"> <value key="subkey">with a list inside</value> </dir> </dir> </pool>
Maybe there's even more inside...
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Hey, i'm surprised, does XML loading actually work? I'm going to look into it.....
Oh, no, it doesn't work, I just tried... obviously for the first time. ;)
ciao
Frank Barknecht _ ______footils.org__
Hi, could one XML expert give me a hand and have a look at the following XML structure? I have the feeling that the value item using "key" as an attribute isn't really well-done, as well as the the way how hierarchies are implemented using the "dir" item. Is there a common way to define hierarchies in XML land?
best greetings, Thomas
Pool hierarchies in XML look like this (indentation by me):
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE pool SYSTEM "pool.dtd">
<pool> <value key="1">60</value> <value key="2">51</value> <dir key="bla"> <value key="2">66</value> <value key="1">44</value> </dir> <dir key="check"> <value key="2">69</value> <value key="1">41</value> </dir> <dir key="bass"> <value key="2">8</value> <value key="1">96</value> </dir> </dir> <dir key="1"> <value key="a_symbol">0</value> <value key="b_symbol">89</value> <dir key="subfolder"> <value key="subkey">with a list inside</value> </dir> </dir> </pool>
Maybe there's even more inside...
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
could one XML expert give me a hand and have a look at the following XML structure? I have the feeling that the value item using "key" as an attribute isn't really well-done, as well as the the way how hierarchies are implemented using the "dir" item. Is there a common way to define hierarchies in XML land?
I thought about this a bit from the view of not exactly an XML expert, but maybe an HTML expert. In HTML I would see an analogy to lists. Lists in html consist of list declarations and list item declarations. List items may contain lists themselves to build up hierarchies:
<ul> <li>First list item</li> <li>Second list item <ul> <li>First nested item</li> <li>Second nested item</li> <li>Third nested item</li> </ul> </li> <li>Third list item</li> <li>Fourth list item</li> </ul>
(I also considered definition lists, but they are not good here IMO.)
Using this approach directly in the pool.xml it would look like this:
<pool> <dir key="outer_list"> <value key="a_symbol">0</value> <value key="b_symbol">89</value>
<!-- change here! Not valid with current DTD because of missing key! -->
<value>
<dir key="subfolder">
<value key="subkey">with a list inside</value>
</dir>
<!-- change 2 -->
</value>
</dir>
</pool>
I think if following the <li> example it would be much better to introduce a new attribute-less <de> ("dir entry") or <entry> tag, that is the only tag possible in a <dir> and in turn may contain <dir> and <value> items:
<pool> <dir key="outer_list"> <de><value key="a_symbol">0</value></de> <de><value key="b_symbol">89</value></de>
<de>
<dir key="subfolder">
<de><value key="subkey">with a list inside</value></de>
</dir>
</de>
</dir>
</pool>
Specifying the key name as an attribute is fine with me. For clarification maybe different names for dir-keys and value-keys might be more readable.
Just my 2 ct.
ciao
Frank Barknecht _ ______footils.org__
Hi Frank, many thanks for your elaborations. I think though that your suggestions would add more redundancy, while i'd rather want to keep it as low as possible. My primary concern is whether values should rather be given as
<value> <key>0</key> <data>1 2 3 hu ha</data> </value>
rather than currently <value key="0">1 2 3 hu ha</value> Does that matter for automatic processing of XML data or database storage? I have practically no knowledge of XML conversion.
Things that i fixed for pool include
- file paths are relative to the patcher folder
- print functions for console dump
best greetings, Thomas
----- Original Message ----- From: "Frank Barknecht" fbar@footils.org To: pd-list@iem.at Sent: Saturday, November 29, 2003 5:32 PM Subject: Re: [PD] re: state saving
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
could one XML expert give me a hand and have a look at the following XML structure? I have the feeling that the value item using "key" as an attribute isn't really well-done, as well as the the way how hierarchies are implemented using the "dir" item. Is there a common way to define hierarchies in XML land?
I thought about this a bit from the view of not exactly an XML expert, but maybe an HTML expert. In HTML I would see an analogy to lists. Lists in html consist of list declarations and list item declarations. List items may contain lists themselves to build up hierarchies:
<ul> <li>First list item</li> <li>Second list item <ul> <li>First nested item</li> <li>Second nested item</li> <li>Third nested item</li> </ul> </li> <li>Third list item</li> <li>Fourth list item</li> </ul>
(I also considered definition lists, but they are not good here IMO.)
Using this approach directly in the pool.xml it would look like this:
<pool> <dir key="outer_list"> <value key="a_symbol">0</value> <value key="b_symbol">89</value>
<!-- change here! Not valid with current DTD because of missing
key! -->
<value> <dir key="subfolder"> <value key="subkey">with a list inside</value> </dir> <!-- change 2 --> </value> </dir></pool>
I think if following the <li> example it would be much better to introduce a new attribute-less <de> ("dir entry") or <entry> tag, that is the only tag possible in a <dir> and in turn may contain <dir> and <value> items:
<pool> <dir key="outer_list"> <de><value key="a_symbol">0</value></de> <de><value key="b_symbol">89</value></de>
<de> <dir key="subfolder"> <de><value key="subkey">with a list inside</value></de> </dir> </de> </dir></pool>
Specifying the key name as an attribute is fine with me. For clarification maybe different names for dir-keys and value-keys might be more readable.
Just my 2 ct.
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo Thomas,
Thomas Grill hat gesagt: // Thomas Grill wrote:
many thanks for your elaborations. I think though that your suggestions would add more redundancy, while i'd rather want to keep it as low as possible.
Yes, that's okay. I don't think this redundancy is necessary.
My primary concern is whether values should rather be given as
<value> <key>0</key> <data>1 2 3 hu ha</data> </value>
rather than currently <value key="0">1 2 3 hu ha</value> Does that matter for automatic processing of XML data or database storage? I have practically no knowledge of XML conversion.
I think, that this could work fine. You'd need to specify <key> and <data> as required elements inside a <value>, that must occur exactly once, like:
<!ELEMENT value (key, data)>
Empty data should be allowed, imo. This would be a correct DTD, and thus every xml parser should be able to read it. I don't know, if specifying it that way was faster than using attributes, though. Files will be larger, though.
ciao
Frank Barknecht _ ______footils.org__
Thomas Grill said this at Mon, 1 Dec 2003 13:55:56 +0100:
My primary concern is whether values should rather be given as
<value> <key>0</key> <data>1 2 3 hu ha</data> </value>
rather than currently <value key="0">1 2 3 hu ha</value> Does that matter for automatic processing of XML data or database storage? I have practically no knowledge of XML conversion.
I must say that using the key as an attribute surprised me when I first saw it, but it's not so bad.
I want to be able to filter through these files with XPath, mostly, and after playing with a few of the alternatives on the table, it seems like your original format is the best, if you want to have a uniform structure that conforms to a generic DTD.
Something that would simplify XPath/XSLT processing in certain cases is having a direct output of keys into elements:
<akey> <anotherkey>0</anotherkey> <subdirectory> <bkey>3 5 6</bkey> </subdirectory> </akey>
...but I can see how this would descend into chaos pretty quickly if you wanted to be generic.
So my vote is for your description as shown below.
<pool> <value key="1">60</value> <value key="2">51</value> <dir key="bla"> <value key="2">66</value> <value key="1">44</value> </dir> </pool>
Hallo, Adam Lindsay hat gesagt: // Adam Lindsay wrote:
So my vote is for your description as shown below.
<pool> <value key="1">60</value> <value key="2">51</value> <dir key="bla"> <value key="2">66</value> <value key="1">44</value> </dir> </pool>
Actually, in case it wasn't clear: I do prefer keys as attributes, too. It's feels quite natural and analogous to html-things like: <img src="some.jpg">, <a name="the_top"> or even clearer: <div id="news">
ciao
Frank Barknecht _ ______footils.org__
Hey all, actually, after reading the web a bit, i tend to prefer the following format...
<pool> <value><key>1</key><data>60</data></value> <value><key>2</key><data>51</data></value> <dir> <key>bla</key> <value><key>2</key><data>66</data></value> <value><key>1</key></value> </dir> </pool>
<key> is mandatory, but <data> is not.
The main reason is that a key can be any PD atom (except symbols with spaces) in pool, and XML attributes must not contain certain characters (like ' or " , probably others). The format looks a bit more general and robust to me than the one with the attributes. It also _looks_ more transformation-friendly....
greetings, Thomas
So my vote is for your description as shown below.
<pool> <value key="1">60</value> <value key="2">51</value> <dir key="bla"> <value key="2">66</value> <value key="1">44</value> </dir> </pool>
--
Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Thomas Grill said this at Mon, 1 Dec 2003 17:31:37 +0100:
The main reason is that a key can be any PD atom (except symbols with spaces) in pool, and XML attributes must not contain certain characters (like ' or " , probably others). The format looks a bit more general and robust to me than the one with the attributes. It also _looks_ more transformation-friendly....
It isn't, really. I was hoping to steer you away from this because it resembles Apple's property-list format, and that's a bit of a pain to deal with. However, the fact that you enclose keys and values within a parent value or dir element makes things a lot easier than Apple's format. I'm not sure I'd call it transformation-friendly, but it allows for XPath expressions like this:
//dir[key='bla']/value[key='2']/data (Give me the data for the key #2 that's in any directory with the key bla.)
The interesting aspect of this format is that it allows you to reverse the lookup with minimal effort: //value[data='51']/key (Give me the key for all data values that equal 51.)
Who knows if that functionality is actually useful for us, though...
Yeah, looks good! I can deal with it, and it does seem more sensible than putting the keys in attributes.
adam
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Hallo, Adam Lindsay hat gesagt: // Adam Lindsay wrote:
It isn't, really. I was hoping to steer you away from this because it resembles Apple's property-list format, and that's a bit of a pain to deal with. However, the fact that you enclose keys and values within a parent value or dir element makes things a lot easier than Apple's format. I'm not sure I'd call it transformation-friendly,
If it's xml, it is transformation friendly by definition, isn't it?
but it allows for XPath expressions like this:
//dir[key='bla']/value[key='2']/data (Give me the data for the key #2 that's in any directory with the key bla.)
The interesting aspect of this format is that it allows you to reverse the lookup with minimal effort: //value[data='51']/key (Give me the key for all data values that equal 51.)
Who knows if that functionality is actually useful for us, though...
Interesting. I didn't think of that, yet.
ciao
Frank Barknecht _ ______footils.org__
On 1 Dec 2003, at 17:14, Adam Lindsay wrote:
Who knows if that functionality is actually useful for us, though...
I have for a while tried to find ways to play with Cocoon (http://cocoon.apache.org) and PD. Other than a couple of obscure things I'm up to, being able to use XPath for key queries would help us in using Cocoon to document PD, or it could. Say, with Forrest for example. The parent child format for this would indeed be easier for XSLT transformations...
D
Hi, i updated the pool source to cover consistent XML saving and loading. Get it from the pd cvs after tomorrow morning CET. At the moment loading a directory, e.g.
<dir> <key>mydir</key> <value><key>a</key><data>hula</data></value> </dir> relies on the key being defined prior to the value items. That doesn't seem to be good practice, but it's no problem when the XML files are written by pool only. Apart from that the parser is not very robust - e.g. can't handle XML comments. Please check the format and the loading/saving consistency.
best greetings, Thomas
Dear Thomas,
Being a great fan of py/pyext, I recently tried to use dyn~ in combination. It turned out that I did not read carefully your webpages...
I received a "Fatal Python error: PyThreadState_Get: no current thread" as a response :-/
But just to be really sure, is it so that dyn~ does only accept the dynamic creation of standard Pd objects and not the one of complex objets like the ones created with py/pyext?
If yes, do you see any chances in the futur that this might happen?
In fact I would really like to use py/pyext to drive dyn~ to build pd objects containing py/pyext objects...
cordially, vincent
Hi Vincent,
I received a "Fatal Python error: PyThreadState_Get: no current thread" as a response :-/
But just to be really sure, is it so that dyn~ does only accept the
dynamic
creation of standard Pd objects and not the one of complex objets like the ones created with py/pyext?
No, that should be treated just the same. I think the problem might be more within py/pyext which suffers from some weaknesses when multiple py/pyext objects are created. I'll look into it shortly!
best greetings, Thomas
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
could one XML expert give me a hand and have a look at the following XML structure?
If you're at it I actually have a small feature wish for pool: Could you implement a kind of dump message that prints a pool's content to the console somehow? This would make testing so much easier...
Not really that important, but maybe a good idea.
ciao
Frank Barknecht _ ______footils.org__
I'll let Frank tout the benefits of pool...
But as for my current situation, it uses arrays of numbers and ... er, textfile, I think, to store the values. In each patch that I create (that is the master patch, not the abstraction) there is some sort of control subpatch. Every time an abstraction is loaded it queries the master subpatch for a settings file based on the abstraction's parameters. The master subpatch then looks for that file in the path of the patch.
Likewise when an abstraction saves it sends its data to the master subpatch, who then saves that data in a file in the patch of the parent patch.
I've got these in my mccallum_abstractions in the downloads section of http://mentalfloss.ca/sintheta. But it's unbelievably needlessly complicated... Nontheless, it works. Still waiting to give it an overhaul with pool, though...
David . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
Josh Steiner wrote:
incidentally i am also pretty deep in the process of building a modular sequencer that saves the state of all the objects in a song using [maphash] which suffers from the same "saves the textfile releatve to the pd dir, not the patch dir" problem. how can you share a little more detail on how your solved this issue? also, what advantages does the [pool] object have over [maphash]?
-josh
Hallo, David NG McCallum hat gesagt: // David NG McCallum wrote:
But as for my current situation, it uses arrays of numbers and ... er, textfile, I think, to store the values. In each patch that I create (that is the master patch, not the abstraction) there is some sort of control subpatch. Every time an abstraction is loaded it queries the master subpatch for a settings file based on the abstraction's parameters. The master subpatch then looks for that file in the path of the patch.
Likewise when an abstraction saves it sends its data to the master subpatch, who then saves that data in a file in the patch of the parent patch.
Regardless of how saving is done technically: What are your and other's requirements in state saving in the light of abstractions?
I think, that a persistable abstraction needs to provide hooks to change its own state, but it also needs to make its state local, so as not to change the state of another instance of the same abstraction.
I guess this all is a typical case for the Memento design pattern. Interestingly while looking for an URL to explain the Memento pattern to those without the Gang of Four book, I found this page:
http://www.agcs.com/supportv2/techpapers/patterns/papers/tutnotes/sld025.htm
where Memento is explained at saving the state of an audio mixer!!
ciao
Frank Barknecht _ ______footils.org__
Frank,
Each abstraction I create works with ID numbers. So if I want to plop down a mixer strip I'll assign it a number and those numbers are used to identify which filenames to use to store/retrieve values.
If this is all done with Pool (in one settings file or several) the same idea could be applied.
My requirements for state saving are... that the settings files be saved in the path of the parent patch. I don't know if midi channel and CC need to be taken into account with state saving, because that can be taken care of in the argument level of the abstraction...
That's all I can think of at the moment...
David . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
Frank Barknecht wrote:
Hallo, Regardless of how saving is done technically: What are your and other's requirements in state saving in the light of abstractions?
I think, that a persistable abstraction needs to provide hooks to change its own state, but it also needs to make its state local, so as not to change the state of another instance of the same abstraction.
I guess this all is a typical case for the Memento design pattern. Interestingly while looking for an URL to explain the Memento pattern to those without the Gang of Four book, I found this page:
http://www.agcs.com/supportv2/techpapers/patterns/papers/tutnotes/sld025.htm
where Memento is explained at saving the state of an audio mixer!!
ciao
Hallo, David NG McCallum hat gesagt: // David NG McCallum wrote:
My requirements for state saving are... that the settings files be saved in the path of the parent patch.
But this is not a requirement of state saving as a concept, or is it to you?
I don't know if midi channel and CC need to be taken into account with state saving, because that can be taken care of in the argument level of the abstraction...
I think everything, that an abstraction author wants to restore later should be possible to save, but that highly depends on the particular patch.
But midi assignments must be configurable to different gear. Actually I think, that no rradical abstraction should use midi directly, there should instead be a central midi in patch, that can route midi data to certain locations.
ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, David NG McCallum hat gesagt: // David NG McCallum wrote:
My requirements for state saving are... that the settings files be saved in the path of the parent patch.
But this is not a requirement of state saving as a concept, or is it to you?
i think it is if you want to make state information easily portable between computers. if the state text files get saved in the same folder as the rest of the project you are working on it would be trivial to just zip that whole folder and email it to a friend... having the state files stored centrally is a pain.
-josh
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
Frank Barknecht wrote:
Hallo, David NG McCallum hat gesagt: // David NG McCallum wrote:
My requirements for state saving are... that the settings files be saved in the path of the parent patch.
But this is not a requirement of state saving as a concept, or is it to you?
i think it is if you want to make state information easily portable between computers. if the state text files get saved in the same folder as the rest of the project you are working on it would be trivial to just zip that whole folder and email it to a friend... having the state files stored centrally is a pain.
No, I'm not talking about saving all states it centrally, but saving all states of one patch in a single file, and that file *could* still be in the working directory, but it wouldn't *have* to be. (Motivation: I use the same patch for different pieces. I can just keep my state files somewhere I like and I am not obliged to put them in the patch directory, which might even be write proteced, btw.)
ciao
Frank Barknecht _ ______footils.org__
Actually, I'd also come to the same idea of using Pool to cover my state saving. The only problem was that Pool saved in a path relative to the Pd dir and I needed it to save relative to the patch dir, but I think that's being changed.
Hi, actually, i never thought of relative paths, but i'm going to correct the behaviour as suggested.
best greetings, Thomas
-
Adam Lindsay -
B. Bogart -
benīŧ ekran.org
-
Chris McCormick -
David Casal -
David NG McCallum -
e skogen -
florian grassl -
Frank Barknecht -
Josh Steiner -
Thomas Grill -
Tim Blechmann -
Vincent Rioux