Wish
- [inlet] and [outlet] should have numeric argument.
Rationale
Currently, [inlet] and [outlet] objects seem to number themselves according to their positioning in the canvas (AFAIK). This is a bad thing because:
- Behaviour should not depend on graphical appearance, except when
otherwise not possible to do so. For example, if several connections come out of an outlet, connections are treated in an unspecified order. It is considered a bug to rely on that ordering. (Is it? I don't know the puredata mindset enough for that)
- Each functionality must be accessible by at least one explicitly
specified behaviour. (i.e. unspecified behaviours do not count as a valid way to use a feature)
Does that make sense to anyone?
Mathieu Bouchard http://artengine.ca/matju
I agree. I think the inlet object should take several symbolic arguments. Your abstraction should then get that many inlets, and the little inlet object box should take on that many outlets. Data sent to the first inlet will both come out of the first outlet of the inlet object box, and be sent to the first name after "inlet", etc.. This would be much more orthogonal to the way the ui elements work. The position of an object should bear as little semantic load as possible.
Of course, inlet objects with *no* arguments should continue to work as they do now. Otherwise pretty much every patch in existence would break.
On Tue, 2003-05-06 at 15:44, Mathieu Bouchard wrote:
Wish
- [inlet] and [outlet] should have numeric argument.
Rationale
Currently, [inlet] and [outlet] objects seem to number themselves according to their positioning in the canvas (AFAIK). This is a bad thing because:
- Behaviour should not depend on graphical appearance, except when
otherwise not possible to do so. For example, if several connections come out of an outlet, connections are treated in an unspecified order. It is considered a bug to rely on that ordering. (Is it? I don't know the puredata mindset enough for that)
- Each functionality must be accessible by at least one explicitly
specified behaviour. (i.e. unspecified behaviours do not count as a valid way to use a feature)
Does that make sense to anyone?
Mathieu Bouchard http://artengine.ca/matju
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On 6 May 2003, jfm3 wrote:
I agree. I think the inlet object should take several symbolic arguments. Your abstraction should then get that many inlets, and the little inlet object box should take on that many outlets. Data sent to the first inlet will both come out of the first outlet of the inlet object box, and be sent to the first name after "inlet", etc.. This would be much more orthogonal to the way the ui elements work. The position of an object should bear as little semantic load as possible. Of course, inlet objects with *no* arguments should continue to work as they do now. Otherwise pretty much every patch in existence would break.
This is an interesting alternative to the (jMax-style) way that I proposed. Maybe I should have proposed the same thing as well, but I sticked to the non-broken solution that is closest to the PD-style. However your method sounds familiar because I am already using it in a dataflow system of my own, where object #-1 is the "flip side" of the patcher (its inlets are the patcher's outlets, and its outlets are the patcher's inlets). Naturally, for a visual system, it may be better to make that two separate objects like you propose.
(I'm still wondering which solution, the numbered [inlet]'s, or the single [inlet] with multiple outlets, is better.)
Mathieu Bouchard http://artengine.ca/matju
whie haveing all the inlets be outlets on the sub patches [inlet] object continues the same visual metaphore nicely, i think i'd prefer it to have 1 object per inlet, so if i have 4 inlets i have the objects :
[inlet 1] [inlet 2] [inlet 3] [inlet 4]
this would save a little bit of speghetti chord clutter for me :)
-josh
Mathieu Bouchard wrote:
On 6 May 2003, jfm3 wrote:
I agree. I think the inlet object should take several symbolic arguments. Your abstraction should then get that many inlets, and the little inlet object box should take on that many outlets. Data sent to the first inlet will both come out of the first outlet of the inlet object box, and be sent to the first name after "inlet", etc.. This would be much more orthogonal to the way the ui elements work. The position of an object should bear as little semantic load as possible. Of course, inlet objects with *no* arguments should continue to work as they do now. Otherwise pretty much every patch in existence would break.
This is an interesting alternative to the (jMax-style) way that I proposed. Maybe I should have proposed the same thing as well, but I sticked to the non-broken solution that is closest to the PD-style. However your method sounds familiar because I am already using it in a dataflow system of my own, where object #-1 is the "flip side" of the patcher (its inlets are the patcher's outlets, and its outlets are the patcher's inlets). Naturally, for a visual system, it may be better to make that two separate objects like you propose.
(I'm still wondering which solution, the numbered [inlet]'s, or the single [inlet] with multiple outlets, is better.)
Mathieu Bouchard http://artengine.ca/matju
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Wish
- [inlet] and [outlet] should have numeric argument.
Because...? It would break a lot of patches, I guess.
Rationale
Currently, [inlet] and [outlet] objects seem to number themselves according to their positioning in the canvas (AFAIK).
Yes.
This is a bad thing because:
- Behaviour should not depend on graphical appearance, except when
otherwise not possible to do so.
The position is saved in the patch file and thus can be deduced from reading the patch file (y-coordinate). In this regard it is not purely graphical.
For example, if several connections come out of an outlet, connections are treated in an unspecified order.
You're right, that this is a bit confusing. If several connections come out of an object, they should be considered to occur at the same time. For explicit ordering, the Max-languages use the [trigger] object.
It is considered a bug to rely on that ordering. (Is it? I don't know the puredata mindset enough for that)
Well, to rely on "unspecified order" isn't a bug, it's stupid. Pd behaves the same as jMax or Max in this, I guess (I didn't use both others very much, though). See [trigger] for how to specify order.
- Each functionality must be accessible by at least one explicitly
specified behaviour. (i.e. unspecified behaviours do not count as a valid way to use a feature)
See [trigger] again. Or maybe I missed the whole point?
ciao
Frank Barknecht _ ______footils.org__
Mathieu Bouchard wrote:
For example, if several connections come out of an outlet, connections are treated in an unspecified order.
Frank Barknecht replied :
You're right, that this is a bit confusing. If several connections come out of an object, they should be considered to occur at the same time. For explicit ordering, the Max-languages use the [trigger] object.
Included is a demonstration patch that shows the problem. I thought that messages were sent from right to left, in this very specific order, in every situations. But in many situations, the order is from left to right. Quite disturbing...
-- Marc
"We need not destroy the past. It is gone." (John Cage)
Correct me if I'm wrong, but I believe messages are sent out in the order the connections were originally made on the outlet. (First to be connected gets first msg, second gets second, etc.)
-Daniel
Marc Lavallée wrote:
Included is a demonstration patch that shows the problem. I thought that messages were sent from right to left, in this very specific order, in every situations. But in many situations, the order is from left to right. Quite disturbing...
Marc, the order that messages are passed down multiple patch chords coming from the same outlet is based on the order they were connected, not their right to left placement.
but if you ever depend strictly on the order you should really do your patch readers a favor and use a trigger object to keep things documented in a very explicit fashion.
-Josh
Included is a demonstration patch that shows the problem. I thought that messages were sent from right to left, in this very specific order, in every situations. But in many situations, the order is from left to right. Quite disturbing...
-- Marc
Josh Steiner wrote:
Marc, the order that messages are passed down multiple patch chords coming from the same outlet is based on the order they were connected, not their right to left placement.
So the order is not random as Mathieu was suggesting. But doesn't Max respects the right to left order? That's how I learned about Max in the first place. (I can't test it, I don't have a Macintosh up and running)
but if you ever depend strictly on the order you should really do your patch readers a favor and use a trigger object to keep things documented in a very explicit fashion.
That's what I do anytime I need to make sure the timing is correct, mostly because I move objects in the patch. But I'd like PD to respect the right to left order instead of the connection order. Would it be possible?
-- Marc
"Democracy is an abuse of statistics." (Jorge Luis Borges)
Hello all,
I've come to like the way PD handles this problem. In my understanding of PD and MAX, yes it's a little confusing moving from one program to another - always reminding myself "MAX = right to left", "PD = order of connections".
However, any mindful programmer appreciates having total control over the 'order of operations'. For this, PD's [trigger] object is a lifesaver...but to confuse the issue even further with numbered inlets and outlets would be a grand pain in the butt. Should we then number all send and receives too? Should we schedule EVERY object in the patch? That sort of practice seems both unnecessary and very time consuming.
Having said that, GEMhead allows us to schedule on-screen rendering. But in GEM, this functionality is clearly necessary.
[trigger] [trigger] [trigger] = that's really the answer to this problem.
The right-to-left order in MAX is problematic because an operation that is carefully constructed can be rendered completely useless (or at the very least unstable) if objects are moved on the screen.
The same problem can occur in PD if a patch cord is re-drawn (this may throw things out of whack if you're relying on single outlets to send messages through multiple patch cords).
In both MAX and PD, there are objects designed to schedule a series of events: in MAX there's [bangbang] and in PD there's [trigger]. These tools should be more than enough to appease even the most discriminating users.
In regards to scheduling/numbering inlets and outlets...I vote no on the grounds that it is not necessary as PD already provides this functionality via [trigger].
Regards, Dave S
David Sabine wrote :
However, any mindful programmer appreciates having total control over the 'order of operations'.
I much prefer the "right to left" graphical order than the connection order, because I never know in advance how I'll program a patch. Like I rearrange text in a procedural script, I'd like to move objects in a patch, knowing the new layout will make sense just by looking at it, not by remembering when the connections were actually created. I can't believe I spent years using PD without knowing about this major difference with Max...
-- Marc
"Health consists of having the same diseases as one's neighbors." (Quentin Crisp)
marc, its just not feasible to change that this late in the game, every sinlge pd patch ever writen would break if miller made this change.
-josh
Marc Lavallée wrote:
David Sabine wrote :
However, any mindful programmer appreciates having total control over the 'order of operations'.
I much prefer the "right to left" graphical order than the connection order, because I never know in advance how I'll program a patch. Like I rearrange text in a procedural script, I'd like to move objects in a patch, knowing the new layout will make sense just by looking at it, not by remembering when the connections were actually created. I can't believe I spent years using PD without knowing about this major difference with Max...
-- Marc
"Health consists of having the same diseases as one's neighbors." (Quentin Crisp)
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Josh Steiner wrote :
marc, its just not feasible to change that this late in the game, every single pd patch ever writen would break if miller made this change.
It would only break patches that depends on the connection order; since we mostly use [trigger] when timing is critical, it wouldn't break "that" many patches.
-- Marc
"It has yet to be proven that intelligence has any survival value." (Arthur C. Clarke)
On 6 May 2003, Marc Lavallée wrote:
Josh Steiner wrote :
marc, its just not feasible to change that this late in the game, every single pd patch ever writen would break if miller made this change.
It would only break patches that depends on the connection order; since we mostly use [trigger] when timing is critical, it wouldn't break "that" many patches.
Since neither outlet nor inlet currently has any arguments (as far as I know), it shouldn't break any patches if arguments were introduced.
Personally, I think the idea is very good.
In addition, I would very much like if created inlet and outlet objects automaticly get a unique color when created. (For example: green background -> inlet, red background -> outlet)
Kjetil S. Matheussen wrote:
On 6 May 2003, Marc Lavallée wrote:
Josh Steiner wrote :
marc, its just not feasible to change that this late in the game, every single pd patch ever writen would break if miller made this change.
It would only break patches that depends on the connection order; since we mostly use [trigger] when timing is critical, it wouldn't break "that" many patches.
Since neither outlet nor inlet currently has any arguments (as far as I know), it shouldn't break any patches if arguments were introduced.
Personally, I think the idea is very good.
In addition, I would very much like if created inlet and outlet objects automaticly get a unique color when created. (For example: green background -> inlet, red background -> outlet)
the context is getting lost in all the cutting people are doing :)
in my post quoted above i'm *not( talking about outlet/inlet numbers, i'm talking about marc's suggestion of changing execution order to be determined by right/left position rather than connection order.
On Wed, 7 May 2003, Josh Steiner wrote:
the context is getting lost in all the cutting people are doing :)
in my post quoted above i'm *not( talking about outlet/inlet numbers, i'm talking about marc's suggestion of changing execution order to be determined by right/left position rather than connection order.
Oops, sorry. Do that all the time. :( Thanks for telling me in such a polite manner. :)
On Tuesday 06 May 2003 20:01, David Sabine wrote:
Hello all,
I've come to like the way PD handles this problem. In my understanding of PD and MAX, yes it's a little confusing moving from one program to another
- always reminding myself "MAX = right to left", "PD = order of
connections".
However, any mindful programmer appreciates having total control over the 'order of operations'. For this, PD's [trigger] object is a lifesaver...but to confuse the issue even further with numbered inlets and outlets would be a grand pain in the butt. Should we then number all send and receives too? Should we schedule EVERY object in the patch? That sort of practice seems both unnecessary and very time consuming.
Unless I misunderstood the original poster, the problem has nothing to do at all with what order the inlets were fired in, but what order they appear in at the parent's object box.
I don't understand how this is at all related to the order of processing.
Again, unless I misunderstood, the question was this: If I put a number of inlets in my patch, how do I know which one will be the first, second, etc..
Larry
yeah, there were two simultaneous, separate but similar issues being discussed in one thread :) the threads started out with what you are talking about, and morphed into a discussion of the order of operations.
as for numbering the inlets/outlet, i'm all for it, i think it makes a
lot more sense then the physical positioning system we have now.
changing this wouldnt break older patches if the current functionality
was how the objects would continue to behave if you gave them no number
initialization argument.
-josh
Unless I misunderstood the original poster, the problem has nothing to do at all with what order the inlets were fired in, but what order they appear in at the parent's object box.
I don't understand how this is at all related to the order of processing.
Again, unless I misunderstood, the question was this: If I put a number of inlets in my patch, how do I know which one will be the first, second, etc..
Larry
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Tue, 6 May 2003, David Sabine wrote:
I've come to like the way PD handles this problem. In my understanding of PD and MAX, yes it's a little confusing moving from one program to another - always reminding myself "MAX = right to left", "PD = order of connections".
I seem to have distracted everyone from the real issue that I was trying to bring into light... talk about communication skills... ;-)
but to confuse the issue even further with numbered inlets and outlets would be a grand pain in the butt.
The numbering of [inlet] and [outlet] objects is not "confusing the issue" and is not even the same issue, although it is a problem in the same general category.
However the big problem with the current [inlet] is that if you have several of them inside a patcher or abstraction, then you cannot position them in a way that the first inlet is to the right of the second inlet, because then both inlets swap roles, which leads to messages coming into and out of the wrong objects.
Should we then number all send and receives too?
pointless and irrelevant.
[trigger] [trigger] [trigger] = that's really the answer to this problem.
That's not the problem I wanted to talk about. [trigger] does not solve the [inlet] problem.
The right-to-left order in MAX is problematic because an operation that is carefully constructed can be rendered completely useless (or at the very least unstable) if objects are moved on the screen.
if objects are moved on the screen. Have you tried moving [inlet]'s on the screen ?
These tools should be more than enough to appease even the most discriminating users.
It's been more than a few times that I've mentioned the shortcomings of [t]... doesn't anyone listen ?
In regards to scheduling/numbering inlets and outlets...I vote no on the grounds that it is not necessary as PD already provides this functionality via [trigger].
You haven't even considered the issue.
Mathieu Bouchard http://artengine.ca/matju
Hello,
<snip> >>> However the big problem with the current [inlet] is that if you have several of them inside a patcher or abstraction, then you cannot position them in a way that the first inlet is to the right of the second inlet, because then both inlets swap roles, which leads to messages coming into and out of the wrong objects. >>> if objects are moved on the screen. Have you tried moving [inlet]'s on the screen ? </snip>
If inlets in a subpatch are moved, as you said, the patch cords move with them. They do not swap roles. The merely change their location on the screen.
?
<snip> >>>> It's been more than a few times that I've mentioned the shortcomings of [t]... doesn't anyone listen ? </snip>
I haven't noticed those shortcomings that you've mentioned.
I understand that the issue you have raised is basically this: You want to plug something into an inlet on a sub-patch box. Then within the sub-patch, you want to route that message to ANY ONE of the [inlet] objects in that patch (regardless of its position on screen). You want to do this using a numbered system. In effect you want to re-route the messages to control both the order in which the operations are carried out in the sub-patch AND the virtual location of the objects on screen. Cannot the [send] and [receive] objects be used for this same general purpose?
Regards, Dave S
The earlier example including [t] objects when necessary so that messages and their 'flow-order' are consistent.
#N canvas 706 19 421 366 10; #X obj 39 78 metro 1000; #X obj 39 150 + 1; #X msg 39 125 1; #X obj 39 36 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #X obj 41 228 * 10; #X obj 118 70 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X msg 118 90 0; #X floatatom 39 173 5 0 0 0 - - -; #X obj 39 103 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 142 214 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #N canvas 532 24 281 190 addition 1; #X obj 34 29 inlet; #X obj 35 117 outlet; #X obj 35 82 + 2; #X obj 66 82 + 3; #X obj 105 51 inlet; #X obj 156 51 inlet; #X obj 105 117 outlet; #X obj 156 117 outlet; #X obj 105 82 + 4; #X obj 156 83 + 5; #X obj 34 50 t f f; #X connect 0 0 10 0; #X connect 2 0 1 0; #X connect 3 0 1 0; #X connect 4 0 8 0; #X connect 5 0 9 0; #X connect 8 0 6 0; #X connect 9 0 7 0; #X connect 10 0 2 0; #X connect 10 1 3 0; #X restore 88 279 pd addition; #X obj 41 334 print a; #X obj 106 334 print b; #X obj 48 279 + 1; #X text 63 45 start here; #X text 34 19 Order of messages is not always from right to left!; #X obj 39 56 t f b; #X obj 40 191 t f f b; #X obj 41 249 t f f f f f; #X obj 142 234 t b b; #X connect 0 0 8 0; #X connect 1 0 7 0; #X connect 2 0 1 0; #X connect 3 0 16 0; #X connect 4 0 18 0; #X connect 5 0 6 0; #X connect 6 0 1 1; #X connect 7 0 17 0; #X connect 8 0 2 0; #X connect 9 0 19 0; #X connect 10 0 12 0; #X connect 10 0 11 0; #X connect 10 1 12 0; #X connect 10 1 11 0; #X connect 10 2 12 0; #X connect 10 2 11 0; #X connect 13 0 12 0; #X connect 13 0 11 0; #X connect 16 0 0 0; #X connect 16 1 5 0; #X connect 17 0 1 1; #X connect 17 1 4 0; #X connect 17 2 9 0; #X connect 18 0 11 0; #X connect 18 1 13 0; #X connect 18 2 10 2; #X connect 18 3 10 1; #X connect 18 4 10 0; #X connect 19 0 11 0; #X connect 19 1 12 0;
On Tue, 6 May 2003 20:57:09 -0400 (EDT) Mathieu Bouchard matju@sympatico.ca wrote:
However the big problem with the current [inlet] is that if you have several of them inside a patcher or abstraction, then you cannot position them in a way that the first inlet is to the right of the second inlet, because then both inlets swap roles, which leads to messages coming into and out of the wrong objects.
...and you don't think readability would suffer if this was possible? after all, the visual order of the [inlet] objects inside the patch corresponds to the ordering of the connection points of the object when it appears in another patch.
if it were possible to have out-of-order inlets, then for readability they should probably be reserved for special cases where it doesn't make sense to the the processing in the area of the patch where the inlet object will lie. in which case, you could achieve the same thing easily by just draping a long patch cable across your patch, or using a send/receive pair, to get the data to where the processing will happen.
[trigger] [trigger] [trigger] = that's really the answer to this problem.
That's not the problem I wanted to talk about. [trigger] does not solve the [inlet] problem.
i kind of apologise for paying too much attention to your order-of-execution example, it seems to have spawned an alternate thread under the same subject heading. much conflation has ensued.
It's been more than a few times that I've mentioned the shortcomings of [t]... doesn't anyone listen ?
yes they listen, krystof said that the fact that [t a] munges bangs is a bug. if you know of any other situations where the input of [t a] differs from it's output, it is also a bug.
pix.
pix wrote:
On Tue, 6 May 2003 20:57:09 -0400 (EDT) Mathieu Bouchard matju@sympatico.ca wrote:
However the big problem with the current [inlet] is that if you have several of them inside a patcher or abstraction, then you cannot position them in a way that the first inlet is to the right of the second inlet, because then both inlets swap roles, which leads to messages coming into and out of the wrong objects.
...and you don't think readability would suffer if this was possible? after all, the visual order of the [inlet] objects inside the patch corresponds to the ordering of the connection points of the object when it appears in another patch.
if it were possible to have out-of-order inlets, then for readability they should probably be reserved for special cases where it doesn't make sense to the the processing in the area of the patch where the inlet object will lie. in which case, you could achieve the same thing easily by just draping a long patch cable across your patch, or using a send/receive pair, to get the data to where the processing will happen.
i dont think it would negatively effect readability since if you have an out of order inlet it would have a number specifying which inlet it is:
[inlet 2] [inlet 1]
On Wed, 7 May 2003, pix wrote:
Mathieu Bouchard matju@sympatico.ca wrote:
position them in a way that the first inlet is to the right of the second inlet, because then both inlets swap roles, which leads to messages coming into and out of the wrong objects.
...and you don't think readability would suffer if this was possible? after all, the visual order of the [inlet] objects inside the patch corresponds to the ordering of the connection points of the object when it appears in another patch.
This is a standard feature of jMax, and it never occurred to me that it might be a readability problem. Never heard a jMax user complain about it in any way. It seems to us like the normal way of doing things.
Mathieu Bouchard http://artengine.ca/matju
On Fri, 9 May 2003, Mathieu Bouchard wrote:
This is a standard feature of jMax, and it never occurred to me that it might be a readability problem. Never heard a jMax user complain about it in any way. It seems to us like the normal way of doing things.
Well, "we" get confused by that (at least me) :) But I think it is natural when one is not used to look at inlet numbers.
The question is if we want to get used it ...
Guenter
On Wed, 7 May 2003, pix wrote:
Mathieu Bouchard matju@sympatico.ca wrote: It's been more than a few times that I've mentioned the shortcomings of [t]... doesn't anyone listen ?
yes they listen, krystof said that the fact that [t a] munges bangs is a bug. if you know of any other situations where the input of [t a] differs from it's output, it is also a bug.
Actually the message I had written this in is the message that got lost; it appeared on the list ~24 hours later (when the thread had already calmed down); and I just got a message from my mailserver that denies it has ever been sent successfully.
weird.
Mathieu Bouchard http://artengine.ca/matju
On 6 May 2003, Marc Lavallée wrote:
Josh Steiner wrote:
Marc, the order that messages are passed down multiple patch chords coming from the same outlet is based on the order they were connected, not their right to left placement.
So the order is not random as Mathieu was suggesting. But doesn't Max respects the right to left order? That's how I learned about Max in the first place. (I can't test it, I don't have a Macintosh up and running)
This is a particular meaning of random. Actually for better clarity I should have called this the prolly-not-what-you-want order, or the unreliable order, or the you-don't-see-it-on-the-screen order, or arbitrary order, or actually all of the above.
That's what I do anytime I need to make sure the timing is correct, mostly because I move objects in the patch. But I'd like PD to respect the right to left order instead of the connection order. Would it be possible?
coming from jMax I would tend to stick with the PD/jMax way, but would like PD to get the currently-jMax-specific improvements, which are numbered [inlet]/[outlet] objects, and the [fork] object.
BTW: I have a system in which patchers are scripted, and so they contain objects that have no position at all. How does your model fit with that? Is there a way (of doing, and/or, of thinking about it) that is elegant with both visual and non-visual systems ?
Mathieu Bouchard http://artengine.ca/matju
On Tue, 6 May 2003, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Wish
- [inlet] and [outlet] should have numeric argument.
Because...? It would break a lot of patches, I guess.
No, obviously, backward compatibility can be kept by omitting the argument; I mean, the way I propose does not conflict with the current way.
The position is saved in the patch file and thus can be deduced from reading the patch file (y-coordinate). In this regard it is not purely graphical.
Well duh, it's saved in the patch file. It _has_ to be saved in the patch file, else the users would be mad. But I call it graphical anyway. (How would _you_ call it, then ?)
For example, if several connections come out of an outlet, connections are treated in an unspecified order.
You're right, that this is a bit confusing.
I am not saying that this is confusing, I am saying that this is an example of unspecified behaviour. I didn't say that unspecified behaviours are confusing either. I did mean that some things are meant to be naturally left unspecified, and that in that case, another means should be there to allow one to control the behaviour explicitly. In this example, there is [t] (which you mentioned), although it is a kludge (see my mail about [t a a] messing with some messages' contents)
Well, to rely on "unspecified order" isn't a bug, it's stupid.
A "bug" is not necessarily something that doesn't work *now*. I know a lot of bugs (bug types) that only occur once in a while randomly. Well, they still are bugs. Relying on unspecified behaviour is, to me, a bug.
- Each functionality must be accessible by at least one explicitly
specified behaviour. (i.e. unspecified behaviours do not count as a valid way to use a feature)
See [trigger] again. Or maybe I missed the whole point?
You missed the whole point. This example was only used to illustrate the rationale behind my solution to the issue with [inlet]/[outlet]. The numeric argument thereof (specifying inlet/outlet number) would be to the [inlet]/[outlet] problem what [t] is to the connection-ordering problem.
Mathieu Bouchard http://artengine.ca/matju
i agree also.
just to be pedantic, having numeric arguments for inlets won't explicitly solve the "multiple connections from an outlet" problem. mutiple inlets with the same number would still be triggered in some unspecified order. the solution here is always to use a trigger if order of operations is important. it's safe to not use a trigger when operations can really occur in any order. theoretically computation could occur in parallel in these cases.
pix
On Tue, 6 May 2003 15:44:51 -0400 (EDT) Mathieu Bouchard matju@sympatico.ca wrote:
Wish
- [inlet] and [outlet] should have numeric argument.
Rationale
Currently, [inlet] and [outlet] objects seem to number themselves according to their positioning in the canvas (AFAIK). This is a bad thing because:
- Behaviour should not depend on graphical appearance, except when
otherwise not possible to do so. For example, if several connections come out of an outlet, connections are treated in an unspecified order. It is considered a bug to rely on that ordering. (Is it? I don't know the puredata mindset enough for that)
- Each functionality must be accessible by at least one explicitly
specified behaviour. (i.e. unspecified behaviours do not count as a valid way to use a feature)
Does that make sense to anyone?
Mathieu Bouchard http://artengine.ca/matju
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Tue, 6 May 2003, pix wrote:
- [inlet] and [outlet] should have numeric argument.
- Behaviour should not depend on graphical appearance, except when
otherwise not possible to do so. For example, if several connections come out of an outlet, connections are treated in an unspecified order. It is considered a bug to rely on that ordering. (Is it? I don't know the puredata mindset enough for that)
just to be pedantic, having numeric arguments for inlets won't explicitly solve the "multiple connections from an outlet" problem. mutiple inlets with the same number would still be triggered in some unspecified order. the solution here is always to use a trigger if order of operations is important. it's safe to not use a trigger when operations can really occur in any order. theoretically computation could occur in parallel in these cases.
I don't call this being pedantic, I call it being mistaken about my intention. I was using the "multiple connections from an outlet" problem to make a parallel: the link between that and the case for [inlet]/[outlet] arguments stops there; the parallel was about unspecified behaviour in general.
About trigger. I actually prefer [fork], as it only orders messages and nothing else, while [t a a] mangles a certain number of messages: for example, bang gets transformed into a list containing a single element 0.0 ???
Mathieu Bouchard http://artengine.ca/matju
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
I don't call this being pedantic, I call it being mistaken about my intention. I was using the "multiple connections from an outlet" problem to make a parallel: the link between that and the case for [inlet]/[outlet] arguments stops there; the parallel was about unspecified behaviour in general.
I *did* miss the whole point in my previous mail and I was mistaken about you intention. So personally I probably wouldn't use numbered outlets very much, as I'm used to the "graphical" way but I see their place.
ciao
Frank Barknecht _ ______footils.org__
hi Mathieu,
is it just my false impression, that the bang is the only message mangled by [t a]? I have always considered this to be a bug (reported...)
So, are there other messages converted by [t a]?
Btw, I do see the point in your quest for (optionally) numbered inlets/outlets. The specialized subpatchers of msp have numbered in/outs, while the regular subpatchers have unnumbered inlets/outlets. People, even if confused at first, easily come to terms with using both ways in their work.
But how to make them into Pd without breaking other things, is quite another matter...
Krzysztof
Mathieu Bouchard wrote:
About trigger. I actually prefer [fork], as it only orders messages and nothing else, while [t a a] mangles a certain number of messages: for example, bang gets transformed into a list containing a single element 0.0 ???
the more i think about it, the more i become a fan of the existing way of doing things ;)
the importance of horizontal order makes it easier to see which connection points on the object correspond to which [inlets] in the patch. with numbered inlet, this would just become a convention, and would make for some needlessly hard to understand patches.
if you are dynamically generating patches and don't want to worry about display (so most objects are created at 0,0), perhaps just put the number that you would have put as a parameter to [inlet] in the x value of the object. eg, inlet 1 is drawn at 1,0 and inlet 2 is drawn at 2,0 etc.
pix.
On Wed, 07 May 2003 11:07:01 +0200 Krzysztof Czaja czaja@chopin.edu.pl wrote:
hi Mathieu,
is it just my false impression, that the bang is the only message mangled by [t a]? I have always considered this to be a bug (reported...)
So, are there other messages converted by [t a]?
Btw, I do see the point in your quest for (optionally) numbered inlets/outlets. The specialized subpatchers of msp have numbered in/outs, while the regular subpatchers have unnumbered inlets/outlets. People, even if confused at first, easily come to terms with using both ways in their work.
But how to make them into Pd without breaking other things, is quite another matter...
Krzysztof
Mathieu Bouchard wrote:
About trigger. I actually prefer [fork], as it only orders messages and nothing else, while [t a a] mangles a certain number of messages: for example, bang gets transformed into a list containing a single element 0.0???
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Wed, 7 May 2003 11:16:53 +0200 pix wrote:
the more i think about it, the more i become a fan of the existing way of doing things ;)
Actually, I think I can relate to that...
Re: intlets/outlets I think it makes a lot of sense, for a visual programming environment, if the (visual) order of inlets & outlets in the subpatch/abstraction is reflected on the parent. I haven't used jMax but Max works in the same way. Not that I care much for Max these days but if there is some work being done by some of the developers to make PD read Max patches (and vice versa?) then a different behaviour would create more, unnecessary, confusion. Not to mention the compatibility with older PD patches.
Re: order of messages Coming from Max, it has been a little confusing. But I do recall problems with that 'functionnality' in Max. [trigger] has been of great help both in Max and PD. While, in some situations, a specified order would be welcome, I would probably use [trigger] anyways, just to be sure.
I will allow myself to branch off to a different issue of inlet/outlet behaviour. What I really miss from Max is the inlet/outlet comment so that I don't have to open a subpatch/abstraction to know what inlet/outlet does what. IMHO this should be higher on a priority list re:inlets/outlets.
cheers
./MiS
On Wed, 07 May 2003 09:43:29 -0500 Michal Seta mis@creazone.32k.org wrote:
Re: order of messages Coming from Max, it has been a little confusing. But I do recall problems with that 'functionnality' in Max. [trigger] has been of great help both in Max and PD. While, in some situations, a specified order would be welcome, I would probably use [trigger] anyways, just to be sure.
i like the idea of leaving the order strictly unspecified, as this allows for the possibility of doing things in parallel at some distant point in the future. the first time i came across the max-like way of representing programs was as a description of how to write parallel programs.
I will allow myself to branch off to a different issue of inlet/outlet behaviour. What I really miss from Max is the inlet/outlet comment so that I don't have to open a subpatch/abstraction to know what inlet/outlet does what. IMHO this should be higher on a priority list re:inlets/outlets.
that would rock! :)
pix.
I think I agree that changes in the direction of Max/MSP compatibility would be Good Things. I think that and a numbering scheme could be made to coexist, like: "inlet 5", "inlet frequency", "inlet float frequency 5", etc, so that you could specify any/all of the type, a name, and an ordering.
hmm...
cheers Miller
On Wed, May 07, 2003 at 03:56:14PM +0200, pix wrote:
On Wed, 07 May 2003 09:43:29 -0500 Michal Seta mis@creazone.32k.org wrote:
Re: order of messages Coming from Max, it has been a little confusing. But I do recall problems with that 'functionnality' in Max. [trigger] has been of great help both in Max and PD. While, in some situations, a specified order would be welcome, I would probably use [trigger] anyways, just to be sure.
i like the idea of leaving the order strictly unspecified, as this allows for the possibility of doing things in parallel at some distant point in the future. the first time i came across the max-like way of representing programs was as a description of how to write parallel programs.
I will allow myself to branch off to a different issue of inlet/outlet behaviour. What I really miss from Max is the inlet/outlet comment so that I don't have to open a subpatch/abstraction to know what inlet/outlet does what. IMHO this should be higher on a priority list re:inlets/outlets.
that would rock! :)
pix.
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
i agree. this seems to meet many peoples needs and will cause no breakage. and yes, being able to specify a name and datatype would be a great boon to usability for new users. every time i teach pd to someone they always feel kind of overwhealmed trying to remember what each inlet/outlet does.
-josh
Miller Puckette wrote:
I think I agree that changes in the direction of Max/MSP compatibility would be Good Things. I think that and a numbering scheme could be made to coexist, like: "inlet 5", "inlet frequency", "inlet float frequency 5", etc, so that you could specify any/all of the type, a name, and an ordering.
hmm...
cheers Miller
hi Michal,
the point is about adding a numbering argument only as an option, which would not break neither old Pd patches, nor max import feature.
For a developer who works on making Pd read Max patches (but not vice versa...), the real trouble is that there are no [inlet~]s and [outlet~]s, in msp, just the 'mixlets'. Right now, any imported msp patch has to be manually adjusted. I will try to add an additional parsing pass in order to account for that, eventually, but I am pretty certain, this would not work for any patch.
You are right, though, the numbered i/o, even if useful, is not the top priority now, after so much work has been done without...
Krzysztof
Michal Seta wrote: ...
I think it makes a lot of sense, for a visual programming environment, if the (visual)
order of inlets & outlets in the subpatch/abstraction is reflected on the parent. I haven't used jMax but Max works in the same way. Not that I care much for Max these days but if there is some work being done by some of the developers to make PD read Max patches (and vice versa?) then a different behaviour would create more, unnecessary, confusion. Not to mention the compatibility with older PD patches.
Le mer 07/05/2003 à 10:43, Michal Seta a écrit :
I will allow myself to branch off to a different issue of inlet/outlet behaviour. What I really miss from Max is the inlet/outlet comment so that I don't have to open a subpatch/abstraction to know what inlet/outlet does what.
This mechanism should be implemented for all objects, not only for the [inlet] and [outlet] objects. The comments associated with the objects in/outs could be displayed in a status bar. Multiple languages would be nice too (I still think better in french than in english).
-- Marc
"Creationists make it sound as though a 'theory' is something you dreamt up after being drunk all night." (Isaac Asimov)
I will allow myself to branch off to a different issue of inlet/outlet behaviour. What I really miss from Max is the inlet/outlet comment so that I don't have to open a subpatch/abstraction to know what inlet/outlet does what.
This mechanism should be implemented for all objects, not only for the [inlet] and [outlet] objects. The comments associated with the objects in/outs could be displayed in a status bar. Multiple languages would be nice too (I still think better in french than in english).
small remark
i would prefer tooltips to a status bar, since the information is placed where i look at.
also:
if bindings of chords and in/outlets is on (t_)symbol level, the order does not matter this much....
martin
-- Marc
"Creationists make it sound as though a 'theory' is something you dreamt up after being drunk all night." (Isaac Asimov)
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
martin pi
http://attacksyour.net/pi
www.machfeld.net
On Wed, 7 May 2003, Krzysztof Czaja wrote:
is it just my false impression, that the bang is the only message mangled by [t a]? I have always considered this to be a bug (reported...) So, are there other messages converted by [t a]?
well, using [print] I cannot see any difference, but using [rubyprint], I can see one by sending a float both through [t a] and directly to [rubyprint]:
[gf] float: [35.0] [gf] list: [35.0]
so [t a] wraps the float in a one-element list, which makes a difference to GridFlow, because it sees a float as a "scalar" (0-D grid) and a list as a "vector" (1-D grid)
the same happens for symbol messages like [symbol foo( :
[gf] symbol: [:foo] [gf] list: [:foo]
Btw, I do see the point in your quest for (optionally) numbered inlets/outlets. The specialized subpatchers of msp have numbered in/outs, while the regular subpatchers have unnumbered inlets/outlets.
People, even if confused at first, easily come to terms with using both ways in their work. But how to make them into Pd without breaking other things, is quite another matter...
Yeah, I never saw [inlet] with an argument. I don't really know much about PD, so sometimes my ideas may look weird.
I asked for that not only as an attempt to make PD "cleaner" (in the sense that object position should not have significant effect on the behaviour), but also to improve compatibility with jMax. One of my .jmax files doesn't convert to .pd _because_ of this. I guess I'm stuck with adding code to the converter to reorder the positions of [inlet] objects anyway. This may screw the layout but it's not like the layout of converted patches is not already quite screwed.
Mathieu Bouchard http://artengine.ca/matju
hi again,
Mathieu Bouchard wrote: ...
so [t a] wraps the float in a one-element list, which makes a difference
true (as always). Same for rejection outlet of [route], btw.
I think there is a convention of 'float 99' and 'list 99' being the same thing (also 'symbol dog' and 'list dog', likewise 'bang' and empty 'list').
If an object expects only a float, or only a list, it simply cannot tell, whether it has been sent 'float 99' or 'list 99'. But if an object has both methods declared (or only the 'anything' method), it can, so it is only by a convention, that there should not be any differentiation of behaviour.
Well, the typing rules in Pd are a bit tricky indeed, perhaps they are explained in some place (IOhannes' docs?), I do not know...
...
but also to improve compatibility with jMax. One of my .jmax files doesn't convert to .pd _because_ of this. I guess I'm stuck with adding code to the converter to reorder the positions of [inlet] objects anyway. This may screw the layout but it's not like the layout of converted patches is not already quite screwed.
very much true -- same about importing poly~ized msp abstractions.
Krzysztof
Hi all,
I always intended for "float 99" and "list 99" to be exactly equivalent in Pd. I think this has caused problems in trying to make certain objects compatible with Max, in which they may be treated distinctly (but never really _should_, I don't think, since it's too comfusing. Also, "list" with no argument is the same as "bang"...
cheers Miller
On Thu, May 08, 2003 at 02:23:58PM +0200, Krzysztof Czaja wrote:
hi again,
Mathieu Bouchard wrote: ...
so [t a] wraps the float in a one-element list, which makes a difference
true (as always). Same for rejection outlet of [route], btw.
I think there is a convention of 'float 99' and 'list 99' being the same thing (also 'symbol dog' and 'list dog', likewise 'bang' and empty 'list').
If an object expects only a float, or only a list, it simply cannot tell, whether it has been sent 'float 99' or 'list 99'. But if an object has both methods declared (or only the 'anything' method), it can, so it is only by a convention, that there should not be any differentiation of behaviour.
Well, the typing rules in Pd are a bit tricky indeed, perhaps they are explained in some place (IOhannes' docs?), I do not know...
...
but also to improve compatibility with jMax. One of my .jmax files doesn't convert to .pd _because_ of this. I guess I'm stuck with adding code to the converter to reorder the positions of [inlet] objects anyway. This may screw the layout but it's not like the layout of converted patches is not already quite screwed.
very much true -- same about importing poly~ized msp abstractions.
Krzysztof
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Thursday 08 May 2003 21:14, Miller Puckette wrote:
Hi all,
I always intended for "float 99" and "list 99" to be exactly equivalent in Pd. I think this has caused problems in trying to make certain objects compatible with Max, in which they may be treated distinctly (but never really _should_, I don't think, since it's too comfusing. Also, "list" with no argument is the same as "bang"...
cheers Miller
Oh man. For some reason, I still have some kind of mental block to understanding how the PD type system works. Once I thought I understood, until I read message such as these on the list, that throw me into confusion again.
Is there a document somewhere that is current and that explains all of this?
I am sooo confused!!!!
For example, Miller, you say that "float 99" should be equivalent to "list 99".
Now, first of all, one would think that a list of one element is not equivalent to a single element by itself (at least coming from the lisp world). Actually, though, this is easily resolved, since you could consider a PD atom as equivalent to a single-atom PD list.
The bigger question is, to my mind, is why "list 99" is equivalent to "float 99" and not just "99". Presumably, the atom after "list" is somehow automatically interpreted to be a float, so then why in the non-list case, do we need "float 99" and not just "99"?
Larry
On Thu, 8 May 2003, Miller Puckette wrote:
I always intended for "float 99" and "list 99" to be exactly equivalent in Pd. I think this has caused problems in trying to make certain objects compatible with Max, in which they may be treated distinctly (but never really _should_, I don't think, since it's too comfusing. Also, "list" with no argument is the same as "bang"...
Given that an object is different from a single-element list/array containing it, when programming in C/C++, Pascal/Delphi, Java, C#, BASIC, ADA, Perl, Python, Ruby, Lua, PHP, TCL, CommonLisp, Scheme, Smalltalk, Self, Javascript, APL, Prolog, ML, Haskell, Max, jMax,
... then I don't know why PD would do things differently.
I can't name a major language doing it the PD way. I can't even name a minor language doing it the PD way (though there probably are).
And then from the perspective of GridFlow: it has to follow the APL data model, so it has to make the difference between a scalar, a 1-vector, a 1x1-matrix, and so on.
Then in the portability layer of GridFlow (which lies between PD/jMax and GridFlow proper), an empty message is converted to a bang message, but an empty list is not the same as an empty message: an empty list is a list message with no arguments.
that is:
foo.send_in 0 # sends a bang in inlet 0 foo.send_in 0, :bang # sends a bang also foo.send_in 0, :list # sends an empty list foo.send_in 0, 1.618034 # sends a float foo.send_in 0, :float, 1.618034 # sends a float too foo.send_in 0, :list, 1.618034 # sends a 1-element list
Now, I can understand that "bang" is sort-of like "void" which is sort-of like "nil" which in some languages is also equated with empty-lists, but it seems to me much less justifiable to equate single-element lists with their contents. Maybe I'd like some more explanation of this.
(PS: in some of the aforementioned languages, there are some ways that the single-element list can be conflated with its content, but usually it's as a shorthand or otherwise secondary usage: it only goes on top of the more basic concepts).
Mathieu Bouchard http://artengine.ca/matju
hi Mathieu,
sorry for jumping in like that...
It seems to me, that Pd message is not a data structure. It is more like a command in tcl -- just a command name (selector) and arguments (atoms).
So, it is probably safer not to think about message selector as of the message type. Typed entities are atoms. If you want to build hierarchical data structures in Pd, there is a pointer atom type.
(Of course, unlike tcl commands, Pd messages do not nest, Pd does neither grouping, nor substitution, etc... unless one would have liked to see the parallel between 'list 99' becoming 'float 99' in Pd and [list 99] evaluating to 99 in tcl...)
Ok, my remarks might very well be off target, etc.
Krzysztof
Mathieu Bouchard wrote: ...
C/C++, Pascal/Delphi, Java, C#, BASIC, ADA, Perl, Python, Ruby, Lua, PHP, TCL, CommonLisp, Scheme, Smalltalk, Self, Javascript, APL, Prolog, ML, Haskell, Max, jMax,
On Mon, 12 May 2003, Krzysztof Czaja wrote:
It seems to me, that Pd message is not a data structure. It is more like a command in tcl -- just a command name (selector) and arguments (atoms).
Well, due to Tcl's LISPish heritage, a command in Tcl is closer to a list than in pretty much any other non-LISP language... look at the command called "unknown": unhandled commands get sent there, and the command name becomes just another arg. Afaik that's what Tk uses to simulate OO method calling, but then the command name is interpreted as a widget name, and then the *next* argument gets interpreted as the command name... and it all looks pretty consistent syntax-wise. Here the selector is merely yet another atom.
So, it is probably safer not to think about message selector as of the message type.
Maybe not "message type", but when you have a single value passed "as if it were" a message, then it's the convention that the selector represents the type of the value, at least in PD/jMax2.
unless one would have liked to see the parallel between 'list 99' becoming 'float 99' in Pd and [list 99] evaluating to 99 in tcl...)
In Tcl, there are no types at all (or actually typing are an optimisation that is not part _at all_ of the language specification, and wasn't there until version _8_). This is what allows the same data to be reparsed as both float and list. I don't see an equivalent in PD.
Mathieu Bouchard http://artengine.ca/matju
i don't think it is a good idea to have order-numbers in inlets, would be more confusing like it is now, because there would be a bunch of new rules with that problem... what, if two inlets have the same number, what if one inlet has a number, and another has not? if i add a new inlet with id 1, would then all other inlets be updated and risen by one?...
but: i could imagine an argument telling about the number of inlets one inlet-object represents. so inlet 4 would create 4 inlets and i would not need to generate 4 seperate objects.
(and please no change to the order of messages from "in_the _order_created" to "left_to_right" in the patch. in my early patches i never used trigger... and i prefer this to max-style)
marius.
----- Original Message ----- From: "Mathieu Bouchard" matju@sympatico.ca To: pd-list@iem.kug.ac.at Sent: Tuesday, May 06, 2003 9:44 PM Subject: [PD] [inlet], [outlet].
Wish
- [inlet] and [outlet] should have numeric argument.
Rationale
Currently, [inlet] and [outlet] objects seem to number themselves according to their positioning in the canvas (AFAIK). This is a bad thing because:
- Behaviour should not depend on graphical appearance, except when
otherwise not possible to do so. For example, if several connections come out of an outlet, connections are treated in an unspecified order. It is considered a bug to rely on that ordering. (Is it? I don't know the puredata mindset enough for that)
- Each functionality must be accessible by at least one explicitly
specified behaviour. (i.e. unspecified behaviours do not count as a valid way to use a feature)
Does that make sense to anyone?
Mathieu Bouchard http://artengine.ca/matju
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
(and please no change to the order of messages from "in_the
_order_created"
to "left_to_right" in the patch. in my early patches i never used
trigger...
and i prefer this to max-style)
Uh oh. Ok, it's personal taste which style to prefer, but how would you change things in the patch a year after you have created it? You'd have to recreate all connections in the new order. This i find very tiring. To my mind it's extremely important to see (in which way ever) instantly how the order is. In this sense i would really like to have the Max style also for PD.
best greetings, Thomas
Thomas Grill said:
Uh oh. Ok, it's personal taste which style to prefer, but how would you change things in the patch a year after you have created it?
no, there are facts of advantage and disadvantage. on the one hand you have a "readeable" patch (readeable in the meaning of readeable for programmers). on the one hand you have no restrictions of placing the objects in your patch. i work with a rather small display of 1024*768 pix, so space and efficiency in placing is one of my biggest problems. therefore every trigger-object is luxury... and i try to have my connections short, straight and not crisscrossing other objects. (because in pd it is not possible to hide connections...). therefore i think it is a good solution the way it is.
marius.
hi Thomas, marius...
the order is declared to be *undefined*, not ``as created''.
The ``as created'' order should be regarded as a mere implementation detail, which may be changed in any future Pd release (as already had been once in the past, afaik).
I would not agree that the original (i.e. the max) way is any 'better'. Max patch may be broken just by someone moving an object (a sink) on screen.
rsKzytfzo
Thomas Grill wrote:
(and please no change to the order of messages from "in_the
_order_created"
...
To my mind it's extremely important to see (in which way ever) instantly how the order is. In this sense i would really like to have the Max style also for PD.
the order is declared to be *undefined*, not ``as created''.
Thanks Krzysztof for saying this clearly, I had a hard time reading through this thread of misinformation and confusion.
As to the inlet number argument: -) AFAIK there is already an argument for inlets, which is used for resampling, hence the implementation would cause a change in functionality and all the patches that use resampling would probably be broken.
-) Personally I would prefer the unnumbered inlets, I think the "one object that creates several inlets" idea would be a nice alternative to Mathieu's proposal.
-) trigger is not a kludge, if it has a bug, you are free to send a patch.
Greetings,
Guenter
On Wed, 7 May 2003, Krzysztof Czaja wrote:
hi Thomas, marius...
The ``as created'' order should be regarded as a mere implementation detail, which may be changed in any future Pd release (as already had been once in the past, afaik).
I would not agree that the original (i.e. the max) way is any 'better'. Max patch may be broken just by someone moving an object (a sink) on screen.
rsKzytfzo
Thomas Grill wrote:
(and please no change to the order of messages from "in_the
_order_created"
...
To my mind it's extremely important to see (in which way ever) instantly how the order is. In this sense i would really like to have the Max style also for PD.
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
ok, aparently i was spreading misinformation about order being determined by the order the objects were connected, i just found out where i got that idea, its in the documentation:
pd/doc/1.manual/x5.htm
In Max/MSP, if an object's outlet is connected to several destinations, corresponding messages are always sent in right-to-left screen order. In Pd, the messages are sent in the order you made the connections in. In either case, in situations where you care about the order it's appropriate to use a "trigger" object to specify.
if indeed this is meant to be "undefined" behavior that might change at some point in the future, this document really should be changed to reflect that.
-josh
guenter geiger wrote:
the order is declared to be *undefined*, not ``as created''.
Thanks Krzysztof for saying this clearly, I had a hard time reading through this thread of misinformation and confusion.
As to the inlet number argument: -) AFAIK there is already an argument for inlets, which is used for resampling, hence the implementation would cause a change in functionality and all the patches that use resampling would probably be broken.
-) Personally I would prefer the unnumbered inlets, I think the "one object that creates several inlets" idea would be a nice alternative to Mathieu's proposal.
-) trigger is not a kludge, if it has a bug, you are free to send a patch.
Greetings,
Guenter
On Wed, 7 May 2003, Krzysztof Czaja wrote:
hi Thomas, marius...
The ``as created'' order should be regarded as a mere implementation detail, which may be changed in any future Pd release (as already had been once in the past, afaik).
I would not agree that the original (i.e. the max) way is any 'better'. Max patch may be broken just by someone moving an object (a sink) on screen.
rsKzytfzo
Thomas Grill wrote:
(and please no change to the order of messages from "in_the
_order_created"
...
To my mind it's extremely important to see (in which way ever) instantly how the order is. In this sense i would really like to have the Max style also for PD.
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi all,
I believe the order is undefined, and nonetheless in Pd's implementation it's in the order the connections were made in (and in Max's, it's right to left)... in other words, patches whose behavior depends on the order of connection might break when ported from one program to the other...
cheers Miller
On Wed, May 07, 2003 at 10:48:03AM -0700, Josh Steiner wrote:
ok, aparently i was spreading misinformation about order being determined by the order the objects were connected, i just found out where i got that idea, its in the documentation:
pd/doc/1.manual/x5.htm
In Max/MSP, if an object's outlet is connected to several destinations, corresponding messages are always sent in right-to-left screen order. In Pd, the messages are sent in the order you made the connections in. In either case, in situations where you care about the order it's appropriate to use a "trigger" object to specify.
if indeed this is meant to be "undefined" behavior that might change at some point in the future, this document really should be changed to reflect that.
-josh
guenter geiger wrote:
the order is declared to be *undefined*, not ``as created''.
Thanks Krzysztof for saying this clearly, I had a hard time reading through this thread of misinformation and confusion.
As to the inlet number argument: -) AFAIK there is already an argument for inlets, which is used for resampling, hence the implementation would cause a change in functionality and all the patches that use resampling would probably be broken.
-) Personally I would prefer the unnumbered inlets, I think the "one object that creates several inlets" idea would be a nice alternative to Mathieu's proposal.
-) trigger is not a kludge, if it has a bug, you are free to send a patch.
Greetings,
Guenter
On Wed, 7 May 2003, Krzysztof Czaja wrote:
hi Thomas, marius...
The ``as created'' order should be regarded as a mere implementation detail, which may be changed in any future Pd release (as already had been once in the past, afaik).
I would not agree that the original (i.e. the max) way is any 'better'. Max patch may be broken just by someone moving an object (a sink) on screen.
rsKzytfzo
Thomas Grill wrote:
(and please no change to the order of messages from "in_the
_order_created"
...
To my mind it's extremely important to see (in which way ever) instantly how the order is. In this sense i would really like to have the Max style also for PD.
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
-- ____________________________________________________ independent u.s. drum'n'bass -- http://vitriolix.com
by the way, when developers say something like "the order is random", it doesn't really mean random in the traditional sense, it means "unspecified". sure, it will have some order, and it might even be repeatable, but given that it isn't easy to find out what that order is just by looking at the rendered patch (assuming you don't enjoy looking at the .pd contents directly), and that it takes an inordinate amount of effort (or dumb luck) to get the order you want using this method, the resulting order is considered "random".
and perhaps the fact that describing something as random is supposed to make people _less_ inclined to use it, says something interesting about developers in general ;)
if someone has been relying on this "random" order, i would suggest they have been exploiting a bug and should expect their patches to break in later versions.
just the way i'm expecting nqpoly to break any version now ;)
pix.
On Wed, 7 May 2003 09:11:17 +0200 "Thomas Grill" t.grill@gmx.net wrote:
(and please no change to the order of messages from "in_the
_order_created"
to "left_to_right" in the patch. in my early patches i never used
trigger...
and i prefer this to max-style)
Uh oh. Ok, it's personal taste which style to prefer, but how would you change things in the patch a year after you have created it? You'd have to recreate all connections in the new order. This i find very tiring. To my mind it's extremely important to see (in which way ever) instantly how the order is. In this sense i would really like to have the Max style also for PD.
best greetings, Thomas
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
-
Daniel Hawthorn -
David Sabine -
Frank Barknecht -
guenter geiger -
jfm3 -
Josh Steiner -
Kjetil S. Matheussen -
Krzysztof Czaja -
Larry Troxler -
Marc Lavallée -
marius schebella -
martin pi -
Mathieu Bouchard -
Michal Seta -
Miller Puckette -
pix -
Thomas Grill