Re: [PD] style guide idea: [send foo] versus [; foo(
--- On Thu, 3/26/09, Mathieu Bouchard wrote: > From: Mathieu Bouchard > Subject: Re: [PD] style guide idea: [send foo] versus [; foo( > To: "Jonathan Wilkes" > Cc: "Hans-Christoph Steiner" , "Matt Barber" > , pd-list@iem.at > Date: Thursday, March 26, 2009, 3:07 AM > On Wed, 25 Mar 2009, Jonathan Wilkes wrote: > > > --- On Wed, 3/25/09, Mathieu Bouchard > wrote: > >> Well, ideally, perhaps... but I think that > it's > >> somewhat hard to do. Perhaps more so when teaching > in French > >> (or any other language apart from English), > because then you > >> have to deal both with the synonyms in French and > the > >> synonyms in English at the same time. > > At least in English, which is all I've taught in, > it's merely a practical matter of using one consistent > term instead of using many interchangeably. > > I know, but when using various materials that are using > various different conventions, or when answering questions > that have been asked using different words, it's hard to > keep using the same word over and over. I see myself > correcting students on the uses of words like objects vs > classes, but that's not for the same reason at all, as > this is for resolving the nameclash between > "object" the synonym of "class" and > "object" the other meanings of it. Since the > synonyms for connections are not clashing with much of > anything else in a significant way (perhaps "line" > is...) it's not the same reason for correcting speech > and I'm not quite used to that. > > OTOH, the upside to using words interchangeably is that > people get used to the synonyms that they will have to use > in real situations... even if I only accidentally use them. I'm responding mostly to your use of the term "crash course." In that context I think it's preferable to restrict terminology so that things like execution order, cold vs. hot inlet, etc. may take precedence. Getting used to synonyms is a trivial and common task that can be gleaned from looking at a list of synonyms, whereas the other concepts are specific to learning Pd and difficult to grasp. In fact, if there were a list of synonyms for common features/concepts in Pd, I think it would be as trivial as putting a link on a handout for the student. Then if people need to search the mailinglist later, they can just go to the list and simply try each possibility until they find what they're looking for. Is there something like this already? If not, I can start making one. -Jonathan > > If I made a tutorial or a set of tutorials, I'd > probably end up calling it by just one name, but if I'm > using other people's tutorials together with mine, > I'm probably not going to search and replace. > > Perhaps it's just that pd-list, pd-dev and #dataflow > are extreme cases of people coming together with different > words, and that I don't recall enough the last real > course I taught... it's been a while. > > _ _ __ ___ _ _ > _ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, > Québec ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
On Wed, 25 Mar 2009, Jonathan Wilkes wrote: --- On Wed, 3/25/09, Mathieu Bouchard wrote: Well, ideally, perhaps... but I think that it's somewhat hard to do. Perhaps more so when teaching in French (or any other language apart from English), because then you have to deal both with the synonyms in French and the synonyms in English at the same time. At least in English, which is all I've taught in, it's merely a practical matter of using one consistent term instead of using many interchangeably. I know, but when using various materials that are using various different conventions, or when answering questions that have been asked using different words, it's hard to keep using the same word over and over. I see myself correcting students on the uses of words like objects vs classes, but that's not for the same reason at all, as this is for resolving the nameclash between "object" the synonym of "class" and "object" the other meanings of it. Since the synonyms for connections are not clashing with much of anything else in a significant way (perhaps "line" is...) it's not the same reason for correcting speech and I'm not quite used to that. OTOH, the upside to using words interchangeably is that people get used to the synonyms that they will have to use in real situations... even if I only accidentally use them. If I made a tutorial or a set of tutorials, I'd probably end up calling it by just one name, but if I'm using other people's tutorials together with mine, I'm probably not going to search and replace. Perhaps it's just that pd-list, pd-dev and #dataflow are extreme cases of people coming together with different words, and that I don't recall enough the last real course I taught... it's been a while. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
--- On Wed, 3/25/09, Mathieu Bouchard wrote: > From: Mathieu Bouchard > Subject: Re: [PD] style guide idea: [send foo] versus [; foo( > To: "Jonathan Wilkes" > Cc: "Hans-Christoph Steiner" , "Matt Barber" > , pd-list@iem.at > Date: Wednesday, March 25, 2009, 9:15 PM > On Wed, 25 Mar 2009, Jonathan Wilkes wrote: > > > I understand the point of making that information > available, but once you start describing a particular pd > concept, don't you stick to one term for the sake of > clarity? > > Well, ideally, perhaps... but I think that it's > somewhat hard to do. Perhaps more so when teaching in French > (or any other language apart from English), because then you > have to deal both with the synonyms in French and the > synonyms in English at the same time. At least in English, which is all I've taught in, it's merely a practical matter of using one consistent term instead of using many interchangeably. -Jonathan > > _ _ __ ___ _ _ > _ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, > Québec ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
On Wed, 25 Mar 2009, Frank Barknecht wrote: Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: Btw, it's in pd/doc/2.control.examples/10.more.messages.pd , and I'd have trouble considering anything in that folder as being non-basic. I must say, when thinking about the time when I learned Pd that there is a lot to swallow at the beginning. I never could attend a workshop, so I learned by doing Pd, reading stuff and from help on this list. Now it's easier as there are many workshops all over, but I guess the "old timers" like me or Hans all learned Pd without a teacher. Well, I all learned without a teacher either... but then I had a strange path. In my first encounter with Pd, I started trying to port a large external library. Then a year later, I started trying Pd itself a bit. Then the following year I started reading the source code. And then I realised that I should really force myself to read the manual a bit. It makes it harder to relate to students for sure. Well, I don't think it's an all-or-nothing proposition. Section 2 is not there as something that must be finished learning before going somewhere else. Everybody will yawn at one part or another of that section, and eventually they figure out that they have to refresh themselves a bit. It's much easier to remember things that you can imagine having a use for, and so if you can't, then you need to develop that imagination so that you can help yourself remember more. (this is yet another example of why I needed to escape the math dept) And 2.control.examples is not as much fun as 3.audio.examples, This is something that I hardly notice, as a programming languages theory enthusiast... even though pd is full of holes, it's so much different from everything else, that there's much that can be said about it and thought about it. And then my personal interest in music composition faded not long before I started to use Pd, and I've never quite been able to reconnect the two... so, that tends to tip the balance in direction of section 2... but I know what you mean. When I started a degree in computer programming, I couldn't understand why so few people thought it could be a good idea to learn programming by generating graphics. But what I did was simple: I read all the docs over and over. Again and again, and repeated that once every year at least. I should have read this part of your mail before replying above. I'm kinda repeating you. Just like Hans it took me a while to understand the concept behind semicolon senders and how they are equivalent to [s something] and how ";pd dsp" is the same as [s pd] ... But once I got that, it opened up all kinds of neat patching tricks and made certain things much easier to do and to understand that I was struggling with before. It's not just that, it's also how that semicolon relates to the semicolons in [netsend], [qlist], the .pd file format, and dynamic patching. It all fits together. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: > Btw, it's in pd/doc/2.control.examples/10.more.messages.pd , and I'd have > trouble considering anything in that folder as being non-basic. I must say, when thinking about the time when I learned Pd that there is a lot to swallow at the beginning. I never could attend a workshop, so I learned by doing Pd, reading stuff and from help on this list. Now it's easier as there are many workshops all over, but I guess the "old timers" like me or Hans all learned Pd without a teacher. And 2.control.examples is not as much fun as 3.audio.examples, so the value of that directory wasn't clear to me immediatly. But what I did was simple: I read all the docs over and over. Again and again, and repeated that once every year at least. And with docs I explicitely include the html-docs, which is something many people seem to skip or only skim through once. Just like Hans it took me a while to understand the concept behind semicolon senders and how they are equivalent to [s something] and how ";pd dsp" is the same as [s pd] ... But once I got that, it opened up all kinds of neat patching tricks and made certain things much easier to do and to understand that I was struggling with before. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
On Wed, 25 Mar 2009, Jonathan Wilkes wrote: I understand the point of making that information available, but once you start describing a particular pd concept, don't you stick to one term for the sake of clarity? Well, ideally, perhaps... but I think that it's somewhat hard to do. Perhaps more so when teaching in French (or any other language apart from English), because then you have to deal both with the synonyms in French and the synonyms in English at the same time. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
--- On Wed, 3/25/09, Mathieu Bouchard wrote: > From: Mathieu Bouchard > Subject: Re: [PD] style guide idea: [send foo] versus [; foo( > To: "Hans-Christoph Steiner" > Cc: "Matt Barber" , pd-list@iem.at > Date: Wednesday, March 25, 2009, 5:48 PM > On Sat, 21 Mar 2009, Hans-Christoph Steiner wrote: > > > And one last little story that I just remembered: I > didn't realize that [send pd] was even a possibility > until recently. I had always seen [; pd dsp 1( and figured > messages to pd had to be sent that way. > > So is this a sign that this part of Pd is difficult, or a > sign that you didn't learn it at the beginning? What if > I teach that thing at the very beginning of a course? The > beginners may get themselves to think that it's a very > basic concept of pd, and won't understand your > recommendation to get it removed. > > Btw, it's in > pd/doc/2.control.examples/10.more.messages.pd , and I'd > have trouble considering anything in that folder as being > non-basic. > > The problem with removing unneeded words and concepts from > a course is that it doesn't prepare the students for the > world, it prepares the students for an exam (or for anything > else that happens within the class). Which means that once > they try to handle patches made outside of this little > world, it reveals those holes in their knowledge. > > Once that I giving some kind of crash course on pd, I said > that outlets are linked to inlets using lines, connections, > wires, cords or patchcords. Later I was told by a teacher > that it's wrong to do so and that I should only be > stating one word and use it consistently. Well, I disagree a > lot. I don't want to cultivate students in a bubble. If > they try to search mailing-list archives for something > related to patchcords, they really do have to search for > those five words in order to find everything, and then if > they talk to anyone outside of the course they have to be > able to communicate. It's the same deal for semicolons > imho. I understand the point of making that information available, but once you start describing a particular pd concept, don't you stick to one term for the sake of clarity? > > _ _ __ ___ _ _ > _ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, > Québec___ > 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] style guide idea: [send foo] versus [; foo(
On Sat, 21 Mar 2009, Hans-Christoph Steiner wrote: And one last little story that I just remembered: I didn't realize that [send pd] was even a possibility until recently. I had always seen [; pd dsp 1( and figured messages to pd had to be sent that way. So is this a sign that this part of Pd is difficult, or a sign that you didn't learn it at the beginning? What if I teach that thing at the very beginning of a course? The beginners may get themselves to think that it's a very basic concept of pd, and won't understand your recommendation to get it removed. Btw, it's in pd/doc/2.control.examples/10.more.messages.pd , and I'd have trouble considering anything in that folder as being non-basic. The problem with removing unneeded words and concepts from a course is that it doesn't prepare the students for the world, it prepares the students for an exam (or for anything else that happens within the class). Which means that once they try to handle patches made outside of this little world, it reveals those holes in their knowledge. Once that I giving some kind of crash course on pd, I said that outlets are linked to inlets using lines, connections, wires, cords or patchcords. Later I was told by a teacher that it's wrong to do so and that I should only be stating one word and use it consistently. Well, I disagree a lot. I don't want to cultivate students in a bubble. If they try to search mailing-list archives for something related to patchcords, they really do have to search for those five words in order to find everything, and then if they talk to anyone outside of the course they have to be able to communicate. It's the same deal for semicolons imho. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
On Sun, 22 Mar 2009, Hans-Christoph Steiner wrote: Or making lines that go up for anything but feedback/loops. Well, if you first make sure that most lines are as short as possible, then there's not much need to worry about lines going up. A single-outlet object connected to a single-inlet object that doesn't get connected anywhere else, can have a 2-pixel line. After that, wires going up is a minor trouble and/or simply a necessity. I do lots of lines that go up, especially to an object at the same height, so, object-wise, it's a kind of horizontal connection, but the rendering goes up because outlets are at the bottom of boxes and inlets are at the top. Any I can't think of any reason why you should ever cross over an inlet or outlet, i.e. Frank's #4. Because the font changed after the patch was made. Which is probably an issue for all of Pd these days...? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
On Sat, 21 Mar 2009, Frank Barknecht wrote: Yeah, lets not turn a style guide into a style law. Sometimes crossings are not avoidable indeed. Well, I don't just mean that. I also mean that sometimes crossings are clearer than any replacement for them. Often a simple X of wires is much more expressive than a [s]/[r] pair made only for the sake of following an unpractically stringent standard about crossings. I seem to go like that: 1) avoid crossings Although, when I think my patch is messy, I first try to remove excess crossings, I can't possibly put avoiding crossings above everything else all of the time. You have to make exceptions for what I was calling "cross-connect" and "side-cross-connect" in PdCon04; that is, respectively, crossing wires from two outlets of one object to two inlets of another, and from one outlet of each of two objects, to one inlet of the other. It would look very silly avoiding that crossing using a [s]/[r] pair. There are other variations of the same, using more wires. For example, see seq_fold-help.pd in GridFlow for a version with three wires. 3) if you really have to cross over objects, make the patch cords go in straight vertical lines (straight vertical cords are the best cords anyway) 4) even then avoid crossing over object inlets or outlets, as it is ambiguous which cords are connected. I'd put (4) over (3), really. But those efforts are foiled by font issues and by the fact that Pd never stores the object width in the case of plain objectboxes. So if you change the font you can get a different positioning of outlets. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > I think avoiding horizontal lines should be pretty high up there on the > no-no list. Or making lines that go up for anything but feedback/loops. I sometimes do like lines going a little bit up when things are on the same logical level so that I can have the objects themselves align next to each other as in a line of text. Like: | [* 0]\[r factor] | or in a counter of course. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
On Mar 21, 2009, at 2:39 PM, Frank Barknecht wrote: Hallo, Martin Peach hat gesagt: // Martin Peach wrote: It's a fun exercise for some kinds of mind to make all the non- vertical lines either horizontal or 45 degrees, as in the attached screen grab. Ha, yeah, that's really cute! Unfortunatly I clashes with another personal preference I have: avoiding horizontal lines. I think avoiding horizontal lines should be pretty high up there on the no-no list. Or making lines that go up for anything but feedback/ loops. Any I can't think of any reason why you should ever cross over an inlet or outlet, i.e. Frank's #4. I made another attempt on A04.line2.pd to highlight the messages themselves: A04.line2.pd Description: Binary data .hc Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
Frank Barknecht wrote: Hallo, Martin Peach hat gesagt: // Martin Peach wrote: It's a fun exercise for some kinds of mind to make all the non-vertical lines either horizontal or 45 degrees, as in the attached screen grab. Ha, yeah, that's really cute! Unfortunatly I clashes with another personal preference I have: avoiding horizontal lines. My personal preference says horizontal lines are all right as long as the connections are unambiguous. If a line passes across several outlets on the way to somewhere it's only acceptable when all the outlets are connected to the same inlet, so a bunch of messages to the same inlet could all be aligned on the same horizontal or diagonal line, but not vertical because then the message inlets would appear to be connected when they're not. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
On Mar 21, 2009, at 3:42 AM, Matt Barber wrote: Ah, ok, I get it, the text in the msg boxes is basically the same as the text in the qlist file. That makes sense, and in the context of [qlist] I think it makes sense to teach about [; foo( sends. But I don't think that [qlist] is an essential object, especially for newbies. I am not saying to avoid it, I have covered it. But personally, I almost never use it. I find it easier to use [textfile] and write my own timing code. You can be a pretty advanced Pd user and not have to use semi-colons in message boxes. IMHO, semi-colons in messages boxes are no doubt useful, but they are not essential. In the interests of spreading out the learning of the concepts in Pd into as many stages as possible, I think it makes sense to avoid using semi-colons in messages boxes except in contexts that they are indispensible. So when learning about [qlist], for example, semi- colons in message boxes should definitely be covered. Outside of those contexts, I think that overall, Pd users will be better served by avoiding their use. I would have a hard time signing up for this program. A lot of things in Pd (and any programming language) are useful but inessential. IMO the send/receive binding in messages is essential if you want to understand how Pd is organized. A lot depends on the kind of student you're working with -- many of them don't feel comfortable with things unless they see some kind of "big picture" -- for those students, they would be comforted by the fact that message boxes can store "send" messages, as well as [qlist] files, the text in .pd files, etc. Eventually students will need to learn this stuff, so the occasional | ;/ | pd dsp 1 \ serves as a handy reminder rather than a detriment to readability. I agree that we should be teaching it, but if you've never done any programming whatsoever, and haven't learned about that syntax in Pd, then it is definitely a hinderance to learning Pd. There are lots of useful concepts in Pd that are not trivial to learn. If the newbie can be more gradually introduced to them, and have a cycle of attempts and successes, then they will be more willing later on to struggle to get something working. If the newbie is hit with a stack of new concepts all at once, it makes it harder to have those successes in the beginning. I also agree with you that once you are learning about messages and [qlist] that having reminders is useful. But until then they often are a major stumbling block for newbies. So I don't think everyone needs to avoid their use, but I do think that in the documentation and reference, we should avoid their use except in the contexts where they are directly relevant. A great example is A04.line2.pd. The three big message boxes are pretty impenetrable for someone with no programming experience. Compare it to the [trigger bang anything bang] on the lower right. And one last little story that I just remembered: I didn't realize that [send pd] was even a possibility until recently. I had always seen [; pd dsp 1( and figured messages to pd had to be sent that way. .hc A04.line2.pd Description: Binary data Part of the problem is that [; foo( is a misnomer. It's | ;/ | foo \ This is the only way the syntax is clear. My vote for style goes for which makes the most sense in (often very complex) context. Matt As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
Hallo, Martin Peach hat gesagt: // Martin Peach wrote: > It's a fun exercise for some kinds of mind to make all the non-vertical > lines either horizontal or 45 degrees, as in the attached screen grab. Ha, yeah, that's really cute! Unfortunatly I clashes with another personal preference I have: avoiding horizontal lines. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote: > On Fri, 20 Mar 2009, Frank Barknecht wrote: > >> For example I'd rather start with making people properly left-align >> their patches and avoid crossing patch cords > > well, I do my best to reduce the number of crossings, but if I have to > avoid crossings completely, I'll just avoid Pd... > > Pd doesn't make it easy to avoid crossings. > > Not all crossings are even bad. Crossings that are ambiguous-looking are > very bad. Too many crossings in the same area is bad, except if the > crossings are very regular-looking (a line crossing a bunch of parallel > lines is more orderly than a line crossing a bunch of random-angled > lines). Yeah, lets not turn a style guide into a style law. Sometimes crossings are not avoidable indeed. You also have to weight crossings against other layout questions, like preferring straight vertical lines and left-alignment. I think, when laying out my patches I seem to go like that: 1) avoid crossings 2) if that doesn't work, then try to avoid patch cords crossing over objects, i.e. prefer cords crossing other cords only 3) if you really have to cross over objects, make the patch cords go in straight vertical lines (straight vertical cords are the best cords anyway) 4) even then avoid crossing over object inlets or outlets, as it is ambiguous which cords are connected. Here's a patch that shows me failing all the way up to 3), but not 4): http://footils.org/images/adsr-envelope-pipe.png Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
--- On Sat, 3/21/09, Hans-Christoph Steiner wrote: > From: Hans-Christoph Steiner > Subject: Re: [PD] style guide idea: [send foo] versus [; foo( > To: jancs...@yahoo.com > Cc: "dmotd" , pd-list@iem.at > Date: Saturday, March 21, 2009, 2:48 AM > On Mar 20, 2009, at 5:51 PM, Jonathan Wilkes wrote: > > > > > > > > > > > --- On Fri, 3/20/09, Hans-Christoph Steiner > wrote: > > > >> From: Hans-Christoph Steiner > >> Subject: Re: [PD] style guide idea: [send foo] > versus [; foo( > >> To: "dmotd" > >> Cc: pd-list@iem.at > >> Date: Friday, March 20, 2009, 5:25 PM > >> I am not proposing to limit the use of dollar args > in > >> message boxes for dynamic sends, that is a very > useful > >> feature. The example you give here, though, is an > example of > >> a shortcut for typing, there is no other benefit > that I can > >> see. > >> > >> And at the risk of sounding pedantic, I am going > to quote > >> one of my favorite ideas relating to code: > "Programs > >> should be written for people to read, and only > incidentally > >> for machines to execute". Typing shortcuts > like this > >> message box below almost never save time when you > look at > >> the whole picture. Code is read far more times > than it is > >> written, so really we should be optimizing for > reading > >> rather than writing. > > > > Could you give an example that is more readable than > the message box below? > > The key part is that [trigger] is the essential way in Pd > to represent execution order. As Frank says: "use > [trigger]s everywhere". Then by breaking out the > messages into their own message boxes, you can clearly see > what the messages that are being send separately from their > destination. > > > > > Having lines of text execute in top-to-bottom may be more > readable for > code like Java, C, etc., but Pd uses right-to-left to > represent > execution order, hence trigger. > > .hc Pd also uses top-to-bottom to represent execution order. Maybe I've just gotten really used to msg-boxes spanning multiple lines-- they seem perfectly readable. But I can see how a single liner like [; pd-some-window clear( might confuse a student where using a msg-box -> [send] would not. -Jonathan > > > > -Jonathan > > > >> > >> In Pd, [trigger] is the central mechanism for > specifying > >> execution order. Therefore, in the interest of > readability, > >> [trigger] should be used as much as possible. > >> > >> Clearer documentation of the messages boxes would > also be a > >> great thing. But you almost anything without ever > using a > >> semi-colon in a message box, they are mostly used > as a > >> typing shortcut, and many people are confused by > them, so I > >> think we should really be limiting them to things > like > >> dynamic sends, since that is hard to do in other > ways. > >> > >> .hc > >> > >> On Mar 20, 2009, at 1:32 AM, dmotd wrote: > >> > >>> hmm.. generally this could be a good idea, but > message > >> sending is most useful > >>> when initialising a number of receives ie: > >>> > >>> [loadbang] > >>> | > >>> |; init-1 6 / > >>> |; init-2 symbol foo | > >>> |; init-3 -2 \ > >>> > >>> which is far more elegant than the the > trigger/send > >> replacement, especially > >>> with more fields.. > >>> > >>> i think its important for students to > recognise that > >> this feature of messaging > >>> has a role to play, rather than trying to veil > its > >> use. in my experience > >>> people will tend to use [send foo] more often > when > >> they start pd, then begin > >>> abbreviating to [s foo] before they appreciate > the msg > >> shorthand [; foo[. but > >>> you are right it is a little confusing for new > users.. > >>> > >>> perhaps this just needs clearer documenting? > 'what > >> does a semi-colon at the > >>> start of a message mean?' in the FAQ? > >>> > >>> dmotd > >>> > >>> On Friday 20 March 2009 10:38:06 > Hans-Christoph > >> Steiner wrote: > >>>> Here's something that I'd like to > propos
Re: [PD] style guide idea: [send foo] versus [; foo(
> Ah, ok, I get it, the text in the msg boxes is basically the same as the > text in the qlist file. That makes sense, and in the context of [qlist] I > think it makes sense to teach about [; foo( sends. But I don't think that > [qlist] is an essential object, especially for newbies. I am not saying to > avoid it, I have covered it. But personally, I almost never use it. I find > it easier to use [textfile] and write my own timing code. You can be a > pretty advanced Pd user and not have to use semi-colons in message boxes. > > IMHO, semi-colons in messages boxes are no doubt useful, but they are not > essential. In the interests of spreading out the learning of the concepts > in Pd into as many stages as possible, I think it makes sense to avoid using > semi-colons in messages boxes except in contexts that they are > indispensible. So when learning about [qlist], for example, semi-colons in > message boxes should definitely be covered. > > Outside of those contexts, I think that overall, Pd users will be better > served by avoiding their use. I would have a hard time signing up for this program. A lot of things in Pd (and any programming language) are useful but inessential. IMO the send/receive binding in messages is essential if you want to understand how Pd is organized. A lot depends on the kind of student you're working with -- many of them don't feel comfortable with things unless they see some kind of "big picture" -- for those students, they would be comforted by the fact that message boxes can store "send" messages, as well as [qlist] files, the text in .pd files, etc. Eventually students will need to learn this stuff, so the occasional | ;/ | pd dsp 1 \ serves as a handy reminder rather than a detriment to readability. Part of the problem is that [; foo( is a misnomer. It's | ;/ | foo \ This is the only way the syntax is clear. My vote for style goes for which makes the most sense in (often very complex) context. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
On Mar 20, 2009, at 6:28 PM, Matt Barber wrote: Also note that some objects, e.g. [qlist], positively depend on the message sending style. My students who wanted to use them have often wondered why we hadn't covered the two ways of sending more in depth. Can you explain with an example? I don't understand why you must use message boxes semi-colons for [qlist]. The [qlist] help patch doesn't have any message boxes with semi-colons, for example. .hc Sure. A [qlist] sends messages from a file (among other things). Those messages have the same form as messages sent from message boxes: send-receive_symbol list or whatever; The only difference is that the first message in a message box is sent from its outlet rather than to a receive -- the leading semicolon you see just means "send no message from outlet" which to me makes plenty of sense and is not difficult to read at all. For instance, this: |; init-1 6 / |; init-2 symbol foo | |; init-3 -2 \ Really means: ; init-1 6; init-2 symbol foo; init-3 -2 Doesn't it? (pardon my ascii) And if you did this: bang; init-1 6; init-2 symbol foo; init-3 -2 then it would send a bang from its inlet first. So in order to have my students understand [qlist] and its files, they have found it very useful to know about the message system in message boxes... it makes the message system in Pd on the whole a lot more understandable and less confusing, and it seems to be less confusing the earlier you introduce it to them. That's all I meant. Matt Ah, ok, I get it, the text in the msg boxes is basically the same as the text in the qlist file. That makes sense, and in the context of [qlist] I think it makes sense to teach about [; foo( sends. But I don't think that [qlist] is an essential object, especially for newbies. I am not saying to avoid it, I have covered it. But personally, I almost never use it. I find it easier to use [textfile] and write my own timing code. You can be a pretty advanced Pd user and not have to use semi-colons in message boxes. IMHO, semi-colons in messages boxes are no doubt useful, but they are not essential. In the interests of spreading out the learning of the concepts in Pd into as many stages as possible, I think it makes sense to avoid using semi-colons in messages boxes except in contexts that they are indispensible. So when learning about [qlist], for example, semi-colons in message boxes should definitely be covered. Outside of those contexts, I think that overall, Pd users will be better served by avoiding their use. .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
On Mar 20, 2009, at 5:51 PM, Jonathan Wilkes wrote: --- On Fri, 3/20/09, Hans-Christoph Steiner wrote: From: Hans-Christoph Steiner Subject: Re: [PD] style guide idea: [send foo] versus [; foo( To: "dmotd" Cc: pd-list@iem.at Date: Friday, March 20, 2009, 5:25 PM I am not proposing to limit the use of dollar args in message boxes for dynamic sends, that is a very useful feature. The example you give here, though, is an example of a shortcut for typing, there is no other benefit that I can see. And at the risk of sounding pedantic, I am going to quote one of my favorite ideas relating to code: "Programs should be written for people to read, and only incidentally for machines to execute". Typing shortcuts like this message box below almost never save time when you look at the whole picture. Code is read far more times than it is written, so really we should be optimizing for reading rather than writing. Could you give an example that is more readable than the message box below? The key part is that [trigger] is the essential way in Pd to represent execution order. As Frank says: "use [trigger]s everywhere". Then by breaking out the messages into their own message boxes, you can clearly see what the messages that are being send separately from their destination. init.pd Description: Binary data Having lines of text execute in top-to-bottom may be more readable for code like Java, C, etc., but Pd uses right-to-left to represent execution order, hence trigger. .hc -Jonathan In Pd, [trigger] is the central mechanism for specifying execution order. Therefore, in the interest of readability, [trigger] should be used as much as possible. Clearer documentation of the messages boxes would also be a great thing. But you almost anything without ever using a semi-colon in a message box, they are mostly used as a typing shortcut, and many people are confused by them, so I think we should really be limiting them to things like dynamic sends, since that is hard to do in other ways. .hc On Mar 20, 2009, at 1:32 AM, dmotd wrote: hmm.. generally this could be a good idea, but message sending is most useful when initialising a number of receives ie: [loadbang] | |; init-1 6 / |; init-2 symbol foo | |; init-3 -2 \ which is far more elegant than the the trigger/send replacement, especially with more fields.. i think its important for students to recognise that this feature of messaging has a role to play, rather than trying to veil its use. in my experience people will tend to use [send foo] more often when they start pd, then begin abbreviating to [s foo] before they appreciate the msg shorthand [; foo[. but you are right it is a little confusing for new users.. perhaps this just needs clearer documenting? 'what does a semi-colon at the start of a message mean?' in the FAQ? dmotd On Friday 20 March 2009 10:38:06 Hans-Christoph Steiner wrote: Here's something that I'd like to propose for the style guide, based on my teaching experience: - use [send foo] instead of [; foo( for all sends that aren't dynamically set A lot of people find the [; foo( syntax confusing, and since it is commonly used, it often gets in the way of newbies understanding the patch. While the [; foo( syntax is definitely useful for dynamic sends, I don't think there is an advantage to using for the regular sends. So for example: [dsp 1( [send pd] instead of |;/ |pd dsp 1 \ This change highlights the dataflow aspect of the messages over the text-style programming with syntax of the message box. At the very least, I think that the help patches should use this style, and I have started to use this style in my regular programming and it feels quite natural once you are used to it. I find it easier to read. (as for [s foo] versus [send foo] that's an issue I want to avoid in this discussion). .hc --- - The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ 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 Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -
Re: [PD] style guide idea: [send foo] versus [; foo(
On Fri, 20 Mar 2009, Frank Barknecht wrote: For example I'd rather start with making people properly left-align their patches and avoid crossing patch cords well, I do my best to reduce the number of crossings, but if I have to avoid crossings completely, I'll just avoid Pd... Pd doesn't make it easy to avoid crossings. Not all crossings are even bad. Crossings that are ambiguous-looking are very bad. Too many crossings in the same area is bad, except if the crossings are very regular-looking (a line crossing a bunch of parallel lines is more orderly than a line crossing a bunch of random-angled lines). _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
On Fri, 20 Mar 2009, Hans-Christoph Steiner wrote: I am not proposing to limit the use of dollar args in message boxes for dynamic sends, that is a very useful feature. The example you give here, though, is an example of a shortcut for typing, there is no other benefit that I can see. Shortcuts for typing are also usually shortcuts for reading for people who are willing to accept them. And at the risk of sounding pedantic, I am going to quote one of my favorite ideas relating to code: "Programs should be written for people to read, and only incidentally for machines to execute". I'd generally agree with your position, but I think that the «only incidentally» part is quite dismissive of the reason why programmes are written in the first place. Programming languages didn't develop significantly until there were machines to run them. At the very least it waited until that there were expectations of future machines that would be able to handle them, or expectations of future projects that would benefit from newer languages. The code doesn't really exist in a bubble. But most of all, readability doesn't necessarily mean longer code, and I'd even dare say it more often means shorter code. In Pd, [trigger] is the central mechanism for specifying execution order. Therefore, in the interest of readability, [trigger] should be used as much as possible. Excuse me: by opposition to what??? Clearer documentation of the messages boxes would also be a great thing. But you almost anything without ever using a semi-colon in a message box, they are mostly used as a typing shortcut, In the internals of Pd, the semicolon in messages is definitely the original feature, and [s foo] was afterwards added as a "longcut". What makes [s] the appropriate default way of doing something, such that the semicolon becomes a "mere shortcut"? and many people are confused by them, so I think we should really be limiting them to things like dynamic sends, since that is hard to do in other ways. People are confused by Pd... should we be limiting everybody to some other software... because there are people who might not understand Pd. If that's not the same thing as removing features that "might be confusing", I don't see how. « the GNOME policy is "If you find a feature, it might confuse a user, so remove it." » -- Uncyclopedia The next version of GNOME: http://uncyclopedia.wikia.com/wiki/Image:Next-gnome.png _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
On Mar 20, 2009, at 1:34 PM, Matt Barber wrote: hmm.. generally this could be a good idea, but message sending is most useful when initialising a number of receives ie: [loadbang] | |; init-1 6 / |; init-2 symbol foo | |; init-3 -2 \ which is far more elegant than the the trigger/send replacement, especially with more fields.. i think its important for students to recognise that this feature of messaging has a role to play, rather than trying to veil its use. in my experience people will tend to use [send foo] more often when they start pd, then begin abbreviating to [s foo] before they appreciate the msg shorthand [; foo[. but you are right it is a little confusing for new users.. Also note that some objects, e.g. [qlist], positively depend on the message sending style. My students who wanted to use them have often wondered why we hadn't covered the two ways of sending more in depth. Can you explain with an example? I don't understand why you must use message boxes semi-colons for [qlist]. The [qlist] help patch doesn't have any message boxes with semi-colons, for example. .hc There is no way to peace, peace is the way. -A.J. Muste ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
Hallo, Matt Barber hat gesagt: // Matt Barber wrote: > So in order to have my students understand [qlist] and its files, they > have found it very useful to know about the message system in message > boxes... it makes the message system in Pd on the whole a lot more > understandable and less confusing, and it seems to be less confusing > the earlier you introduce it to them. And then later if you can make your students understand, that even the text in object boxes is a message to an internal receiver, they will have an easier time when they want to do some dynamic patching. I think, a style guide should take care not to over-regulate things. For example I'd rather start with making people properly left-align their patches and avoid crossing patch cords and use [trigger]s everywhere - this is very important to make patches readable and maintainable and generally learn to "think in Pd". But if at the end of an object tree there is a [s foo] or a [; foo $1( is not that important IMHO. People will get tired of typing lots of $-variables on their own. Nobody uses [; foo $1 $2 $3 $4 $5 $6 $7 $8 $9( anyway when a simple [s foo] is sufficient. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
>> Also note that some objects, e.g. [qlist], positively depend on the >> message sending style. My students who wanted to use them have often >> wondered why we hadn't covered the two ways of sending more in depth. > > Can you explain with an example? I don't understand why you must use > message boxes semi-colons for [qlist]. The [qlist] help patch doesn't have > any message boxes with semi-colons, for example. > > .hc > Sure. A [qlist] sends messages from a file (among other things). Those messages have the same form as messages sent from message boxes: send-receive_symbol list or whatever; The only difference is that the first message in a message box is sent from its outlet rather than to a receive -- the leading semicolon you see just means "send no message from outlet" which to me makes plenty of sense and is not difficult to read at all. For instance, this: |; init-1 6 / |; init-2 symbol foo | |; init-3 -2 \ Really means: ; init-1 6; init-2 symbol foo; init-3 -2 Doesn't it? (pardon my ascii) And if you did this: bang; init-1 6; init-2 symbol foo; init-3 -2 then it would send a bang from its inlet first. So in order to have my students understand [qlist] and its files, they have found it very useful to know about the message system in message boxes... it makes the message system in Pd on the whole a lot more understandable and less confusing, and it seems to be less confusing the earlier you introduce it to them. That's all I meant. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
--- On Fri, 3/20/09, Hans-Christoph Steiner wrote: > From: Hans-Christoph Steiner > Subject: Re: [PD] style guide idea: [send foo] versus [; foo( > To: "dmotd" > Cc: pd-list@iem.at > Date: Friday, March 20, 2009, 5:25 PM > I am not proposing to limit the use of dollar args in > message boxes for dynamic sends, that is a very useful > feature. The example you give here, though, is an example of > a shortcut for typing, there is no other benefit that I can > see. > > And at the risk of sounding pedantic, I am going to quote > one of my favorite ideas relating to code: "Programs > should be written for people to read, and only incidentally > for machines to execute". Typing shortcuts like this > message box below almost never save time when you look at > the whole picture. Code is read far more times than it is > written, so really we should be optimizing for reading > rather than writing. Could you give an example that is more readable than the message box below? -Jonathan > > In Pd, [trigger] is the central mechanism for specifying > execution order. Therefore, in the interest of readability, > [trigger] should be used as much as possible. > > Clearer documentation of the messages boxes would also be a > great thing. But you almost anything without ever using a > semi-colon in a message box, they are mostly used as a > typing shortcut, and many people are confused by them, so I > think we should really be limiting them to things like > dynamic sends, since that is hard to do in other ways. > > .hc > > On Mar 20, 2009, at 1:32 AM, dmotd wrote: > > > hmm.. generally this could be a good idea, but message > sending is most useful > > when initialising a number of receives ie: > > > > [loadbang] > > | > > |; init-1 6 / > > |; init-2 symbol foo | > > |; init-3 -2 \ > > > > which is far more elegant than the the trigger/send > replacement, especially > > with more fields.. > > > > i think its important for students to recognise that > this feature of messaging > > has a role to play, rather than trying to veil its > use. in my experience > > people will tend to use [send foo] more often when > they start pd, then begin > > abbreviating to [s foo] before they appreciate the msg > shorthand [; foo[. but > > you are right it is a little confusing for new users.. > > > > perhaps this just needs clearer documenting? 'what > does a semi-colon at the > > start of a message mean?' in the FAQ? > > > > dmotd > > > > On Friday 20 March 2009 10:38:06 Hans-Christoph > Steiner wrote: > >> Here's something that I'd like to propose > for the style guide, based > >> on my teaching experience: > >> > >> - use [send foo] instead of [; foo( for all sends > that aren't > >> dynamically set > >> > >> A lot of people find the [; foo( syntax confusing, > and since it is > >> commonly used, it often gets in the way of newbies > understanding the > >> patch. While the [; foo( syntax is definitely > useful for dynamic > >> sends, I don't think there is an advantage to > using for the regular > >> sends. So for example: > >> > >> [dsp 1( > >> > >> [send pd] > >> > >> instead of > >> > >> |;/ > >> |pd dsp 1 \ > >> > >> This change highlights the dataflow aspect of the > messages over the > >> text-style programming with syntax of the message > box. At the very > >> least, I think that the help patches should use > this style, and I have > >> started to use this style in my regular > programming and it feels quite > >> natural once you are used to it. I find it easier > to read. > >> > >> (as for [s foo] versus [send foo] that's an > issue I want to avoid in > >> this discussion). > >> > >> .hc > >> > >> > >> > --- > >> - > >> > >> The arc of history bends towards justice. - > Dr. Martin Luther > >> King, Jr. > >> > >> > >> > >> ___ > >> 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 > > > > > > > > Programs should be written for people to read, and only > incidentally for machines to execute. > - from Structure and Interpretation of Computer Programs > > > ___ > 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] style guide idea: [send foo] versus [; foo(
I am not proposing to limit the use of dollar args in message boxes for dynamic sends, that is a very useful feature. The example you give here, though, is an example of a shortcut for typing, there is no other benefit that I can see. And at the risk of sounding pedantic, I am going to quote one of my favorite ideas relating to code: "Programs should be written for people to read, and only incidentally for machines to execute". Typing shortcuts like this message box below almost never save time when you look at the whole picture. Code is read far more times than it is written, so really we should be optimizing for reading rather than writing. In Pd, [trigger] is the central mechanism for specifying execution order. Therefore, in the interest of readability, [trigger] should be used as much as possible. Clearer documentation of the messages boxes would also be a great thing. But you almost anything without ever using a semi-colon in a message box, they are mostly used as a typing shortcut, and many people are confused by them, so I think we should really be limiting them to things like dynamic sends, since that is hard to do in other ways. .hc On Mar 20, 2009, at 1:32 AM, dmotd wrote: hmm.. generally this could be a good idea, but message sending is most useful when initialising a number of receives ie: [loadbang] | |; init-1 6 / |; init-2 symbol foo | |; init-3 -2 \ which is far more elegant than the the trigger/send replacement, especially with more fields.. i think its important for students to recognise that this feature of messaging has a role to play, rather than trying to veil its use. in my experience people will tend to use [send foo] more often when they start pd, then begin abbreviating to [s foo] before they appreciate the msg shorthand [; foo[. but you are right it is a little confusing for new users.. perhaps this just needs clearer documenting? 'what does a semi-colon at the start of a message mean?' in the FAQ? dmotd On Friday 20 March 2009 10:38:06 Hans-Christoph Steiner wrote: Here's something that I'd like to propose for the style guide, based on my teaching experience: - use [send foo] instead of [; foo( for all sends that aren't dynamically set A lot of people find the [; foo( syntax confusing, and since it is commonly used, it often gets in the way of newbies understanding the patch. While the [; foo( syntax is definitely useful for dynamic sends, I don't think there is an advantage to using for the regular sends. So for example: [dsp 1( [send pd] instead of |;/ |pd dsp 1 \ This change highlights the dataflow aspect of the messages over the text-style programming with syntax of the message box. At the very least, I think that the help patches should use this style, and I have started to use this style in my regular programming and it feels quite natural once you are used to it. I find it easier to read. (as for [s foo] versus [send foo] that's an issue I want to avoid in this discussion). .hc --- - The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ 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 Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
> hmm.. generally this could be a good idea, but message sending is most useful > when initialising a number of receives ie: > > [loadbang] > | > |; init-1 6 / > |; init-2 symbol foo | > |; init-3 -2 \ > > which is far more elegant than the the trigger/send replacement, especially > with more fields.. > > i think its important for students to recognise that this feature of messaging > has a role to play, rather than trying to veil its use. in my experience > people will tend to use [send foo] more often when they start pd, then begin > abbreviating to [s foo] before they appreciate the msg shorthand [; foo[. but > you are right it is a little confusing for new users.. > Also note that some objects, e.g. [qlist], positively depend on the message sending style. My students who wanted to use them have often wondered why we hadn't covered the two ways of sending more in depth. Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] style guide idea: [send foo] versus [; foo(
hmm.. generally this could be a good idea, but message sending is most useful when initialising a number of receives ie: [loadbang] | |; init-1 6 / |; init-2 symbol foo | |; init-3 -2 \ which is far more elegant than the the trigger/send replacement, especially with more fields.. i think its important for students to recognise that this feature of messaging has a role to play, rather than trying to veil its use. in my experience people will tend to use [send foo] more often when they start pd, then begin abbreviating to [s foo] before they appreciate the msg shorthand [; foo[. but you are right it is a little confusing for new users.. perhaps this just needs clearer documenting? 'what does a semi-colon at the start of a message mean?' in the FAQ? dmotd On Friday 20 March 2009 10:38:06 Hans-Christoph Steiner wrote: > Here's something that I'd like to propose for the style guide, based > on my teaching experience: > > - use [send foo] instead of [; foo( for all sends that aren't > dynamically set > > A lot of people find the [; foo( syntax confusing, and since it is > commonly used, it often gets in the way of newbies understanding the > patch. While the [; foo( syntax is definitely useful for dynamic > sends, I don't think there is an advantage to using for the regular > sends. So for example: > > [dsp 1( > > [send pd] > > instead of > > |;/ > |pd dsp 1 \ > > This change highlights the dataflow aspect of the messages over the > text-style programming with syntax of the message box. At the very > least, I think that the help patches should use this style, and I have > started to use this style in my regular programming and it feels quite > natural once you are used to it. I find it easier to read. > > (as for [s foo] versus [send foo] that's an issue I want to avoid in > this discussion). > > .hc > > > --- >- > > The arc of history bends towards justice. - Dr. Martin Luther > King, Jr. > > > > ___ > 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
[PD] style guide idea: [send foo] versus [; foo(
Here's something that I'd like to propose for the style guide, based on my teaching experience: - use [send foo] instead of [; foo( for all sends that aren't dynamically set A lot of people find the [; foo( syntax confusing, and since it is commonly used, it often gets in the way of newbies understanding the patch. While the [; foo( syntax is definitely useful for dynamic sends, I don't think there is an advantage to using for the regular sends. So for example: [dsp 1( | [send pd] instead of |;/ |pd dsp 1 \ This change highlights the dataflow aspect of the messages over the text-style programming with syntax of the message box. At the very least, I think that the help patches should use this style, and I have started to use this style in my regular programming and it feels quite natural once you are used to it. I find it easier to read. (as for [s foo] versus [send foo] that's an issue I want to avoid in this discussion). .hc The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
