Re: [PD] Idiomatic Pd
On Sun, Aug 3, 2008 at 2:03 AM, Luke Iannini [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [PD] Idiomatic Pd
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___
Re: [PD] Idiomatic Pd
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Yo, On Mon, Jul 28, 2008 at 10:31 PM, Frank Barknecht [EMAIL PROTECTED] 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
On Mon, Jul 28, 2008 at 1:39 PM, Hans-Christoph Steiner [EMAIL PROTECTED] 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote: On Mon, Jul 28, 2008 at 10:31 PM, Frank Barknecht [EMAIL PROTECTED] 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__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Luke Iannini wrote: On Mon, Jul 28, 2008 at 7:49 PM, Chris McCormick [EMAIL PROTECTED] 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Luke, I like some of your ideas, but I'd offer the following: 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. Why should we assume anything about an abstraction's parent? It seems to me a lot has to be assumed about the general purpose of abstractions for one to say that a child's $1 should usually be the parent's $0... I tend not to hierarchize my abstractions to quite this extent, and prefer to allow abstractions to be relatively agnostic about their surroundings when possible. There's one style of patching which suggests that abstractions should operate as closely as possible to built-in objects, which (in vanilla at least) are usually also basically unaware of their surroundings (save for [block~] and other canvas-local settings, or send-receive type bindings, which granted depend a lot upon $0 but not usually explicitly as a single argument passed to objects)... Though, I suppose I agree that when $0 *does* need to be passed, it could go first. I can think of many situations where it would want to go last, though -- for instance an abstraction which takes mandatory arguments and optional arguments, of which one of the latter is a number to prepend to a symbol to designate, say, the send symbol of a group of instances within a parent abstraction which might be used e.g. for error cleanup, and which otherwise should be set to that instance's (not the parent's) $0 when not in the presence of a parent that knows what to do with the error message (so it isn't sent anywhere at all). A related topic is: in general, if there's an adequate solution with an abstraction, should one use it rather than an external? Does this change in pedagogical situations where a student might profit in learning from a rather sparse set of unit generators? Does this change when performance is required above all? etc. etc. Another related topic -- for GOP abstractions, is it bad form to cover the abstraction name and arguments with a canvas? What if these things are printed as labels on canvases? * 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 : ). Smalltalk and Cocoa remind me more of supercollider (y/n?), which isn't a bad thing at all. Still, I prefer the hyphen after $0 in general, as it can apply to all cases. As an aside, I also prefer $0 at the beginning of a symbol whenever possible to ensure backwards compatibility with 0.40 -- and a [makefilename %d] trick with $0 to allow things like pd-$0-edge_of_now (I suppose I prefer underscores to camelCase... meh - I'm not sure this is vital to proper patching, but it does remind me of the C-style the objects themselves are written in). * When working with stereo, Left and Right pairs are written with Le and Ri appended (to distinguish them from an R denoting receive, above) I think it's better to remain completely neutral with regard to the numbering of channels. Stereo should not stand out as a preferred case... many other more general nomenclatures could apply, e.g. ch1 ch2 ch3 ch4 (or ch0 ch1, etc. for channel array lovers), or just the numbers, or something else. This might allow code from a stereo garden to be plucked and implemented in a multichannel space in the future, with little worry. Also, actual pairing of loudspeaker to channel number should not, in general, be codified. There are too many standard and acceptable configurations by now to anoint some over others. I guess I second Frank's suggestion and say let's see what patching styles abound and let people be creative -- but when there's codification, let it be generalizable to as many situations as possible. Thanks for the great suggestion about a style guide, though -- it would be especially helpful to newcomers and students. Things like decouple number boxes and bangs used for debugging from the workings of the patch I feel are almost essential examples of efficient and proper pd patching. And early, strong, and repetitive grounding in [trigger]. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Date: Tue, 29 Jul 2008 10:02:05 -0400 From: marius schebella [EMAIL PROTECTED] Subject: Re: [PD] Idiomatic Pd To: pd-list@iem.at Message-ID: [EMAIL PROTECTED] 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: 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. A lot can be had with at least left-aligning connected objects. You get a clean left side, which is the important side of most Pd objects because of the hot inlet there. Then even if something like the as in your [t b a a a a] aren't aligned anymore because of platform/version issues, you still have the clear layout of the main logic flow to the left. It's also good to leave a bit more room to the right of objects and comments to avoid overlapping boxes. I think, Pd-extended runs quite a bit narrower than Pd-vanilla with a 10px font on Linux, which is what I use. (I'm guilty of not leaving enough room to the right myself, though.) When 0.39 begins to wane (so [declare] can be used), ... Careful here: [declare -path ...] is disabled inside of abstractions in Pd-0.41. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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. Also, I forgot to mention that I think abstractions (and maybe to a lesser extent subpatches) should follow the right-to-left conventions of Pd objects for input/output, even if it complicates layout on the parent. So for instance [gate] from cyclone is bad Pd style, IMO, and an abstraction designed to mimic it ([gator], say) should be set up more like a multi-outlet [spigot]. Even [timer] still bothers me, but I guess it's a special case. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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 [EMAIL PROTECTED] 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
Re: [PD] Idiomatic Pd
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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
Re: [PD] Idiomatic Pd
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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 [EMAIL PROTECTED] 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 -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
When 0.39 begins to wane (so [declare] can be used), ... Careful here: [declare -path ...] is disabled inside of abstractions in Pd-0.41. Right -- but [declare -path ...] is terribly useful for not having a patch's main directory cluttered with 100 abstractions, which was the main point... but since 0.39 is still widely in use I tend to avoid it unless it's for patches I know only I am going to be running. I guess it's okay to be conservative in some parts of life. =o) OT -- out of curiosity, if it were to be enabled within an abstraction, would the -path be relative to the abstraction file or to the patch in which it's instantiated? M ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
On Jul 29, 2008, at 4:29 PM, Matt Barber wrote: When 0.39 begins to wane (so [declare] can be used), ... Careful here: [declare -path ...] is disabled inside of abstractions in Pd-0.41. Right -- but [declare -path ...] is terribly useful for not having a patch's main directory cluttered with 100 abstractions, which was the main point... but since 0.39 is still widely in use I tend to avoid it unless it's for patches I know only I am going to be running. I guess it's okay to be conservative in some parts of life. =o) OT -- out of curiosity, if it were to be enabled within an abstraction, would the -path be relative to the abstraction file or to the patch in which it's instantiated? The relative path stuff seems to be a can of worms that is more trouble that it is worth, IMHO. But in order to make sure it doesn't make things more complicated, the path declared by [declare -path] would have to be same absolute path everywhere it is used. I think the simplest solution is to make the only option be loading libraries and setting the global search path. Then use a unified library format that is very easy to setup. That's the goal with libdir. .hc M ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Idiomatic Pd
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
Re: [PD] Idiomatic Pd
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 [EMAIL PROTECTED] skype:gigischinke ichat:gigicarlo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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
Re: [PD] Idiomatic Pd
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. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
On Mon, Jul 28, 2008 at 7:49 PM, Chris McCormick [EMAIL PROTECTED] 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Idiomatic Pd
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__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
