IOhannes m zmoelnig wrote:
well, "my" [unpack] behaves perfect. i really don't know what you want.
I must have done something wrong or expected something I couldn't get. I don't have the patch in front of me, so I really can't say what specifically I did wrong. I think it was [prepend] that was causing the problem (see below).
if you have a message [symbol /bli/bla/bo(, then the message contains a single symbol (as is denoted by the selector "symbol") named "/bli/bla/bo" again: the symbol does *not* consist of 2 parts ("symbol" and "/bli/bla/bo") but only of one typed part "/bli/bla/bo".
Ah, yes. I get this. The weird thing is happening in [prepend] then, because it does not handle the symbol as an identifier for the data, but as part of the data. Now, which version/incantation of [prepend], you may ask? It coulad also have been [playlist] which output a weird symbol identifier... I don't know until tomorrow... :-)
with [unpack] you can extract atoms of "lists". example: your message is [list 1 2 3(; again "list" is just a type-selector (to state that the one or more atoms ("1" "2" and "3") of the message form a list. now if you send the message [list 1 2 3( (or only [1 2 3( which is just an abbreviation(!) for [list 1 2 3() to [unpack 0 0 0] you will get the numbers "1" "2" and "3" out of the outlets. the numbers are messages too: "1" is really [float 1( (and not just [1(, which again can be used as an abbreviation(!)).
confused ?
Well, not as long as [unpack] is also capable of processing symbols... :-) I get this.
Thanks!
.thomas