[PD] Idiomatic Pd

[Matt Barber]

> Date: Tue, 29 Jul 2008 10:02:05 -0400
> From: marius schebella <marius.schebella at gmail.com>
> Subject: Re: [PD] Idiomatic Pd
> To: pd-list at iem.at
> Message-ID: <488F22DD.6060505 at 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