New subject: Idiomatic Pd

29 Jul 2008 · *maybe*


      ...
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

Re: [PD] Idiomatic Pd

Ciao