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.
.hc
"The arc of history bends towards justice."
Dr.
Martin Luther King, Jr.
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:
[value]
send/receive
array/table
practically is a no go for shared patches, 2) and 3) should always
start with $0
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: fqdn _ http://footils.org/cms/show/38
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 example.
Cheers, Ian
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:
[value]
send/receive
array/table
practically is a no go for shared patches, 2) and 3) should always
start with $0
Ciao
-
Frank Barknecht -
Hans-Christoph Steiner -
Ian Smith-Heisters