[PD] Good PD programming practice?

[Patrick Pagano]

This is such great advice and it's apprent in your patches frank and in 
the sounds i have heard from Kim
-i totally dug HMC back in the day.

But then the question for me is
What about when you know what you want to do but can't patch it yet?
I have been agonising over trying to go fully into one OS (OS X )
and i know we have disagreed on this before but what i woudl like to do 
is port

Improsculpt to pd
This is by far the coolest csound instrument(GUI) in recent years
http://www.teks.no/oeyvind/frames/Index.htm

it rules. it can grab up to 14 5 second loops into buffer
then it has a network of EFX and granular functions
as well as a BAss Synth that reacts to the input etc..
It is Quite marvelous but csound on OSX does not quite support FLTK 
opcodes

So i was wondering woul danyone be willing in this project as well?



On Thursday, March 4, 2004, at 06:24 PM, Frank Barknecht wrote:

> Hallo,
> Trevor Agus hat gesagt: // Trevor Agus wrote:
>
>> Has anyone seen rules-of-thumb for "good PD programming practice" (in
>> the same way "Extreme Programming" has advice for good C++ writing?) 
>> Or
>> does anyone have strong opinions on the topic?
>>
>> e.g. are abstractions preferable to subpatches, or is there a time and
>> place for each? Is there a recommended limit to objects in any canvas,
>> for clarity's sake? Any recommendation on the extent and style of
>> commenting?
>>
>> My aim is to have some "house rules" so a number of us can work on the
>> same large-scale patch with maximum clarity and minimum confusion.
>> (Also, it's part of an assignment, so we need to do things as "by the
>> book" as possible.)
>
> This is a very interesting bag of questions, and you surely will not
> get final answers shared by everyone on this, as Pd is so open and
> free-form, that there will never be a common ground among all users
> for it, and there also are so many different useages of Pd.
>
> This isn't a bad thing at all.
>
> Still, thinking about these issues IMO is an essential part of working
> with Pd. I only came to realize this after 3 or 4 years of Pd usage.
> It will help a lot to read as much as possible about design questions
> in related areas. By this I mean for example design methods in
> software development, like the object oriented approach, and also some
> GUI guidelines like the Apple interface guidelines. This is really
> enlightening stuff.
>
> The concrete example questions you asked are actually minor issues in
> that context. Like: abstractions and subpatches are totally different
> things that have a very different semantics inside patches.
> Subpatches have no real meaning (at least not much) besides making
> room inside a patch, wheras abstractions are a statement made by the
> developer saying: "This is standalone functionality. I might use this
> again later, and you are encouraged to do so as well." Also what is
> clarity is more a matter of taste and personal preferences.
>
> A thing, that really *is* important is for example how you design the
> communcation paths insider your patch. When do you use a simple
> send/receive, and when do you use a network transparent OSC
> connection? Which parts of your patch should talk to or even know
> about which other parts? How many things do you want to control as a
> patch user, which things are better controlled by some random
> automatic function? And might this change later?
>
> Those are questions, that really force you to make the interesting
> decisons.
>
> So, maybe the "non-Extreme Programming" advice I would give is: "Sit
> down and think, before you patch." Actually I got this advice once
> from Kim Cascone, who said it in a slightly other way like: "Make a
> detailed plan before you develop something and by all means: Stick to
> it!" The last part is the hard part.
>
> I might add, that personally I still cannot follow this rule, but I'm
> working on it. ;)
>
> ciao
> -- 
>  Frank Barknecht                               _ ______footils.org__
>
> _______________________________________________
> PD-list mailing list
> PD-list at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>