...

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

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

Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:

Ok, I'd like to propose a "patch-off."

What's the cleanest, clearest way to present adsr.pd from the audio tutorials?

I choose this patch because there are lots of crossed wires, plus one has to leave space for the explanatory comments of the patch.

Here are two versions I could think of.

Nice idea. I wrote up two alternative aproaches to ADSRing in Pd here: http://footils.org/cms/weblog/2009/mar/21/adsr-envelopes-pd/

My patch-off is this: http://footils.org/pkg/adsr-variations.pd

(For a strange reason my Iceweaselfirefox doesn't show the images for that article. My iPhone does, so they must be there. Can you see the images?)

Ciao

Frank Barknecht Do You RjDj.me? _ ______footils.org__

Nice. As a side note, the ADSR variations patch of Frank's show very clearly how to use [vline~] correctly: $1=lvl, $2=attack time, $3=decay time, $4=sustain level. Go to $1 over $2 msec, go to $4 over $3 msec

Could use that in the vline~ help patch!

~Kyle

On Sat, Mar 21, 2009 at 5:01 AM, Frank Barknecht fbar@footils.org wrote:

Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:

...

(For a strange reason my Iceweaselfirefox doesn't show the images for that article. My iPhone does, so they must be there. Can you see the images?)

Never mind: Ad(sr)-blocking gone wrong...

Ciao

Frank

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:

I agree. I also like the use of list in that patch to store parameters.

So if you wanted to set parameters with creation arguments, would it just be a matter of using $1...$5 in the [list]s and (un)[pack]?

Yes, almost. [list] is a shortcut for [list append] so you need to use: [list append $1 $2 $3 $4 $5] or so.

Ciao

Frank

Hallo, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:

Actually [list $1 $2 $3 $4 $5] seems to work in this context, but I guess that's because the first arg isn't a symbol. Is that why you're saying [list append] is needed?

The [list] object will behave differently depending on its first argument: You get to choose between [list prepend], [list append], [list split] etc. The following arguments have different meanings depending on the first argument.

E.g. [list split 3] will split a list at position 3, while [list prepend 3] will add a "3" in front of your incoming list.

If you create [list] without any argument it will be the same as [list append], but if you'd use [list $1] then the value of $1 will decide, which kind of list operation you get. So if $1 is "split" you get a splitter, if it's "append" then you get a [list append].

So [list $1 $2 $3 $4 $5] is *not* the same as [list append $1 $2 $3 $4 $5]! Try it by sending something into both and print the result.

Ciao

Frank

Hallo Jonathan, Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:

I understand what you describe. But when the 1st creation argument is a float, [list $1] and [list append $1] print the exact same result as far as I can see.

(Shaky comp sci terminology to follow...) Looking at list_new in x_list.c, if the first creation argument of [list $1 $2 etc.] is a not a symbol, the object is deemed a [list append] and the args are left alone. For [list append $1 $2 etc.] however, after "append" is matched, the argument count is decremented and the 2nd arg becomes the 1st. Consequently, the behavior of [list $1 $2 etc.] is exactly the same as [list append $1 $2 etc.] in this case.

Ah, indeed you're right! Thanks for pointing me to this, I was falsely assuming otherwise (and should have checked myself before tellling others to check it, sorry. :(

I would prefer the more verbose form [list append $1 $2 ...] just for clarity.

Ciao

Frank

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 Barknecht Do You RjDj.me? _ ______footils.org__

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

Hi Martin,

Here's my proposal: horizontal connections should only be used when the upper object has only one outlet, and the lower object has only one inlet. Otherwise there will be always be ambiguity.

With your example of all outlets pointing to the same inlet, there is still ambiguity as to whether or not all the outlets are actually connected. That's fine if your patching style is to connect them first, and only line them up after. But if someone is debugs a patch they made that includes your abstraction, they would have to click and move objects to be certain all the objects are actually connected.

-Jonathan

--- On Sat, 3/21/09, Martin Peach martin.peach@sympatico.ca wrote:

From: Martin Peach martin.peach@sympatico.ca Subject: Re: [PD] style guide idea: [send foo] versus [; foo( To: pd-list@iem.at Date: Saturday, March 21, 2009, 11:42 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.

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

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:

.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/

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

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

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

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

--- On Wed, 3/25/09, Mathieu Bouchard matju@artengine.ca wrote:

From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] style guide idea: [send foo] versus [; foo( To: "Hans-Christoph Steiner" hans@eds.org Cc: "Matt Barber" brbrofsvl@gmail.com, 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

--- On Wed, 3/25/09, Mathieu Bouchard matju@artengine.ca wrote:

From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] style guide idea: [send foo] versus [; foo( To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@eds.org, "Matt Barber" brbrofsvl@gmail.com, 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

--- On Thu, 3/26/09, Mathieu Bouchard matju@artengine.ca wrote:

From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] style guide idea: [send foo] versus [; foo( To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@eds.org, "Matt Barber" brbrofsvl@gmail.com, 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

matju@artengine.ca 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

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