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