Hallo,
(I cc. to the list as well, I hope you don't mind.)
Sciss hat gesagt: // Sciss wrote:
frank, thanks for the links to the text from you and hc ; i think i
quite understand the thing know (although i still find it not very
convincing to have a "symbolic atom" along with a "symbol" ;-)so i guess you can often omit the selector for the left inlet because
that's a special "accepts all" inlet, right?
No, that's not dependent of the inlet number although as a convention most objects accept meta-messages at their first inlet. However you cannot just omit the selector. It really depends on the object that gets this message. For example "set" and "symbol set" are two very different messages, which you can see by creating a graphical symbol-object with Ctrl-4, and connecting a [set( and a [symbol set( message to it. Pressing the "set" message will not change, what you typed into the symbol, however "symbol set" will input "set" into the symbol-atom.
This gets even clearer if you use a message object instead of the symbol-atom like in:
[symbol set( | | [set( |/ [hallo $1( | [print]
If you press the "symbol set" message, Pd will print "hallo set" because $1 will get expanded.
However if you press the "set" message, Pd will print nothing, instead the contents of the "hallo $1" message will be deleted and the message will be set to be empty. ("set something" would set it to "something").
So the difference between messages with selectors and messages without a selector can be HUGE. The only place, where the selector can be omited is with messages that start with a floating point number. They will automatically become a float or a list messages depending on how many elements the messages has. Also empty messages are normally considered to be a "bang" message.
Frank Barknecht _ ______footils.org_ __goto10.org__
Am 19.04.2006 um 18:20 schrieb Frank Barknecht:
Hallo,
(I cc. to the list as well, I hope you don't mind.)
Sciss hat gesagt: // Sciss wrote:
[...]
so i guess you can often omit the selector for the left inlet because that's a special "accepts all" inlet, right?
No, that's not dependent of the inlet number although as a convention most objects accept meta-messages at their first inlet. However you cannot just omit the selector. It really depends on the object that gets this message. For example "set" and "symbol set" are two very different messages, which you can see by creating a graphical
symbol-object with Ctrl-4, and connecting a [set( and a [symbol set( message to it. Pressing the "set" message will not change, what you typed into the symbol, however "symbol set" will input "set" into the symbol-atom.
here is what i mean:
#N canvas 0 22 454 304 16; #X obj 106 131 pack s s; #X obj 107 168 print; #X msg 107 48 gaga; #X msg 180 48 gaga; #X text 230 48 NO!; #X text 61 47 YES!; #X msg 224 93 symbol gaga; #X connect 0 0 1 0; #X connect 2 0 0 0; #X connect 3 0 0 1; #X connect 6 0 0 1;
pack accepts a "metasymbol" as first inlet (so i *can* omit the
selector here), but only a "symbol" as second inlet. i experience
this behaviour with many objects. no ?
ciao, -sciss-
On Wed, 19 Apr 2006, Sciss wrote:
pack accepts a "metasymbol" as first inlet (so i *can* omit the selector here), but only a "symbol" as second inlet. i experience this behaviour with many objects. no ?
I believe that this is a serious misfeature of Pd: interpreting a lone selector as a symbol introduces exceptions because some selectors already mean something else. "set" isn't like "symbol set", "bang" isn't like "symbol bang", "symbol" isn't like "symbol symbol", "float" isn't like "symbol float" (and then some more, depending on which object you send to). Also, if lone selector messages weren't accepted as if they were symbol messages, there would be less confusion between those two things.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Wed, 19 Apr 2006, Sciss wrote:
pack accepts a "metasymbol" as first inlet (so i *can* omit the selector here), but only a "symbol" as second inlet.
Note that even with that, [pack]'s output will be a proper list-message, which you can check with:
[a( [symbol b( [symbol c( | | | [pack s s s ] | [print]
will print "list a b c".
I believe that this is a serious misfeature of Pd: interpreting a lone selector as a symbol introduces exceptions because some selectors already mean something else. "set" isn't like "symbol set", "bang" isn't like "symbol bang", "symbol" isn't like "symbol symbol", "float" isn't like "symbol float" (and then some more, depending on which object you send to). Also, if lone selector messages weren't accepted as if they were symbol messages, there would be less confusion between those two things.
Yes, I agree, lets file a bug report against [pack] ... oh, but what about backwards compatibility. :(
I guess, the misleading behaviour comes from the fact, that the first inlet often is an "anything" inlet, which accepts anything: meta-messages, symbols, floats, lists, that sometimes are distributed over other inlets etc.
I'd say, that one should take great care not to rely lone selectors, being converted to symbols because often they aren't, for example not with the Ctrl-4 symbol-atom.
[list] in pd-0.39 works great for adding proper selectors, btw. because by design it adds a list-selector and the message will be auto-converted by Pd to a proper symbol-message later, if the incoming message just contained one non-float element.
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, 19 Apr 2006, Frank Barknecht wrote:
Yes, I agree, lets file a bug report against [pack] ... oh, but what about backwards compatibility. :(
that feature could be re-enabled by starting pd with the "-sloppy" option...
I guess, the misleading behaviour comes from the fact, that the first inlet often is an "anything" inlet, which accepts anything: meta-messages, symbols, floats, lists, that sometimes are distributed over other inlets etc.
just because it can accept anything doesn't mean it does. In practice, a lot of left inlets only accept a handful of selectors. if class_addanything is used to trap all remaining messages (and for example use it as a shortcut for symbol) then it's a deliberate act, and the fact that some objects accept this encourage people to think that it's normal that you don't have to write "symbol" in front of symbols in messageboxes.
[list] in pd-0.39 works great for adding proper selectors, btw. because by design it adds a list-selector and the message will be auto-converted by Pd to a proper symbol-message later, if the incoming message just contained one non-float element.
well that means that [list] can't support any methods other than "anything", at the risk of causing exceptions, and that's exactly what filing a bug report against [pack] would be about... or am I missing anything?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Wed, 19 Apr 2006, Frank Barknecht wrote:
[list] in pd-0.39 works great for adding proper selectors, btw. because by design it adds a list-selector and the message will be auto-converted by Pd to a proper symbol-message later, if the incoming message just contained one non-float element.
well that means that [list] can't support any methods other than "anything", at the risk of causing exceptions, and that's exactly what filing a bug report against [pack] would be about... or am I missing anything?
I'm not sure I understand what you mean here: [list] accepts meta-messages as well as float-, symbol- and bang-messages and pointers. They all will be converted to "list INPUT" at the outlet. I think, this is quite okay, very useful and there's no need for a bug report.
But [list] also accepts other kinds of message, for example GemLists, which are converted to something that prints:
print: list gem_state (pointer) (pointer)
and which is probably useless. Is that, what you mean by "risk of causing exceptions"?
Frank Barknecht _ ______footils.org_ __goto10.org__
On Thu, 20 Apr 2006, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
well that means that [list] can't support any methods other than "anything", at the risk of causing exceptions, and that's exactly what filing a bug report against [pack] would be about... or am I missing anything?
I'm not sure I understand what you mean here: [list] accepts meta-messages as well as float-, symbol- and bang-messages and
I mean that if [list] supports a "set" method then you can't send "set 42" to it if you really mean "list set 42" and don't want to call the "set" method.
But [list] also accepts other kinds of message, for example GemLists, which are converted to something that prints: print: list gem_state (pointer) (pointer) and which is probably useless. Is that, what you mean by "risk of causing exceptions"?
No, I really meant the fact that you can't define extra configuration
methods (such as "set") in the first inlet without causing special cases.
Messageboxes already have such special cases (and I consider that fact to
be somewhat ugly).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada