[PD] poll: common problems when sharing performance patches

Ian Smith-Heisters heisters at 0x09.com
Sun Feb 27 00:02:06 CET 2005

The other thing I find handy is to clearly mark sends and receives with 
a 1x20 red canvas on their left edge, and keep them no more than 1 or 
two subpatch levels down. I think my usual structure, since I'm doing 
lots of GOP is something like this:

TOP: Controls, no patchcords, all send/receives prefixed with 
$0-s_ctrl_/$0-r_ctrl_ respectively. Top level contains only in/outlets, 
GUI controls, and a subpatch called [pd guts]

PD_GUTS: lots of subpatches going to different modules of the 
abstraction. If it's a very simple abstraction, the workings go here. 
Try to avoid sending/receiving between patches here: use cords instead.

WORKINGS: In subpatches in guts. Here's where the controls from TOP are 
caught and put into action. No sends or receives deeper than this.

I'm not sure that makes any sense. If it doesn't, LMK and I'll post an 


Frank Barknecht wrote:
> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>>For the next phase of my [hid] toolkit project, I want to focus on 
>>addressing issues that make it difficult to share performance patches 
>>made with it.   RRADical is a very good example of what I am trying to 
>>accomplish with the HID side of things.So I thought I'd start with an 
>>informal poll of common problems people have when trying to use someone 
>>else's performance patch.  The most obvious one that I can think of 
>>right now would be getting the correct objects and libraries, and then 
>>there are the name conflicts.  These are things that are being 
>>addressed, albeit slowly. 
>>I am particularly interested in patching styles, object functionality, 
>>etc. that makes sharing performance patches easier or harder.  
> I think, this might not necessarily have to be restricted to
> "performance" patches. Actually my performance patches are almost
> unsharable, as the are quite specific to my laptop. I even sometimes
> struggle with moving them to my stationary machine, but this isn't
> that important to me. 
> However patches that are intended to be shared need to adhere to
> certain rules, be it performance patches or other patches. The most
> imporant rule IMO is to avoid global names as much as possible. Names
> that immediatly come to my mind are: 
>   1) [value]
>   2) send/receive 
>   3) array/table 
> 1) practically is a no go for shared patches, 2) and 3) should always
> start with $0
> Ciao

More information about the Pd-list mailing list