There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
The only one I have seen so far for Pd covers best practices for layout. I'd want to include that, but also codify naming, arguments, common idioms, and so on.
I've begun to collect some of my practices to start things off. I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always first in
the argument list [1]
- When possible, pass parent arguments in numeric order, like [child
$0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Programming recommendations
- To invert a toggle, use [== 0]
- Use the loadbang of the parent of both abstractions to initialize
two or more interdependent abstractions
[1] I think of this like emulating the "self" convention in Python
And so on... Cheers Luke
Hi Luke..
I think that is very useful....
even better would it be to have that in a PD-Patch ;-)
so it is 100% clear what is meant and maybe easier to read...
Bye
Luigi
Am 28.07.2008 um 03:34 schrieb Luke Iannini:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
The only one I have seen so far for Pd covers best practices for layout. I'd want to include that, but also codify naming, arguments, common idioms, and so on.
I've begun to collect some of my practices to start things off. I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always first in
the argument list [1]
- When possible, pass parent arguments in numeric order, like [child
$0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Programming recommendations
- To invert a toggle, use [== 0]
- Use the loadbang of the parent of both abstractions to initialize
two or more interdependent abstractions
[1] I think of this like emulating the "self" convention in Python
And so on... Cheers Luke
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
---------------------------------------<
Luigi Rensinghoff luigi.rensinghoff@freenet.de skype:gigischinke ichat:gigicarlo
I think a style guide is a great idea. There have been some
discussions along these lines in the past. I'd say just start a
"wiki folder" on puredata.info in the /docs/ section and edit it up.
Something like /docs/style-guide/ I think that the main page could
lay out all of the possible realms of style, like dollar arguments,
abstractions, subpatches, inlets/outlets, trigger, etc. Then the
next step people can create sub-pages that outline all of their
styles. Then ultimately, things would be organized into a single
style-guide.
.hc
On Jul 27, 2008, at 9:34 PM, Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
The only one I have seen so far for Pd covers best practices for layout. I'd want to include that, but also codify naming, arguments, common idioms, and so on.
I've begun to collect some of my practices to start things off. I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always first in
the argument list [1]
- When possible, pass parent arguments in numeric order, like [child
$0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Programming recommendations
- To invert a toggle, use [== 0]
- Use the loadbang of the parent of both abstractions to initialize
two or more interdependent abstractions
[1] I think of this like emulating the "self" convention in Python
And so on... Cheers Luke
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
On Mon, Jul 28, 2008 at 1:39 PM, Hans-Christoph Steiner hans@eds.org wrote:
I think a style guide is a great idea. There have been some discussions along these lines in the past. I'd say just start a "wiki folder" on puredata.info in the /docs/ section and edit it up. Something like /docs/style-guide/ I think that the main page could lay out all of the possible realms of style, like dollar arguments, abstractions, subpatches, inlets/outlets, trigger, etc. Then the next step people can create sub-pages that outline all of their styles. Then ultimately, things would be organized into a single style-guide.
Okay, here it is: http://puredata.info/docs/style-guide
.hc
On Jul 27, 2008, at 9:34 PM, Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
The only one I have seen so far for Pd covers best practices for layout. I'd want to include that, but also codify naming, arguments, common idioms, and so on.
I've begun to collect some of my practices to start things off. I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always first in
the argument list [1]
- When possible, pass parent arguments in numeric order, like [child
$0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Programming recommendations
- To invert a toggle, use [== 0]
- Use the loadbang of the parent of both abstractions to initialize
two or more interdependent abstractions
[1] I think of this like emulating the "self" convention in Python
And so on... Cheers Luke
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Can I suggest using the MoinMoin wiki syntax? IMHO the python wikis
all have weak syntax compared to MediaWiki, but MoinMoin is the
closest to MediaWiki, which is a widely used and relatively easy to
use syntax. It is also what is used in most of the rest of the
'docs' section. To use MoinMoin, the page has to be a "wiki page". A
regular Plone "page" doesn't allow it for some reason.
Also, to make an index page for that folder, create a page called
"FrontPage" or "index_html" IIRC. I think that would be a good place
to lay out all of the things that are relevant to the style guide,
like a survey of programming elements. Then people can make their
own style pages for things that are a matter of opinion. And
hopefully at the end, we can come up with something unified.
.hc
On Jul 29, 2008, at 2:30 AM, Luke Iannini wrote:
Okay, here it is: http://puredata.info/docs/style-guide
On Mon, Jul 28, 2008 at 1:39 PM, Hans-Christoph Steiner
hans@eds.org wrote:I think a style guide is a great idea. There have been some discussions along these lines in the past. I'd say just start a "wiki folder" on puredata.info in the /docs/ section and edit it up. Something like /docs/style-guide/ I think that the main page could lay out all of the possible realms of style, like dollar arguments, abstractions, subpatches, inlets/outlets, trigger, etc. Then the next step people can create sub-pages that outline all of their styles. Then ultimately, things would be organized into a single style-guide.
.hc
On Jul 27, 2008, at 9:34 PM, Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized
approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/The only one I have seen so far for Pd covers best practices for layout. I'd want to include that, but also codify naming,
arguments, common idioms, and so on.I've begun to collect some of my practices to start things off.
I was hoping we could all lazy-vote the document together in this
thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.Style:
- If giving $0 as an argument to an abstraction, it is always
first in the argument list [1]
- When possible, pass parent arguments in numeric order, like
[child $0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Programming recommendations
- To invert a toggle, use [== 0]
- Use the loadbang of the parent of both abstractions to initialize
two or more interdependent abstractions
[1] I think of this like emulating the "self" convention in Python
And so on... Cheers Luke
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
Sorry all for my silence!! I've been deadly busy this week and it looks like it will continue for another few days. But, rest assured, my obsession cannot be squashed and we'll need plenty of criticism to make a useful guide, so fire away :).
Everyone's suggestions are wonderful so far. I'm so glad to have you all contributing. I'm going to start by organizing this thread by categories (as soon as I get the wikipage issue figured out, below), and then it should be pretty clear which are most chaotic (in a good way) and which need more input.
On Tue, Jul 29, 2008 at 10:35 AM, Hans-Christoph Steiner hans@eds.org wrote:
Can I suggest using the MoinMoin wiki syntax? IMHO the python wikis all have weak syntax compared to MediaWiki, but MoinMoin is the closest to MediaWiki, which is a widely used and relatively easy to use syntax. It is also what is used in most of the rest of the 'docs' section. To use MoinMoin, the page has to be a "wiki page". A regular Plone "page" doesn't allow it for some reason.
Hey, I am getting: Site error This site encountered an error trying to fulfill your request. The errors were:
Error Type BadRequest Error Value The id "outline" is reserved. Request made at 2008/08/03 10:45:39.063 GMT+2
when I try to add a wiki page to the Style Guide folder. Could you or IOhannes try, maybe?
Best Luke
Also, to make an index page for that folder, create a page called "FrontPage" or "index_html" IIRC. I think that would be a good place to lay out all of the things that are relevant to the style guide, like a survey of programming elements. Then people can make their own style pages for things that are a matter of opinion. And hopefully at the end, we can come up with something unified.
.hc
On Jul 29, 2008, at 2:30 AM, Luke Iannini wrote:
Okay, here it is: http://puredata.info/docs/style-guide
On Mon, Jul 28, 2008 at 1:39 PM, Hans-Christoph Steiner hans@eds.org wrote:
I think a style guide is a great idea. There have been some discussions along these lines in the past. I'd say just start a "wiki folder" on puredata.info in the /docs/ section and edit it up. Something like /docs/style-guide/ I think that the main page could lay out all of the possible realms of style, like dollar arguments, abstractions, subpatches, inlets/outlets, trigger, etc. Then the next step people can create sub-pages that outline all of their styles. Then ultimately, things would be organized into a single style-guide.
.hc
On Jul 27, 2008, at 9:34 PM, Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
The only one I have seen so far for Pd covers best practices for layout. I'd want to include that, but also codify naming, arguments, common idioms, and so on.
I've begun to collect some of my practices to start things off. I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always
first in the argument list [1]
- When possible, pass parent arguments in numeric order, like
[child $0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Programming recommendations
- To invert a toggle, use [== 0]
- Use the loadbang of the parent of both abstractions to initialize
two or more interdependent abstractions
[1] I think of this like emulating the "self" convention in Python
And so on... Cheers Luke
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, Aug 3, 2008 at 2:03 AM, Luke Iannini lukexipd@gmail.com wrote:
Sorry all for my silence!! I've been deadly busy this week and it looks like it will continue for another few days. But, rest assured, my obsession cannot be squashed and we'll need plenty of criticism to make a useful guide, so fire away :).
Everyone's suggestions are wonderful so far. I'm so glad to have you all contributing. I'm going to start by organizing this thread by categories (as soon as I get the wikipage issue figured out, below), and then it should be pretty clear which are most chaotic (in a good way) and which need more input.
On Tue, Jul 29, 2008 at 10:35 AM, Hans-Christoph Steiner hans@eds.org wrote:
Can I suggest using the MoinMoin wiki syntax? IMHO the python wikis all have weak syntax compared to MediaWiki, but MoinMoin is the closest to MediaWiki, which is a widely used and relatively easy to use syntax. It is also what is used in most of the rest of the 'docs' section. To use MoinMoin, the page has to be a "wiki page". A regular Plone "page" doesn't allow it for some reason.
Hey, I am getting: Site error This site encountered an error trying to fulfill your request. The errors were:
Error Type BadRequest Error Value The id "outline" is reserved. Request made at 2008/08/03 10:45:39.063 GMT+2
when I try to add a wiki page to the Style Guide folder. Could you or IOhannes try, maybe?
I just discovered that you fixed it IOhannes, thanks very much! Back to work then. Cheers Luke
Best Luke
Also, to make an index page for that folder, create a page called "FrontPage" or "index_html" IIRC. I think that would be a good place to lay out all of the things that are relevant to the style guide, like a survey of programming elements. Then people can make their own style pages for things that are a matter of opinion. And hopefully at the end, we can come up with something unified.
.hc
On Jul 29, 2008, at 2:30 AM, Luke Iannini wrote:
Okay, here it is: http://puredata.info/docs/style-guide
On Mon, Jul 28, 2008 at 1:39 PM, Hans-Christoph Steiner hans@eds.org wrote:
I think a style guide is a great idea. There have been some discussions along these lines in the past. I'd say just start a "wiki folder" on puredata.info in the /docs/ section and edit it up. Something like /docs/style-guide/ I think that the main page could lay out all of the possible realms of style, like dollar arguments, abstractions, subpatches, inlets/outlets, trigger, etc. Then the next step people can create sub-pages that outline all of their styles. Then ultimately, things would be organized into a single style-guide.
.hc
On Jul 27, 2008, at 9:34 PM, Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
The only one I have seen so far for Pd covers best practices for layout. I'd want to include that, but also codify naming, arguments, common idioms, and so on.
I've begun to collect some of my practices to start things off. I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always
first in the argument list [1]
- When possible, pass parent arguments in numeric order, like
[child $0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Programming recommendations
- To invert a toggle, use [== 0]
- Use the loadbang of the parent of both abstractions to initialize
two or more interdependent abstractions
[1] I think of this like emulating the "self" convention in Python
And so on... Cheers Luke
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
when I try to add a wiki page to the Style Guide folder. Could you or IOhannes try, maybe?
i always thought i had already fixed this. hmm, obviously not....
I just discovered that you fixed it IOhannes, thanks very much! Back to work then.
ah sorry that i haven't told anyone. i forgot to find your original email to answer it. anyhow, good that you found out yourself...
fgmasdr IOhannes
On Sun, Jul 27, 2008 at 06:34:05PM -0700, Luke Iannini wrote:
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
Will this even work? I think sends and receives have to be named the same to work.
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
I like using a forward slash ("/") since this is forwards compatable with the day when OSC externals make it into Vanilla Pd. ;)
The other suggestions sound good to me.
Best,
Chris.
On Mon, Jul 28, 2008 at 7:49 PM, Chris McCormick chris@mccormick.cx wrote:
On Sun, Jul 27, 2008 at 06:34:05PM -0700, Luke Iannini wrote:
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
Will this even work? I think sends and receives have to be named the same to work.
Yo, sorry, just poor wording on my part. Usually when I make a GUI object, I give it $0mySlider as its sending target and $0mySliderR as its receiving target so I can choose to either route things through the slider (so it picks up the change to the parameter) or not, or, so I can send "set", "color" etc. messages to the slider without it going to the slider's destination.
I know at least Hard-off does the same in his DIY2 library (which is fantastic, by the way).
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
I like using a forward slash ("/") since this is forwards compatable with the day when OSC externals make it into Vanilla Pd. ;)
Aok by me.
Thanks all for your input so far. I'll make the wiki tonight. Regarding Hans' suggestion that people make their own style guides, that's certainly encouraged but I also don't mind if you are lazy and reply to the thread with input, I'll scrape it all together anyway.
Best Luke
Luke Iannini wrote:
On Mon, Jul 28, 2008 at 7:49 PM, Chris McCormick chris@mccormick.cx wrote:
On Sun, Jul 27, 2008 at 06:34:05PM -0700, Luke Iannini wrote:
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
Will this even work? I think sends and receives have to be named the same to work.
Yo, sorry, just poor wording on my part. Usually when I make a GUI object, I give it $0mySlider as its sending target and $0mySliderR as its receiving target so I can choose to either route things through the slider (so it picks up the change to the parameter) or not, or, so
Àhm, isn't this already built-into the iemgui objects? i mean, it will just pick up values without passing them on so that no feedback is generated, and if you actively use it (moving the slider) it will send out things.
I can send "set", "color" etc. messages to the slider without it going to the slider's destination.
right, the above mentioned built-in mechanism doesn't work so well with special messages like "color".
I know at least Hard-off does the same in his DIY2 library (which is fantastic, by the way).
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
I like using a forward slash ("/") since this is forwards compatable with the day when OSC externals make it into Vanilla Pd. ;)
Aok by me.
hmm, even though there surely _are_ uses for a combination of OSC and $0, i guess this is the least common field of application...
fmasdr IOhannes
On Tue, Jul 29, 2008 at 09:13:38AM +0200, IOhannes m zmoelnig wrote:
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
I like using a forward slash ("/") since this is forwards compatable with the day when OSC externals make it into Vanilla Pd. ;)
Aok by me.
hmm, even though there surely _are_ uses for a combination of OSC and $0, i guess this is the least common field of application...
Ah yes, you are probably right. In general though I find using '/' as a divider more satisfying than '.' or '-' or '_' because it is more consistent with the OSC way and with the whole libdir thing, although maybe that's more confusing than clear. Hmmm. I used to use '-', hence the names of s-abstractions.
Chris.
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
I think, it would be important to first collect every possible style element in the wild and document what people are using in reality. That would be interesting. I'm not too much in favour of a style "guide" however. Let people be creative.
I've begun to collect some of my practices to start things off.
I added where I do things different.
I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always first in
the argument list [1]
I often put it last (and it's specified to be that way e.g. in Memento)
- When possible, pass parent arguments in numeric order, like [child
$0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
I use the underscore style sometimes but often a simple "dash" style: "r some-thing" instead of camelCase. My reason: It doesn't need any Shift-key-combinations on German keyboards, and I find camelCase hard to read.
When I want to name matching send/receive pairs I use $0-some-s and $0-some-r.
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
I always seperate $0 with a $0-dash. $0myGod is easy to misunderstand.
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Nice idea. I never did that, though.
Ciao
Frank Barknecht _ ______footils.org__
Yo, On Mon, Jul 28, 2008 at 10:31 PM, Frank Barknecht fbar@footils.org wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
I think, it would be important to first collect every possible style element in the wild and document what people are using in reality. That would be interesting. I'm not too much in favour of a style "guide" however. Let people be creative.
Agreed! Regarding the guide, well, no one is going to be kicked out of the community or have their patches burned for not adhering to the styleguide : ). If you would like to be creative in your lettering you are as free as ever to do so.
But, I think many people (including myself) would rather be creative in the functionality rather than the syntax, and for people such as that, they might as well all do the same thing so they don't invent even more arbitrary ways when they didn't really care to do so.
I've begun to collect some of my practices to start things off.
I added where I do things different.
I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always first in
the argument list [1]
I often put it last (and it's specified to be that way e.g. in Memento)
My reasoning here is that $0 is probably the most common thing to pass to an abstraction, but abstractions have varying numbers of arguments, so $0 will sometimes be $3, sometimes $2, sometimes $7, and that swings my brain around. Putting it in the first slot means that $1 gains a sort of second meaning as "my parent's $0", which I think is handy.
And, the same memory-assistance applies to my numeric-ordering proposition as well; I usually remember how many arguments an abstraction has better than what order they're in, so when they're all taken from their parent I know it will be [mychild $0 $1 $2].
- When possible, pass parent arguments in numeric order, like [child
$0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
I use the underscore style sometimes but often a simple "dash" style: "r some-thing" instead of camelCase. My reason: It doesn't need any Shift-key-combinations on German keyboards, and I find camelCase hard to read.
When I want to name matching send/receive pairs I use $0-some-s and $0-some-r.
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
I always seperate $0 with a $0-dash. $0myGod is easy to misunderstand.
That's all cool, and I think you are in the majority on that. I think I just took camelCase because it reminded me of Smalltalk and Cocoa, which remind me of Pd : ).
Thanks for the comments Luke
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Nice idea. I never did that, though.
Ciao
Frank Barknecht _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
On Mon, Jul 28, 2008 at 10:31 PM, Frank Barknecht fbar@footils.org wrote:
Style:
- If giving $0 as an argument to an abstraction, it is always first in
the argument list [1]
I often put it last (and it's specified to be that way e.g. in Memento)
My reasoning here is that $0 is probably the most common thing to pass to an abstraction, but abstractions have varying numbers of arguments, so $0 will sometimes be $3, sometimes $2, sometimes $7, and that swings my brain around. Putting it in the first slot means that $1 gains a sort of second meaning as "my parent's $0", which I think is handy.
The reason, $0 is last in e.g. [originator] or [commun] was that this way I can pass $1 deeply without ever changing the number.
For example it's quite common to have something like this with memento
[synth /mysynth] [envelope $1/myenv $0] [attack $1/a $0]
Here the toplevel [synth] doesn't need to pass $0. Putting the name as second arg would make it look like this:
[synth /mysynth] [envelope $0 $1/myenv] [attack $0 $2/a]
and now suddenly it depends on how deep I am in the hierarchy if I should use $1 or $2. So generally with memento/sssad I reserve $1 to be the "tag" of an object or the "self" in other languages, but that tag generally doesn't refer to the parent's $0.
And, the same memory-assistance applies to my numeric-ordering proposition as well; I usually remember how many arguments an abstraction has better than what order they're in, so when they're all taken from their parent I know it will be [mychild $0 $1 $2].
Yeah, numeric ordering is fine, but putting $0 first means, that using $1 inside the abstraction is $0 from the parent, $2 inside the abstraction is the value called $1, $3 = $2 and so on. Putting $0 last lets you have $1 = $1, $2 = $2 and so on in abstraction trees/hierarchies like above.
That's all cool, and I think you are in the majority on that. I think I just took camelCase because it reminded me of Smalltalk and Cocoa, which remind me of Pd : ).
Yep, it's just two different styles. Probably the style guide shouldn't favour a single one but just recommend to not change the style in one project.
Btw. I tend to use ALL_UPPERCASE for globals.
Ciao
Frank Barknecht _ ______footils.org__
On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
I think, it would be important to first collect every possible style element in the wild and document what people are using in reality. That would be interesting. I'm not too much in favour of a style
"guide" however. Let people be creative.
Nobody is talking about requirements. If you don't like style
guides, don't use them. But it is really not useful to squelch other
people's efforts, especially when you don't even have an intention of
using this stuff.
I've begun to collect some of my practices to start things off.
I added where I do things different.
I was hoping we could all lazy-vote the document together in this thread
and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.Style:
- If giving $0 as an argument to an abstraction, it is always
first in the argument list [1]
I often put it last (and it's specified to be that way e.g. in Memento)
- When possible, pass parent arguments in numeric order, like
[child $0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
I use the underscore style sometimes but often a simple "dash" style: "r some-thing" instead of camelCase. My reason: It doesn't need any Shift-key-combinations on German keyboards, and I find camelCase hard to read.
When I want to name matching send/receive pairs I use $0-some-s and $0-some-r.
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
I always seperate $0 with a $0-dash. $0myGod is easy to misunderstand.
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Nice idea. I never did that, though.
I like the idea of standard labels, but I find unix-isms hard to
remember. Why not just use the whole word? Code is read far more
than it is written. It takes a trivial amount of time to type
'right' vs 'ri', it will take a lot longer for people to figure out
what "Ri" means if they don't know or have forgotten (like I
undoubted will).
.hc
Ciao
Frank Barknecht _
______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote:
I think, it would be important to first collect every possible style element in the wild and document what people are using in reality. That would be interesting. I'm not too much in favour of a style
"guide" however. Let people be creative.Nobody is talking about requirements. If you don't like style
guides, don't use them. But it is really not useful to squelch other
people's efforts, especially when you don't even have an intention of
using this stuff.
I really cannot see where you got the impression that I'm squelching Luke's suggestion, when I briefly expressed a certain personal scepticism regarding style guides in two sentences of currently three much longer mails in this thread, which I considered to be constructive, at least as brainstorming fodder or to give some motivations on how and why my personal style evolved the way it did.
Ciao
Frank Barknecht
On Jul 29, 2008, at 2:04 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote:
I think, it would be important to first collect every possible style element in the wild and document what people are using in reality. That would be interesting. I'm not too much in favour of a style "guide" however. Let people be creative.
Nobody is talking about requirements. If you don't like style guides, don't use them. But it is really not useful to squelch other people's efforts, especially when you don't even have an intention of using this stuff.
I really cannot see where you got the impression that I'm squelching Luke's suggestion, when I briefly expressed a certain personal scepticism regarding style guides in two sentences of currently three much longer mails in this thread, which I considered to be
constructive, at least as brainstorming fodder or to give some motivations on how
and why my personal style evolved the way it did.
From this sentence:
"I'm not too much in favour of a style "guide" however. Let people be
creative."
Maybe I overreacted. I think there is a lot of negative tone on this
list, I am sure I have contributed to that as well. I think we
should encourage people to try things more than telling them its
wrong before they have started.
Or maybe I'm just a fucking hippie... "peace 'n' love dude!"
.hc
Ciao
Frank Barknecht
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Hans-Christoph Steiner wrote:
On Jul 29, 2008, at 2:04 PM, Frank Barknecht wrote:
I really cannot see where you got the impression that I'm squelching Luke's suggestion, when I briefly expressed a certain personal scepticism regarding style guides in two sentences of currently three much longer mails in this thread, which I considered to be
constructive, at least as brainstorming fodder or to give some motivations on how
and why my personal style evolved the way it did.From this sentence:
"I'm not too much in favour of a style "guide" however. Let people be
creative."Maybe I overreacted. I think there is a lot of negative tone on this
list, I am sure I have contributed to that as well. I think we
should encourage people to try things more than telling them its
wrong before they have started.Or maybe I'm just a fucking hippie... "peace 'n' love dude!"
Although I am more or less just a lurker on this list, and sometimes an asker of stupid questions, not to mention a person with too messy patches, I find the idea of a style guide very good, and here is my reasoning:
As most of us Pd users think of Pd as a programming language, then Pd should have one or more style guides just as any other programming language, so other people's patches (read: source code) are easy to read to you. You do not need to have a definite style guide, just as there are several indent styles for functional programming languages, there may be several styles for Pd programming, but guidelines for newbies are a Good Thing (tm), as you can't teach an old dog new tricks.
Just my two cents, Thomas
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jul 29, 2008, at 2:04 PM, Frank Barknecht wrote:
I really cannot see where you got the impression that I'm squelching Luke's suggestion, when I briefly expressed a certain personal scepticism regarding style guides in two sentences of currently three much longer mails in this thread, which I considered to be constructive, at least as brainstorming fodder or to give some motivations on how and why my personal style evolved the way it did.
From this sentence:
"I'm not too much in favour of a style "guide" however. Let people be creative."
... where I briefly expressed my scepticism, as Luke asked for opinions about style guidelines for Pd.
Ciao
Frank
Hans-Christoph Steiner wrote:
On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
I think, it would be important to first collect every possible style element in the wild and document what people are using in reality. That would be interesting. I'm not too much in favour of a style
"guide" however. Let people be creative.Nobody is talking about requirements. If you don't like style
guides, don't use them. But it is really not useful to squelch other
people's efforts, especially when you don't even have an intention of
using this stuff.
I actually liked frank's idea to collect different people's ideas and compare them. maybe there is some common sense in all of them? marius.
On Jul 29, 2008, at 2:25 PM, marius schebella wrote:
Hans-Christoph Steiner wrote:
On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
There are some amazing sets of abstractions being released
recently, which has served to highlight the many extant styles of
patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized
approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/I think, it would be important to first collect every possible style element in the wild and document what people are using in reality. That would be interesting. I'm not too much in favour of a style
"guide" however. Let people be creative.Nobody is talking about requirements. If you don't like style
guides, don't use them. But it is really not useful to squelch
other people's efforts, especially when you don't even have an
intention of using this stuff.I actually liked frank's idea to collect different people's ideas
and compare them. maybe there is some common sense in all of them? marius.
Yeah, I think that was Luke's idea from the beginning. I agree that
it is a good one.
.hc
Access to computers should be unlimited and total. - the hacker ethic
Actually, reading this thread for me has shown me that one idea that I have been using is a lot more common that I had thought. The idea of naming the receives on an object with an "r" at the end (or whatever) to distinguish it from the send was something that I wasn't really sure if it was a "Pd Idiom" or not, and I really had no idea how to ask a question about it...
Mike
On Tue, Jul 29, 2008 at 1:25 PM, marius schebella < marius.schebella@gmail.com> wrote:
Hans-Christoph Steiner wrote:
On Jul 29, 2008, at 1:31 AM, Frank Barknecht wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
I think, it would be important to first collect every possible style element in the wild and document what people are using in reality. That would be interesting. I'm not too much in favour of a style "guide" however. Let people be creative.
Nobody is talking about requirements. If you don't like style guides, don't use them. But it is really not useful to squelch other people's efforts, especially when you don't even have an intention of using this stuff.
I actually liked frank's idea to collect different people's ideas and compare them. maybe there is some common sense in all of them? marius.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Luke
Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
The only one I have seen so far for Pd covers best practices for layout. I'd want to include that, but also codify naming, arguments, common idioms, and so on.
I've begun to collect some of my practices to start things off. I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always first in
the argument list [1]
- When possible, pass parent arguments in numeric order, like [child
$0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
i arbitrary use ".", "-" and "_" . IMO a separator in a send/receive name is needed when you use a dollar, and i would welcome a guideline, especially if there is a certification and quality brand for pd-patches :)
but there are so many styles and i don't even know which way to declare an external.
now a bit personal: i don't like $0 :) . It's fine for a namespace within a patch, but I found myself often needing to access something from "outside" so i have to pass $0 around, which is ugly. I much more prefer a global receiver and route everything. so i pass the name of my patch to it's abstractions. abstracions get global receiver with $1 in it which is the motherpatchname. it helps for orientation i.e. look at the window title:
yourabstraction.pd (mother) isn't it better than: yourabstraction.pd (1284)
you can even use it for [sssad $1/vol] without having the $0 making your sssad key into a unusable name. If I have GUI inside the GOP each sliders send and receive name begin with $1. or $1- or $1_ (guideline please!), that makes it possible to hijack the patch from an other patch. Like the midilearn or automator patch can control any slider in this setup.
Franks recommendation UPPERCASE for globals is really neat.
For GUI elements like sliders I've never regret to use a kind of name hierarchy ($1.vol), usually mypatch-myabs-myparameter or mypatch.myabs.myparameter or mypatch_myabs_myparameter or whatever. so you can hijack your channel aux-sender with anything.
but that means you can't open a patch multiple times, no problem for me because i reuse code always with abstractions.
does somebody run 1 patch multiple times? (sounds like fun would you mind and share?)
i look forward to the lazy-vote :)
eni
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Programming recommendations
- To invert a toggle, use [== 0]
- Use the loadbang of the parent of both abstractions to initialize
two or more interdependent abstractions
[1] I think of this like emulating the "self" convention in Python
Programming recommendations
always use [trigger] for 1tomany connections
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. It is almost not possible for me to look at the montreal abstractions... I also want to point out the importance of good grouping. sometimes I use bg canvases to underline that certain objects belong together (do some transformation or algorithm). 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).
some things are important for patches that should be portable. please mention, which libraries are used, and consider to use declare to load the objects. do not store patches with position <0/0. some window managers will not allow to drag the patch window around. (oh, and please don't place objects outside the canvas and esp. not <0/0, having to scroll to the left to see the beginning of a patch can cause heart attack). and not all people have widescreen monitors or hi-res monitors, so I think 1024 should be the maximum width of a patch.
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).
I don't care about send and receive naming conventions( - _ / camelCase), as long as they are unique ($0).
more later. marius.
Luke Iannini wrote:
There are some amazing sets of abstractions being released recently, which has served to highlight the many extant styles of patching. I was wondering if there was interest in establishing a set of guidelines for patching in the vein of PEP 8 for Python; I've found that document to be very relaxing as it is a standardized approach to OCD. More seriously, it greatly helps when reading other people's code or collaborating. http://www.python.org/dev/peps/pep-0008/
The only one I have seen so far for Pd covers best practices for layout. I'd want to include that, but also codify naming, arguments, common idioms, and so on.
I've begun to collect some of my practices to start things off. I was hoping we could all lazy-vote the document together in this thread and I'll then compile it into a PdPedia/Pd.info document. So, feel free to object to or replace my propositions.
Style:
- If giving $0 as an argument to an abstraction, it is always first in
the argument list [1]
- When possible, pass parent arguments in numeric order, like [child
$0 $1 $2 other1 other2] etc.
- Sends and Receives are written in camelCase, with "R" appended to
complementary receives (e.g. in GUIs, $0mySlider for the send and $0mySliderR for the receive)
- When prepending $0 to a symbol, only add a "-" to separate it from
another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].
- When working with stereo, Left and Right pairs are written with Le
and Ri appended (to distinguish them from an R denoting "receive", above)
Programming recommendations
- To invert a toggle, use [== 0]
- Use the loadbang of the parent of both abstractions to initialize
two or more interdependent abstractions
[1] I think of this like emulating the "self" convention in Python
And so on... Cheers Luke
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Chris McCormick -
Enrique Erne -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Luigi Rensinghoff -
Luke Iannini -
marius schebella -
Mike McGonagle -
Thomas Mayer