Mathieu Bouchard wrote (and a few other people wrote something similar):
$0 in objectboxes is already inconsistent with $1,$2,$3,... in objectboxes, so, it's not clear that $0 in messagebox has to be consistent with anything at all.
$0 is inconsistent with $1, $2 etc strictly speaking, but you may think of $0 as of an "implicit creation argument". The name $0 has the same scope of the names $1,$2, in the sense that: in any two places where two $0's would have the same value, two $1's would have the same value. Both are values that are generated at the time of creating the object (semantically I mean, I don't know if it is so in implementation and it is irrelevant) and don't change later. So it is not *so* inconsistent.
Making $0 mean in a message the same it means in an object box, would make it *a lot* more inconsistent with $1,$2 in messages than $0 is with $1,$2 in object boxes. $1,$2... in messages are evaluated at the time the message box receives its input and generates its output; they are arguments of the message it receives. The "natural" object-counterpart of $0 would be a number that is unique to that particular message event (not message box) or message tree, though that would be of little or no use..... or wouldn't it?
Also, consider the following goal: (*) give direct access to (implicit and explicit) creation arguments ($n) of the patch within a message
Making $0 mean the same in a message box than outside it would address goal (*) only for the particular case of $0 and not for n>0, and I personally think this isn't an elegant approach. Also, any future attempt to address (*) for n>0, would probably result more difficult or have to be more inconsistend if the $0 case has been treated this way.
I am personally strongly against implementing $0 in messages meaning the same as $0 outside them. It would introduce further inconsistence. If there actually is some inconsistence now, it is not a good reason imho to deliberately introduce more inconsistence.
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6905&d=17-8
You know what, all along the hundreds of lines I've been reading in the list about $0, I don't get a single consistent reason why it hasn't the same behavior in object and message boxes.
Matteo Sisti Sette a écrit :
Mathieu Bouchard wrote (and a few other people wrote something similar):
$0 in objectboxes is already inconsistent with $1,$2,$3,... in objectboxes, so, it's not clear that $0 in messagebox has to be consistent with anything at all.
$0 is inconsistent with $1, $2 etc strictly speaking, but you may think of $0 as of an "implicit creation argument". The name $0 has the same scope of the names $1,$2, in the sense that: in any two places where two $0's would have the same value, two $1's would have the same value. Both are values that are generated at the time of creating the object (semantically I mean, I don't know if it is so in implementation and it is irrelevant) and don't change later. So it is not *so* inconsistent.
Making $0 mean in a message the same it means in an object box, would make it *a lot* more inconsistent with $1,$2 in messages than $0 is with $1,$2 in object boxes. $1,$2... in messages are evaluated at the time the message box receives its input and generates its output; they are arguments of the message it receives. The "natural" object-counterpart of $0 would be a number that is unique to that particular message event (not message box) or message tree, though that would be of little or no use..... or wouldn't it?
Also, consider the following goal: (*) give direct access to (implicit and explicit) creation arguments ($n) of the patch within a message
Making $0 mean the same in a message box than outside it would address goal (*) only for the particular case of $0 and not for n>0, and I personally think this isn't an elegant approach. Also, any future attempt to address (*) for n>0, would probably result more difficult or have to be more inconsistend if the $0 case has been treated this way.
I am personally strongly against implementing $0 in messages meaning the same as $0 outside them. It would introduce further inconsistence. If there actually is some inconsistence now, it is not a good reason imho to deliberately introduce more inconsistence.
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6905&d=17-8
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi, the problem is, that $1 (and $<) has a different behaviour in objects and in messages. I think that was taken as reason, not to make $0 having the same behaviour in messages, but giving it no behaviour at all and also no alternative solution. but maybe there is another motivation I have not taken into consideration. and I am also not able to implement any of the discussed possibilities. I am just trying to find a lobby for either solution.
marius
Patrice Colet wrote:
You know what, all along the hundreds of lines I've been reading in the list about $0, I don't get a single consistent reason why it hasn't the same behavior in object and message boxes.
Matteo Sisti Sette a écrit :
Mathieu Bouchard wrote (and a few other people wrote something similar):
$0 in objectboxes is already inconsistent with $1,$2,$3,... in objectboxes, so, it's not clear that $0 in messagebox has to be consistent with anything at all.
$0 is inconsistent with $1, $2 etc strictly speaking, but you may think of $0 as of an "implicit creation argument". The name $0 has the same scope of the names $1,$2, in the sense that: in any two places where two $0's would have the same value, two $1's would have the same value. Both are values that are generated at the time of creating the object (semantically I mean, I don't know if it is so in implementation and it is irrelevant) and don't change later. So it is not *so* inconsistent.
Making $0 mean in a message the same it means in an object box, would make it *a lot* more inconsistent with $1,$2 in messages than $0 is with $1,$2 in object boxes. $1,$2... in messages are evaluated at the time the message box receives its input and generates its output; they are arguments of the message it receives. The "natural" object-counterpart of $0 would be a number that is unique to that particular message event (not message box) or message tree, though that would be of little or no use..... or wouldn't it?
Also, consider the following goal: (*) give direct access to (implicit and explicit) creation arguments ($n) of the patch within a message
Making $0 mean the same in a message box than outside it would address goal (*) only for the particular case of $0 and not for n>0, and I personally think this isn't an elegant approach. Also, any future attempt to address (*) for n>0, would probably result more difficult or have to be more inconsistend if the $0 case has been treated this way.
I am personally strongly against implementing $0 in messages meaning the same as $0 outside them. It would introduce further inconsistence. If there actually is some inconsistence now, it is not a good reason imho to deliberately introduce more inconsistence.
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6905&d=17-8
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello, indeed, in message boxes, if the variable after the dollar sign doesn't match a number corresponding to the number of arguments given at it's input, it outputs directly the variable, if the variable is a number, it ignores the dollarsign, if the number is greater than the number of variables only, it outputs an error message.
It just doesn't make easy to find errors.
In object boxes such attempts would result into different error messages like "$2: argument number out of range", or "$-1: bad type", that might help for debugging a patch.
For me, dollar sign has exactly the same behavior in objects and messages, it's just objects and messages that don't do the same things, and I would think that $0 would decrease performances reached by message boxes if it would have to give the patch ID instead of ignoring dollar sign like it actually does.
marius schebella a écrit :
Hi, the problem is, that $1 (and $<) has a different behaviour in objects and in messages. I think that was taken as reason, not to make $0 having the same behaviour in messages, but giving it no behaviour at all and also no alternative solution. but maybe there is another motivation I have not taken into consideration. and I am also not able to implement any of the discussed possibilities. I am just trying to find a lobby for either solution.
marius
Patrice Colet wrote:
You know what, all along the hundreds of lines I've been reading in the list about $0, I don't get a single consistent reason why it hasn't the same behavior in object and message boxes.
Matteo Sisti Sette a écrit :
Mathieu Bouchard wrote (and a few other people wrote something similar):
$0 in objectboxes is already inconsistent with $1,$2,$3,... in objectboxes, so, it's not clear that $0 in messagebox has to be consistent with anything at all.
$0 is inconsistent with $1, $2 etc strictly speaking, but you may think of $0 as of an "implicit creation argument". The name $0 has the same scope of the names $1,$2, in the sense that: in any two places where two $0's would have the same value, two $1's would have the same value. Both are values that are generated at the time of creating the object (semantically I mean, I don't know if it is so in implementation and it is irrelevant) and don't change later. So it is not *so* inconsistent.
Making $0 mean in a message the same it means in an object box, would make it *a lot* more inconsistent with $1,$2 in messages than $0 is with $1,$2 in object boxes. $1,$2... in messages are evaluated at the time the message box receives its input and generates its output; they are arguments of the message it receives. The "natural" object-counterpart of $0 would be a number that is unique to that particular message event (not message box) or message tree, though that would be of little or no use..... or wouldn't it?
Also, consider the following goal: (*) give direct access to (implicit and explicit) creation arguments ($n) of the patch within a message
Making $0 mean the same in a message box than outside it would address goal (*) only for the particular case of $0 and not for n>0, and I personally think this isn't an elegant approach. Also, any future attempt to address (*) for n>0, would probably result more difficult or have to be more inconsistend if the $0 case has been treated this way.
I am personally strongly against implementing $0 in messages meaning the same as $0 outside them. It would introduce further inconsistence. If there actually is some inconsistence now, it is not a good reason imho to deliberately introduce more inconsistence.
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6905&d=17-8
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
patrice, I am not sure if we are talking about the same thing... a dollar sign in an object will get replaced by the argument you give to the patch on creation. lets say you have a patch "volume" and it multiplies input by $1
[inlet~] | [*~ $1] | [outlet~]
then you can create that abstraction in your patch like
[volume 0.7]
and $1 is replaced by 0.7.
but in a [message $1( the $1 is not replaced by 0.7 but by whatever you send to its inlet. that is really not the same behaviour in my opinion. marius.
Patrice Colet wrote:
Hello, indeed, in message boxes, if the variable after the dollar sign doesn't match a number corresponding to the number of arguments given at it's input, it outputs directly the variable, if the variable is a number, it ignores the dollarsign, if the number is greater than the number of variables only, it outputs an error message.
It just doesn't make easy to find errors.
In object boxes such attempts would result into different error messages like "$2: argument number out of range", or "$-1: bad type", that might help for debugging a patch.
For me, dollar sign has exactly the same behavior in objects and messages, it's just objects and messages that don't do the same things, and I would think that $0 would decrease performances reached by message boxes if it would have to give the patch ID instead of ignoring dollar sign like it actually does.
marius schebella a écrit :
Hi, the problem is, that $1 (and $<) has a different behaviour in objects and in messages. I think that was taken as reason, not to make $0 having the same behaviour in messages, but giving it no behaviour at all and also no alternative solution. but maybe there is another motivation I have not taken into consideration. and I am also not able to implement any of the discussed possibilities. I am just trying to find a lobby for either solution.
marius
Patrice Colet wrote:
You know what, all along the hundreds of lines I've been reading in the list about $0, I don't get a single consistent reason why it hasn't the same behavior in object and message boxes.
Matteo Sisti Sette a écrit :
Mathieu Bouchard wrote (and a few other people wrote something similar):
$0 in objectboxes is already inconsistent with $1,$2,$3,... in objectboxes, so, it's not clear that $0 in messagebox has to be consistent with anything at all.
$0 is inconsistent with $1, $2 etc strictly speaking, but you may think of $0 as of an "implicit creation argument". The name $0 has the same scope of the names $1,$2, in the sense that: in any two places where two $0's would have the same value, two $1's would have the same value. Both are values that are generated at the time of creating the object (semantically I mean, I don't know if it is so in implementation and it is irrelevant) and don't change later. So it is not *so* inconsistent.
Making $0 mean in a message the same it means in an object box, would make it *a lot* more inconsistent with $1,$2 in messages than $0 is with $1,$2 in object boxes. $1,$2... in messages are evaluated at the time the message box receives its input and generates its output; they are arguments of the message it receives. The "natural" object-counterpart of $0 would be a number that is unique to that particular message event (not message box) or message tree, though that would be of little or no use..... or wouldn't it?
Also, consider the following goal: (*) give direct access to (implicit and explicit) creation arguments ($n) of the patch within a message
Making $0 mean the same in a message box than outside it would address goal (*) only for the particular case of $0 and not for n>0, and I personally think this isn't an elegant approach. Also, any future attempt to address (*) for n>0, would probably result more difficult or have to be more inconsistend if the $0 case has been treated this way.
I am personally strongly against implementing $0 in messages meaning the same as $0 outside them. It would introduce further inconsistence. If there actually is some inconsistence now, it is not a good reason imho to deliberately introduce more inconsistence.
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6905&d=17-8
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Patrice Colet hat gesagt: // Patrice Colet wrote:
You know what, all along the hundreds of lines I've been reading in the list about $0, I don't get a single consistent reason why it hasn't the same behavior in object and message boxes.
Don't know if it's a good reason, but: In a message box, dollar variables get replaced by looking at (the elements of) incoming messages. In object boxes, dollars are substituted by looking at the context of the patch's canvas: If the patch was called as an abstraction, its arguments replace the dollars, otherwise default zeros are inserted. A canvas has an additional property in the unique identifier $0. However messages reaching a message box do not carry such an unique identifier, as $0 is a property of the canvas, not a property of the incoming message: There is no $0 in messages, there's only a $0 in a canvas. An effect of this is, that there's no $0 in message boxes, but there's a $0 in object boxes. So to get $0 into a message, you first have to collect it from the canvas by using some kind of object box (float $0, symbol $0-x,...) then make a message out of it ("1002" or "symbol 1002-x") and then send that message to the message box.
I guess, the reason, why in Pd $0 and the conversion from canvas properties to a message are not directly included in a message box, is just that it would obscure the difference between canvas and message properties, that's in effect now, so it's more or less an aesthetic reason. But as Marius' and others' suggestion of changing $ in messages to # shows, that also has its problems: Should the difference be made clearer by using different variable identifiers? Or should users be expected to be insightful enough after a while to understand the difference without having to type different variable-characters for messages and objects as in Max? (Personally I prefer that both messages and object boxes use a dollarsign for simplicity, but I also know from teaching workshops, that many "newbies" get confused by this. But then, they also confuse the difference between subpatches and abstractions ... it goes away with time.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 17 Aug 2007, marius schebella wrote:
Frank Barknecht wrote:
reason. But as Marius' and others' suggestion of changing $ in messages to #
no, I was talking about changing the sign for creation arguments! for reasons of backwards compatibitily.
For reasons of backwards compatibility you'd keep $- the same because if you write $- it currently stays $- ... if you are going to selectively drop compatibility, you ought to explain why and how, e.g. "because $- is rarer than #" ...
marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
On Fri, 17 Aug 2007, marius schebella wrote:
Frank Barknecht wrote:
reason. But as Marius' and others' suggestion of changing $ in messages to #
no, I was talking about changing the sign for creation arguments! for reasons of backwards compatibitily.
For reasons of backwards compatibility you'd keep $- the same because if you write $- it currently stays $- ... if you are going to selectively drop compatibility, you ought to explain why and how, e.g. "because $- is rarer than #" ...
in old patches you have $1 $2 $3 in messages and $0 $1 $2 in objects presumtion: you don't just simply want to add $0-feature to messages simply because it would be inconsequent, or difficult to understand for newbies... therefor you want to differentiate between creation and message arguments. giving one of them a new appearance, but still making old patches work. case 1 (bad): you have $0 $1 #1 $2 #2 $3 #3 in messages and $0 $1 $2 $3 in objects. (that's bad because, then u still have the confusion of $0 and $- in messages, exactly what you did not want case 2 (better): you have #0 #1 #2 #3 #4 $1 $2 $3 $4 in messages (all meaning different things) and $0 or #0, $1 or #1, $2 or #2 in objects. (#- the new style, but for backwards compatibilty still allowing the old $- style) hope this is clear enough. marius.
instead of @ # ? we could also use a prefix like "this.": this.$0, this.$1, this.$2 for messages. just a suggestion. m.
marius schebella wrote:
Mathieu Bouchard wrote:
On Fri, 17 Aug 2007, marius schebella wrote:
Frank Barknecht wrote:
reason. But as Marius' and others' suggestion of changing $ in messages to #
no, I was talking about changing the sign for creation arguments! for reasons of backwards compatibitily.
For reasons of backwards compatibility you'd keep $- the same because if you write $- it currently stays $- ... if you are going to selectively drop compatibility, you ought to explain why and how, e.g. "because $- is rarer than #" ...
in old patches you have $1 $2 $3 in messages and $0 $1 $2 in objects presumtion: you don't just simply want to add $0-feature to messages simply because it would be inconsequent, or difficult to understand for newbies... therefor you want to differentiate between creation and message arguments. giving one of them a new appearance, but still making old patches work. case 1 (bad): you have $0 $1 #1 $2 #2 $3 #3 in messages and $0 $1 $2 $3 in objects. (that's bad because, then u still have the confusion of $0 and $- in messages, exactly what you did not want case 2 (better): you have #0 #1 #2 #3 #4 $1 $2 $3 $4 in messages (all meaning different things) and $0 or #0, $1 or #1, $2 or #2 in objects. (#- the new style, but for backwards compatibilty still allowing the old $- style) hope this is clear enough. marius.
Hallo, marius schebella hat gesagt: // marius schebella wrote:
instead of @ # ? we could also use a prefix like "this.": this.$0, this.$1, this.$2 for messages.
Though with 0.40 dollar substition was allowed in the middle of a symbol as well, not only at the beginning, so this wouldn't work without conflicts.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
instead of @ # ? we could also use a prefix like "this.": this.$0, this.$1, this.$2 for messages.
Though with 0.40 dollar substition was allowed in the middle of a symbol as well, not only at the beginning, so this wouldn't work without conflicts.
Ciao
you mean because it would be difficult/impossible to program such a feature or because so many people are already using this.$- strings in their daily patchwork? marius.
Hallo, marius schebella hat gesagt: // marius schebella wrote:
you mean because it would be difficult/impossible to program such a feature or because so many people are already using this.$- strings in their daily patchwork?
The latter.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
reason. But as Marius' and others' suggestion of changing $ in messages to #
no, I was talking about changing the sign for creation arguments! for reasons of backwards compatibitily.
Seems I've confused some things here, sorry.
So what you propose is to allow usage of all canvas properties like creation arguments and $0 in message boxes as well? I think, then instead of changing the message box, a new GUI object would be more appropriate and even more backwards-compatible. Something like [msg ...] which would be like a fancy, clickable makefilename/list/cnv/bng bastard similar to what I mentioned in another mail.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
yes, seems our mails were crossing each other somewhere in the jungle of mail delivery... :) marius.
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
reason. But as Marius' and others' suggestion of changing $ in messages to #
no, I was talking about changing the sign for creation arguments! for reasons of backwards compatibitily.
Seems I've confused some things here, sorry.
So what you propose is to allow usage of all canvas properties like creation arguments and $0 in message boxes as well? I think, then instead of changing the message box, a new GUI object would be more appropriate and even more backwards-compatible. Something like [msg ...] which would be like a fancy, clickable makefilename/list/cnv/bng bastard similar to what I mentioned in another mail.
Ciao
Hello, Frank Barknecht a écrit : However messages reaching a message box do not
carry such an unique identifier, as $0 is a property of the canvas, not a property of the incoming message: There is no $0 in messages, there's only a $0 in a canvas. An effect of this is, that there's no $0 in message boxes, but there's a $0 in object boxes. So to get $0...
Ciao
I was just wondering why $0 wouldn't be implemented as a message property.
Patrice Colet a écrit :
Hello, Frank Barknecht a écrit : However messages reaching a message box do not
carry such an unique identifier, as $0 is a property of the canvas, not a property of the incoming message: There is no $0 in messages, there's only a $0 in a canvas. An effect of this is, that there's no $0 in message boxes, but there's a $0 in object boxes. So to get $0...
Ciao
I was just wondering why $0 wouldn't be implemented as a message property.
Message boxes couldn't be drawn anywhere else than into a canvas, so I really don't get why canvas properties wouldn't be parsed through message boxes with some variable, and then the $0 would be an excellent guest for the canvas's unique identifier into messages.
Hallo, Patrice Colet hat gesagt: // Patrice Colet wrote:
Hello, Frank Barknecht a écrit : However messages reaching a message box do not
carry such an unique identifier, as $0 is a property of the canvas, not a property of the incoming message: There is no $0 in messages, there's only a $0 in a canvas. An effect of this is, that there's no $0 in message boxes, but there's a $0 in object boxes. So to get $0...
Ciao
I was just wondering why $0 wouldn't be implemented as a message property.
You mean as a property of a "message" or as a property of a "message box"? (In my previous mail, I tried to make a difference between both and tried to write "message box" where I was talking about a "message box" and only message, where general messages were meant. I might have made some mistakes during that, though.)
A message (like "list 10 20 30") doesn't know anything about the thing called $0 with canvases. Messages aren't bound to a certain canvas, they can be sent freely between various "cancas scopes" with different $0s.
Messages do know about their $2, which is just another name for their second item. For "list 10 20 30" this message's $2 would be: "20". But I don't really see, how something like "$0 for messages" (not message boxes!) would make any sense.
For message boxes however one *could* define, that $0 should be replaced by the value of $0 taken from the canvas, the message box sits in, as soon the box is activated (by click or an incoming message). However this would somehow change the direct relationship messages and message boxes currently have: It would rely on the fact, that message boxes also are a kind of object in a canvas and don't just represent a Pd message as objects exchange them. In the end, a message box wouldn't be very different from a fancy, clickable [makefilename] or [list ...] object.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht a écrit :
Hallo,
It would rely on the fact,
that message boxes also are a kind of object in a canvas and don't just represent a Pd message as objects exchange them. In the end, a message box wouldn't be very different from a fancy, clickable [makefilename] or [list ...] object.
Ciao
Hi, You've perfectly got what I've been thinking about, thank you for making this clear.
Frank Barknecht wrote:
For message boxes however one *could* define, that $0 should be replaced by the value of $0 taken from the canvas, the message box sits in, as soon the box is activated (by click or an incoming message). However this would somehow change the direct relationship messages and message boxes currently have:
then I think the only solution is to write a new object: the message object :). we already have bang as a message and bang as a widget and we have two numbers, so why not also have a new message object, clickable and with all features one wants. marius.
On Fri, 17 Aug 2007, marius schebella wrote:
then I think the only solution is to write a new object: the message object :). we already have bang as a message and bang as a widget and we have two numbers, so why not also have a new message object, clickable and with all features one wants. marius.
Messageboxes are already objects. It's just that the constructor has been hidden, such that if you try to make a [message] object, it fails, even though the class is truly named "message". It is because class names don't matter, only constructor names matter, and they usually correspond to class names, but not always.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Fri, 17 Aug 2007, Frank Barknecht wrote:
for messages and objects as in Max? (Personally I prefer that both messages and object boxes use a dollarsign for simplicity, but I also know from teaching workshops, that many "newbies" get confused by this. But then, they also confuse the difference between subpatches and abstractions ... it goes away with time.)
Simplicity of the language gets balanced by complexity of what you write in it. It is not a zero-sum game: a little less complexity in the language means a lot more complexity in the patches. In the end, it's a loss.
Unlike the difference between subpatches and abstractions, at least part of the complexity of not having abstraction $ in messageboxes does not go away with time. It makes clumps around messageboxes and they stick around there because they are necessary to compensate for a lack of complexity in pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Fri, Aug 17, 2007 at 06:37:58PM -0400, Mathieu Bouchard wrote:
On Fri, 17 Aug 2007, Frank Barknecht wrote:
for messages and objects as in Max? (Personally I prefer that both messages and object boxes use a dollarsign for simplicity, but I also know from teaching workshops, that many "newbies" get confused by this. But then, they also confuse the difference between subpatches and abstractions ... it goes away with time.)
Simplicity of the language gets balanced by complexity of what you write in it. It is not a zero-sum game: a little less complexity in the language means a lot more complexity in the patches. In the end, it's a loss.
Unlike the difference between subpatches and abstractions, at least part of the complexity of not having abstraction $ in messageboxes does not go away with time. It makes clumps around messageboxes and they stick around there because they are necessary to compensate for a lack of complexity in pd.
My 2 Zimbabwe dollars: I agree that there is no nice reason for those clumps, and one more inconsistency in Pd would do more good than bad in this case. I would say making $0 do the same thing in message boxes and abstraction arguments would overall save time for users and only add a very small amount of easily-explainable complication.
Best,
Chris.
On Tuesday 21 August 2007 06:05, Chris McCormick wrote:
My 2 Zimbabwe dollars: I agree that there is no nice reason for those clumps, and one more inconsistency in Pd would do more good than bad in this case. I would say making $0 do the same thing in message boxes and abstraction arguments would overall save time for users and only add a very small amount of easily-explainable complication.
At the same time can we also get rid of the 'only $s at the beginning of a string get interpreted' rule?
Nesting abstractions within abstractions just to get that is sometimes not an option.
robert.
Hallo, Robert Scott hat gesagt: // Robert Scott wrote:
At the same time can we also get rid of the 'only $s at the beginning of a string get interpreted' rule?
Already done in Pd 0.40 and up.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Quoting Robert Scott lists@humanleg.org.uk:
At the same time can we also get rid of the 'only $s at the beginning of a string get interpreted' rule?
as frank has said, at the same time we could make sure that we are
running an actual version of Pd (or try, whether the requested feature
is already implemented...) :-)
Nesting abstractions within abstractions just to get that is sometimes not an option.
it would be interesting how you acchieve the required functionility
with nested abstractions. i cannot think how you do that...
mfg.adsr. IOhannes
This message was sent using IMP, the Internet Messaging Program.
On Tuesday 21 August 2007 19:56, zmoelnig@iem.at wrote:
as frank has said, at the same time we could make sure that we are running an actual version of Pd (or try, whether the requested feature is already implemented...) :-)
I've only just updated to 0.40. So far it's just solved two of my problems in a row. It's like a goldmine.
So following this pattern, will 0.42 be a compatibility-breaking redesign replacing insane messages with LISP-like lists of lists and atoms?
it would be interesting how you acchieve the required functionility with nested abstractions. i cannot think how you do that...
I only remember that that's how I once managed to achieve the goal I needed to at the time. It may not have been doing exactly that.
robert.
On Tue, 21 Aug 2007, Robert Scott wrote:
So following this pattern, will 0.42 be a compatibility-breaking redesign replacing insane messages with LISP-like lists of lists and atoms?
In DesireData, as soon as I'm done reprogramming the GOP feature (which has been dragging for a while and is driving me mad) I will work towards making DS and pointers work again. I will be working at the atom level on three different additions that have something in common: deallocatable symbols, listatoms, and simplified pointers. All three involve reference counting (I won't involve mark-and-sweep in this). Also, listatoms won't be chains of pairs (linked-lists) as they are in LISP; they will be more like LISP vectors, or in pd internals vocabulary, t_binbuf (which might gain in getting renamed) or argument lists. (now I'd like to know: should those lists be mutable or not?)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Wednesday 22 August 2007 13:18, Mathieu Bouchard wrote:
making DS and pointers work again.
The reason I ended up abandoning data structures was, as far as I could see, the only way to get data from them was by polling them. Which I found ridiculous.
I found it was much easier and less buggy to simply abuse the provided widgets.
In my idle moments staring at the screen (often battling pd lists) I've been considering how I would go about scratch-writing a pd-alike with no legacy requirements. So I have a whole bunch of mad ideas about how things should really be done and you probably shouldn't listen to me.
robert.
Hallo, Robert Scott hat gesagt: // Robert Scott wrote:
On Wednesday 22 August 2007 13:18, Mathieu Bouchard wrote:
making DS and pointers work again.
The reason I ended up abandoning data structures was, as far as I could see, the only way to get data from them was by polling them. Which I found ridiculous.
You don't need to poll them anymore for mouse-driven updates: The struct-object reports (m)any changes through its outlet.
Ciao
Frank Barknecht
Hallo, Robert Scott hat gesagt: // Robert Scott wrote:
So following this pattern, will 0.42 be a compatibility-breaking redesign replacing insane messages with LISP-like lists of lists and atoms?
I think, with the introduction of the [list] object family, many more LISP-like list operations became possible with standard Pd objects. Of course Pd is not lisp, and I doubt, it will ever be one.
If you need a more structured container for data items, the data structures of Pd are immensly useful IMO. You can ignore all the drawing stuff easily and just use them as general purpose containers. While messages are kind of volatile "things" that are basically gone, once you've received them (unless you store them one by one into an object like [list]), data structures also have a more permanent character. If you modify a data item through a pointer, the modified version will be available for future use. This makes applications like the Turing machine I once posted, cellular automata, L-Systems and other grammars etc. very elegant to implement.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hello IOhannes,
im still trying to compile iars for mac Intel but im getting some
errors....
I ran .configure:
machine$ ./configure checking whether qmake is available ..../configure: line 40: test: too many arguments yes checking whether zziplib is available ...Package zziplib was not found in the pkg-config search path. Perhaps you should add the directory containing `zziplib.pc' to the PKG_CONFIG_PATH environment variable No package 'zziplib' found no! Aborting machine:~/Desktop/PD PLUGIN IARS/iARS machine$
there's a zziplib package missing.
so I downloaded the zziplib-0.13.49.tar.bz2
with ./configure everything goes ok, but then I have to do make:
sed: IARS/iARS/zziplib/Darwin_8.10.1_i386.d/zzip/libzzip.la: No such
file or directory
libtool: link: `IARS/iARS/zziplib/Darwin_8.10.1_i386.d/zzip/
libzzip.la' is not a valid libtool archive
make[3]: *** [libzzipwrap.la] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all] Error 2
it creates a zziplib.pc but I don't know where to put it in iARS
(tried putting it in ./iARS/pd)
any help?
thks
On Fri, 17 Aug 2007, Matteo Sisti Sette wrote:
$0 is inconsistent with $1, $2 etc strictly speaking, but you may think of $0 as of an "implicit creation argument". The name $0 has the same scope of the names $1,$2,
yes.
Making $0 mean in a message the same it means in an object box, would make it *a lot* more inconsistent with $1,$2 in messages than $0 is with $1,$2 in object boxes.
scope-wise, yes. I once recommended that the selector of a message be interpreted as $0 in a messagebox, because this has the same scope as the message arguments, even though when following this logic it means that objectboxes' $0 ought to be the name of the class the abstraction was created as (before any path lookups and following symlinks, but after any $-substitutions in that name).
$1,$2... in messages are evaluated at the time the message box receives its input and generates its output; they are arguments of the message it receives. The "natural" object-counterpart of $0 would be a number that is unique to that particular message event (not message box) or message tree, though that would be of little or no use..... or wouldn't it?
Right... messages are way too volatile for this to be of any use (beyond statistics about the execution itself, but that's the job of a profiler)
I am personally strongly against implementing $0 in messages meaning the same as $0 outside them. It would introduce further inconsistence. If there actually is some inconsistence now, it is not a good reason imho to deliberately introduce more inconsistence.
I don't know... when you have a messagebox, the $ arguments are processed in the context of the incoming message but the message has a default receiver that is the messresponder (a hidden object that relays to the outlet of the messagebox). In an objectbox, the $ arguments are processed in the context of the enclosing patch and the default receiver is the objectmaker (an object whose methods are the constructors of all possible object classes). I can't find an analogy like "W is to X what Y is to Z" about it. Is this inconsistence or not? Is it just the way things have to be like?
If there is no sensible use of $0 in messageboxes, then is it less inconsistent to reuse $0 for something else, than if it were an actual contradiction? Aren't those two different levels of inconsistency? Does this distinction matter?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Chris McCormick -
Frank Barknecht -
marius schebella -
Mathieu Bouchard -
Matteo Sisti Sette -
Miguel Cardoso -
Patrice Colet -
Robert Scott -
zmoelnig＠iem.at