--- On Tue, 8/11/09, Jonathan Wilkes jancsika@yahoo.com wrote:
From: Jonathan Wilkes jancsika@yahoo.com Subject: Re: [PD] Pd Manual To: "William Brent" william.brent@gmail.com Date: Tuesday, August 11, 2009, 11:04 PM
--- On Tue, 8/11/09, William Brent william.brent@gmail.com wrote:
From: William Brent william.brent@gmail.com Subject: Re: [PD] Pd Manual To: "Jonathan Wilkes" jancsika@yahoo.com Date: Tuesday, August 11, 2009, 8:58 AM
"It is indeterminate which of
"B" or "C" is done first; this depends on
what order you made the connections in (in Max,
it's
automatically sorted
right to left)."
First of all, the part before the semicolon
contradicts the part that
follows the semicolon.
I see your point here, but the meaning seems clear. From the perspective we're given of the patch, we really don't
know
which connection was made first. So it's indeterminate as presented.
Then, I guess trigger isn't introduced in the _very_
next
paragraph, but it's there in the next section (2.3.3) after
explaining
hot/cold inlets as a related point. So it's still part of
the
same line of thought. A few more trigger examples wouldn't hurt though...
Hi William, I would say that the meaning is clear for those of us who have patching habits in Pd. However, my main point is that the relevance is not clear, especially for people reading about Pd for the first time. I've heard and read at least five comments in the past year from people who have taken a cursory glance at Pd and found it necessary to mention they dislike the idea that "execution order is determined by the order in which connections are made." I know these people are aware of the [trigger] object, so my only explanation is that they think the order in which connections are made is useful as a common patching practice. Additionally, in section 2.3.3 it is stated that the second patch example (which has two connections coming from the number atom) is incorrect because the author made the leftmost connection first. Equally important, and unstated, is that such an idiom is _never_ relied upon in Pd. If you're reading the manual for the first time, how would you know which of the following is true: a) [trigger] is used to disambiguate execution order for the beginner, and for situations in which execution order gets complex. But for simple idioms, one can use connection order as a shortcut. b) The patch example is not idiomatic Pd, but the one that uses [trigger] is. [trigger] should _always_ be used for visual clarity whenever execution order matters.
Here's my first attempt to clarify the relevance of the sentence I quoted in the first email (Section 2.3.2):
Whether "B" or "C" is done first depends on the order in which you made
the connections. This means you cannot determine the execution order
simply by looking at the two connections coming from "A." In practice,
Pd patches never rely upon the order in which connections were made to
specify execution order. In situations where execution order must be
specified, the [trigger] object is used (see section 2.3.3 below).
And in section 2.3.3:
Change: Here, I connected the left inlet before connecting the right hand one (although this is not evident in the appearance of the patch.)
To: If I had connected the left inlet before connecting the right hand one, the "+" would add the new input (at left) to the previous input (at right). If I had connected the right inlet first, the patch would produce the correct output, but the problem remains the same: the execution order is not evident in the appearance of the patch.
-Jonathan
Jonathan Wilkes wrote:
Hi William, I would say that the meaning is clear for those of us who have patching habits in Pd. However, my main point is that the relevance is not clear, especially for people reading about Pd for the first time. I've heard and read at least five comments in the past year from people who have taken a cursory glance at Pd and found it necessary to mention they dislike the idea that "execution order is determined by the order in which connections are made." I know these people are aware of the
somewhere on my todo list is the task of committing a patch to miller, that truely randomizes the execution order where it is not made explicit. probably he won't include it (and it will break the example about execution-matters), though.
dfamr IOhannes
On Wed, 12 Aug 2009, IOhannes m zmoelnig wrote:
somewhere on my todo list is the task of committing a patch to miller, that truely randomizes the execution order where it is not made explicit. probably he won't include it (and it will break the example about execution-matters), though.
"If" this were accepted, in the future... then people would come to rely on that as being a randomiser for execution order, and so will be used wherever people want execution order to be randomised. Therefore, the correct way to get rid of the reliance on the builtin ordering, is to have Pd read their minds and do the opposite of what the user wants it to do.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
-
IOhannes m zmoelnig -
Jonathan Wilkes -
Mathieu Bouchard