[PD] Announcing 'RRADical Pd'

[ben at ekran.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 at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-list