Date: Tue, 29 Jul 2008 10:02:05 -0400 From: marius schebella marius.schebella@gmail.com Subject: Re: [PD] Idiomatic Pd To: pd-list@iem.at Message-ID: 488F22DD.6060505@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
Yes, I am this way too -- but with font sizes sometimes being different from one platform to the next, and even between extended and vanilla, it's really hard to ensure that things will line up sweetly every time you open it, everywhere.
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).
This is a good point. In fact, for some patches e.g. for interactive pieces to be sent to musicians who don't do Pd for a living -- =o) -- I prefer to put everything in a subpatch which has a GOP control surface. I think it's productive to petition against the "spider web" style, but even too many objects and connections on the main patch seems wasteful somehow. It's nice to include a subpatch which can be opened with a bng, that is basically a readme. I do this for abstractions, too, but without the bng -- just something to describe how it works inside the patch itself, I suppose as a quick substitute for a help file.
Most of this is really personal, though, and I don't think it should be codified.
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).
Abstractions, whenever possible I think, should try not to conflict with names in extended, even when the patch is designed for vanilla. Also, I think it's helpful to include tilde in abstraction names when audio signals are involved.
When 0.39 begins to wane (so [declare] can be used), it might be productive to keep abstractions in subfolders, and possibly control in one and tilde in another. Same, as you suggest, with textfiles, qlists, images, and soundfiles. This way the main patch is there cleanly for anyone who might need to use the patch besides you, and especially nice for musicians.
Again, not essential, but ergonomic.
Matt