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.)
Thanks very much for your ideas,
Trevor
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?
This is something I have been wondering about lately as well. There seem to be plenty of unwritten rules, but little actual documentation. I think it would behoove the project to set down some guidelines and also supplemental information. For example, "No hard tabs in sourcefiles -- only spaces. Tab depth is two spaces, or one space for curly braces when they are alone on a line." followed by "Here is how you stop emacs from using hard tabs in sourcefiles, and here is how you set the indentation style to be consistent with our own. Here is how you set the same items up in JEdit and here is how you do it in vi."
I would be willing to do much of the legwork on this. I have spring break coming up this Friday so I have about a week of spare time to spend on boring detail-oriented assignments such as this. I have spent quite a lot of time looking at the source for Pd and related externals, so my familiarity with the code is well-developed enough that I think I may be able to do a decent job.
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?
Again, more guidelines are needed. As for the extent, I would
suggest that anyone contributing code should comment anything they think wouldn't be obvious to an intermediate-level programmer, and also provide decriptive documentation and usage info in a comment in the head of the main source file(s). Perhaps we should adopt something like Doxygen for this stuff?
If anyone thinks I am being a snotty kid, or this has already been
done and I am too lame to realize it, feel free to smack me down.
I am going to cross-post this to PD-Dev, where I think it is more on topic.
-John Lamb
<snip John lamb's reply>
Perhaps i misunderstood Trevor completly John, but how i read his question it seemed about how to program *within* pure data, not for the pd source code as you are suggesting.
If i am mistaken, then id like to pose that question anyway, how to program well and organized using Pure Data. ...
Cheers Anton
Anton Woldhek wrote:
<snip John lamb's reply>
Perhaps i misunderstood Trevor completly John, but how i read his question it seemed about how to program *within* pure data, not for the pd source code as you are suggesting.
Thus my disclaimer that I should be smacked down if I sound stupid.
:-D I suppose I should read my e-mails before replying to them. In any
case, I still think the code needs better comments. ;)
-John
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__
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@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Patrick Pagano hat gesagt: // Patrick Pagano wrote:
But then the question for me is What about when you know what you want to do but can't patch it yet?
Learn, learn, learn.... ;)
Anecdote: When I discovered Pd about 3 or 4 years ago, I felt at home soon, but I also realized, that it would take *years* to get familiar with it to the degree I would like to be familiar with it. I gave myself a span of 4 years in which I would not even try to do any real music with Pd but instead just invest time to learn it. I thought, 4 years would be a good span, because that's about as long as studying something at university takes here.
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?
This is a cool project, and actually not that far away from what RRADical should achieve, but in RRADical, I'd like to patch the bricks, from which something like Improsculpt can be built with ease. At least this is the phiosophy behind it, but give me another half year (or at least some months) to make this actually happen.
ciao
Frank Barknecht _ ______footils.org__
On Fri, 5 Mar 2004, Frank Barknecht wrote:
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.
A more Extreme Programming way of dealing with creating patches would be like:
prototype as you go, the way you feel it, making sure you have add something useful AND working, and make sure your code doesn't stop working for extended periods of time
when you get enough experience with the problem that you now have an idea about how to make a part of your patch cleaner, _do it_.
especially, any kind of duplication of effort and copypaste programming should be destroyed right after it's created, and replaced by something cleaner.
when you make an abstraction, also provide a patch that can automatically test it and report whether it works. create the testing patch before the actual abstraction (!). Whenever there is a bug, add something to the testing patch to test for that bug, and only then fix the bug so that the testing patch stops complaining. Use your testing patches as your bug database as much as possible.
Mathieu Bouchard http://artengine.ca/matju
(The following advice is my personal opinion on patch design for musicians. It does not necessarily reflect my opinion on programming in general, or the views of my sponsers. Use only as directed. Keep out of reach of children. For external use only)
It may seem obvious, but to handle a large project, you must think of it as a combination of many small projects. Seperate the functionality into many small pieces. Learn from the examples provided with Pd and what other people have already done (usually better than you). Then find a way to make the pieces you have work the way you want.
By seperating the pieces (and making use of subpatches and abstractions) and giving them space, your patch will be better organized and easier to modify. You don't have to go nuts and make everything modular "just because you can" if you're not going to use it. You can always add options later. Stick to what you need to make your vision a success.
For big projects. figure out what you are interested in, what you want to accomplish, and why you need to do it a certain way. Then make a plan and stick with it as best you can. Noodling around without an objective is not experimenting, it's just wasting your valuable time. Experimenters form a hypothosis, then test their theory. You music will be better if you have an idea first, and then an implementation. You can do anything you want in Pd so now what will you do?
e
was walking along the web and found this doc: ftp://arts.ucsc.edu/pub/ems/MaxTutors/Max&Problems.pdf
just thought it could be usefull..
Friday, March 5, 2004, 2:50:17 AM, you wrote:
TA> Has anyone seen rules-of-thumb for "good PD programming practice" (in TA> the same way "Extreme Programming" has advice for good C++ writing?) Or TA> does anyone have strong opinions on the topic?
TA> e.g. are abstractions preferable to subpatches, or is there a time and TA> place for each? Is there a recommended limit to objects in any canvas, TA> for clarity's sake? Any recommendation on the extent and style of TA> commenting?
TA> My aim is to have some "house rules" so a number of us can work on the TA> same large-scale patch with maximum clarity and minimum confusion. TA> (Also, it's part of an assignment, so we need to do things as "by the TA> book" as possible.)
TA> Thanks very much for your ideas,
TA> Trevor
TA> _______________________________________________ TA> PD-list mailing list TA> PD-list@iem.at TA> http://iem.at/cgi-bin/mailman/listinfo/pd-list
-
Anton Woldhek -
Eric Skogen -
Frank Barknecht -
John Lamb -
Mathieu Bouchard -
Patrick Pagano -
Trevor Agus -
Yury