[PD] Idiomatic Pd

[marius schebella]

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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>