Hi list
I understand that [symbol 43( is not the same as [43( as it is interpreted as a symbol, not a float. So I can send the message [symbol 43( to a symbol atom, or to any object that works with symbols, and it will be handled just as if it was [symbol dog(, right?
However, when this symbol is inserted as an argument into a message, or packed into a list, what is it that distinguishes it from the number 43??
Let's make a practical example. I want to dynamically set the label of a canvas so that it shows a number. Suppose the receive symbol of the canvas is mycanvas_receive.
(1) The following doesn't work:
[label 43( (*) | [s mycanvas_receive]
(2) Nor does this:
[43( (or replace this with a number box) | [label $1( (*) | [s mycanvas_receive]
(3) Nor this:
[symbol 43( | [label $1( (*) | [s mycanvas_receive]
(4) While this DOES work
[43( (or replace this with a number box) | [makesymbol %d] | [label $1( (*) | [s mycanvas_receive]
However, I can't see any difference between the output of the message box (*) in (4) and in (1-3). If I connect that message box to a [print] in any of the four examples above, the output is always "label 43".
It seems that the message that is generated in example 4 is intrinsically but invisibly different from the previous 3 examples.
I may deduce that each argument of a message has an associated type that somewhat depends on its "history" and cannot always be "seen"... which I don't like but may be an explanation.
However, this does not explain the following:
- Isn't the output of [makefilename] in example (4) just the same as [symbol
43( of example 3?? Then why doesn't example 3 work as well???
Also, consider this:
(5) [label 43( | [unpack s f]
and this
(6) [symbol 43( | [label $1( (**) | [unpack s f]
In example (5), the second outlet of unpack outputs float 43, which is (somewhat) coherent with the fact that example (1) didn't succeed to set the canvas label However, in example (6) unpack gives the error "unpack: type mismatch"... so I guess that the "$1" (i.e. the "43") in (**) is seen as a symbol, not a float....... but then, again: why didn't example (3) set the canvas label???
Anybody can help me to understand the underlying logic?
Oh shit!!!!!!!
Now I see that the following: [symbol 43( | [print]
just outputs "symbol "
while [43( | [makesymbol %d] | [print]
outputs "symbol 43" as expected....
isn't it weird??????
Well... again, if anyone can help me to undertsand this, I'll be grateful
Thank you m.
-- Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor: Vacanza in Grecia: 7 giorni con trattamento all inclusive in albergo 4 stelle a soli 479 Euro Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6607&d=31-5
Hallo, Matteo Sisti Sette hat gesagt: // Matteo Sisti Sette wrote:
Anybody can help me to understand the underlying logic?
First you need to understand the basic role of selectors in Pd's message system: http://puredata.org/dev/PdMessages
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Matteo Sisti Sette hat gesagt: // Matteo Sisti Sette wrote:
However, I can't see any difference between the output of the message box (*) in (4) and in (1-3). If I connect that message box to a [print] in any of the four examples above, the output is always "label 43".
[print] is very bad for showing these kinds of things.
However, this does not explain the following:
- Isn't the output of [makefilename] in example (4) just the same as [symbol
43( of example 3??
It isn't: [makefilename] always generates real symbols and it's the only (usual) way to really numeric symbols. There was a thread on pd-dev about this some time ago. The 43 in a message box [symbol 43( is not a real numeric symbol. Actually "symbol 43" is kind of an illegal message in Pd, as a proper symbol-message is built from the word "symbol" and another "word", not a number. So to build a proper word "43" first you need to generate a 43-symbol using [makefilename].
Then why doesn't example 3 work as well???
Also, consider this:
(5) [label 43( | [unpack s f]
and this
(6) [symbol 43( | [label $1( (**) | [unpack s f]
In example (5), the second outlet of unpack outputs float 43, which is (somewhat) coherent with the fact that example (1) didn't succeed to set the canvas label However, in example (6) unpack gives the error "unpack: type mismatch"... so I guess that the "$1" (i.e. the "43") in (**) is seen as a symbol, not a float.......
It's neither a symbol nor a float: To be a float, it would need to have a selector of "float" or no selector at all, to be a symbol, the data part of the message should be a symbol, but it is a float (43) so your message is not valid.
Oh shit!!!!!!!
Now I see that the following: [symbol 43( | [print]
just outputs "symbol "
Yes, [print] gets confused about the invalid message.
while [43( | [makesymbol %d] | [print]
outputs "symbol 43" as expected....
However this "43" now is indeed a symbol and you cannot input it into a numberbox anymore. Try this:
[43( | [makefilename %d] | [$1( | [+ 10]
You get the error message:
error: +: no method for '43'
which indicates, that "43" now is a symbol-selector! (Let that sink for a while ...) Numeric symbol selectors aren't used by many objects. [select] can handle them, you can label GUI elements with them, you can use them as targets for [send] through the second inlet, but you cannot build a receiver for them: [r 43] is not valid, as in this case "43" is still a float.
isn't it weird??????
Ah, the fun of Pd's message system! But once you get to grips with it you may see, that it's limited, but actually rather consistent. It'd recommend an afternoon of list-archive reading, as this confuses many people.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
I've tried to document odd behavior in Pd. Here's my collection:
http://pure-data.cvs.sourceforge.net/pure-data/doc/additional/ messageoddness/
.hc
On May 31, 2007, at 10:58 AM, Matteo Sisti Sette wrote:
Hi list
I understand that [symbol 43( is not the same as [43( as it is
interpreted as a symbol, not a float. So I can send the message [symbol 43( to a symbol atom, or to any
object that works with symbols, and it will be handled just as if it was
[symbol dog(, right?However, when this symbol is inserted as an argument into a
message, or packed into a list, what is it that distinguishes it from the
number 43??Let's make a practical example. I want to dynamically set the label of a canvas so that it shows a
number. Suppose the receive symbol of the canvas is mycanvas_receive.(1) The following doesn't work:
[label 43( (*) | [s mycanvas_receive]
(2) Nor does this:
[43( (or replace this with a number box) | [label $1( (*) | [s mycanvas_receive]
(3) Nor this:
[symbol 43( | [label $1( (*) | [s mycanvas_receive]
(4) While this DOES work
[43( (or replace this with a number box) | [makesymbol %d] | [label $1( (*) | [s mycanvas_receive]
However, I can't see any difference between the output of the
message box (*) in (4) and in (1-3). If I connect that message box to a [print] in any of the four examples above, the output is always "label 43".It seems that the message that is generated in example 4 is
intrinsically but invisibly different from the previous 3 examples.I may deduce that each argument of a message has an associated type
that somewhat depends on its "history" and cannot always be "seen"...
which I don't like but may be an explanation.However, this does not explain the following:
- Isn't the output of [makefilename] in example (4) just the same
as [symbol 43( of example 3?? Then why doesn't example 3 work as well???
Also, consider this:
(5) [label 43( | [unpack s f]
and this
(6) [symbol 43( | [label $1( (**) | [unpack s f]
In example (5), the second outlet of unpack outputs float 43, which is (somewhat) coherent with the fact that example (1) didn't succeed
to set the canvas label However, in example (6) unpack gives the error "unpack: type
mismatch"... so I guess that the "$1" (i.e. the "43") in (**) is seen as a symbol,
not a float....... but then, again: why didn't example (3) set the canvas
label???Anybody can help me to understand the underlying logic?
Oh shit!!!!!!!
Now I see that the following: [symbol 43( | [print]
just outputs "symbol "
while [43( | [makesymbol %d] | [print]
outputs "symbol 43" as expected....
isn't it weird??????
Well... again, if anyone can help me to undertsand this, I'll be
gratefulThank you m.
-- Email.it, the professional e-mail, gratis per te: http:// www.email.it/f
Sponsor: Vacanza in Grecia: 7 giorni con trattamento all inclusive in
albergo 4 stelle a soli 479 Euro Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6607&d=31-5
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
-
Frank Barknecht -
Hans-Christoph Steiner -
Matteo Sisti Sette