I am quite pedantic in regard to spacing and aligning of objects. I started to space all objects using ctrl+arrow keys. that way all objects are spaced like on a grid and always a multiple of 10px away of each other. I don't know if that should go into a style guide, but for "official" patches like tutorials it could be considered. It is almost not possible for me to look at the montreal abstractions... I also want to point out the importance of good grouping. sometimes I use bg canvases to underline that certain objects belong together (do some transformation or algorithm). If I work on big patches that run as installations (no interface) the parent patch is basically empty, it only shows piece information and credits, everything is in a subpatch called [MACHINE]. and that usually is more a visual representation of the space (according to positioning of sensors/speakers) or a basic overview of the patch structure with an short explanation of what the different subpatches are doing. even, if everybody says, pd patches are their own documentation, because everything is visible, that's not true, commenting should be an important part of patching (cyclone's comment allow differnt fonts, sizes, colors and width of comments).
some things are important for patches that should be portable. please mention, which libraries are used, and consider to use declare to load the objects. do not store patches with position <0/0. some window managers will not allow to drag the patch window around. (oh, and please don't place objects outside the canvas and esp. not <0/0, having to scroll to the left to see the beginning of a patch can cause heart attack). and not all people have widescreen monitors or hi-res monitors, so I think 1024 should be the maximum width of a patch.
then, for patches that rely on abstractions, *maybe* it would be good to give them either unique names or put them into subfolders. (I have to say, I do not really stick with this rule. but at least one thing: the main patch should always be recognizable, I usually put it in capital letters, so that people know, which patch to start.
resources (images, textfiles, data) could be kept in a subfolder, too. (just think of the GEM examples, how often one of the images or videos can not be found. - at least in the past).
I don't care about send and receive naming conventions( - _ / camelCase), as long as they are unique ($0).
more later. marius.
Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
The only one I have seen so far for Pd covers best practices for layout. I'd want to include that, but also codify naming, arguments, common idioms, and so on.
I've begun to collect some of my practices to start things off. I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always first in
the argument list [1]
- When possible, pass parent arguments in numeric order, like [child
$0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Programming recommendations
- To invert a toggle, use [== 0]
- Use the loadbang of the parent of both abstractions to initialize
two or more interdependent abstractions
[1] I think of this like emulating the "self" convention in Python
And so on... Cheers Luke
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list