Hi, I'm using Vanilla 46-7

I'm parsing osc data from the "CONTROL (OSC+MIDI)" app.
When using the multitouchXT interface, I unpack the message using [unpack s f f].
The "s" is a number indicating which cursor is being moved or tapped, the two floats correspond to the X Y coordinates.
When I print the "s" directly, The console displays "symbol n" (n corresponds to the cursor number)
If I send the outlet corresponding to "s" to [$1( and print it afterwards, the console displays only the "n".

The problem I'm having, is that I can't find a way to use that "n" value to route or select different actions.

When using [select 1 2 3 4 5] feeding it from the [$1( I get a "no method for 'n' " message. But if I feed it directly from the unpack outlet it does not give back any error, but does not select anything either.

I guess I'm missing some very basic stuff, but I'm really stuck.

Thank you. Any advice would be greatly appreciated

PS: A completely different question: Today I've noticed several examples also inside the forum with text inside a number box.
Like: [text\ or two numbers separated by a space inside one box [1 22\ ... Is that possible? What is it supposed to mean?

The way I like to think about what you are confronting is in programming terms. pd has explicit typing whereas a lot of other visual languages don't; it can be useful or confusing.

The unpack message is typed as a symbol. Routing it through the message box without explicitly stating symbol before the $1 stripped the symbol of its type. So the sel object really just understands it gets a blank message of type $1.

I think select also is barred from selecting floats and symbols at the same time.

Yeah symbol / float conversion can be some of the most annoying things to do in PD. If you can afford to use an external then Zexy's [symbol2list] does exactly what you need ("s2l" for short). If not then maybe you can do something with [list fromsymbol], although this will give you the ASCII code output rather than the actual number you need

As for your second question, you're probably looking at a symbol atom (control + 4 from the "put" menu), which looks pretty much the same as the float atom but is used for symbol / text input. It can be really useful when used in conjunction with the same s2l object.

@LiamG I posted this as a bug a few months ago. At the time I could see no way around it in 0.46-7.
I would suggest using an external osc program to change the whole message address to floats (or even better to symbols.....as that was always the intention for osc ..... to make it human readable......
David.

@whale-av said:

At the time I could see no way around it in 0.46-7.

Challenge accepted! I'm not saying that this is an elegant solution, but it will convert symbol-floats to real floats using only Vanilla objects. Things get confusing if you start feeding it regular symbols, though...

Vanilla_symbol_to_float.pd

@LiamG I will look at that this evening.......
Here is the patch that didn't work.....
vanilla_bug_oscparse.pd
From this thread..........
http://forum.pdpatchrepo.info/topic/9856/oscformat-and-oscparse-integer-not-routing-as-expected/3
If you have provided a workaround (or do in the future!) then it could be posted to the bug list as a solution.........
David.

@LiamG thank you so much. It does the trick for me.
Don't know how robust it is for other messages, but great work.
I'm afraid my expertise in PD is not enough to really understand what's going on in your patch, but I'll figure it out some day
Maybe in the meantime [s2l] or another different solution is implemented in Vanilla.

And thank you as well for answering regarding the 'Symbol atom' ... you're right. That's what I was seeing around. I never used it. Maybe now I'll do.

@Gaspar [list fromsymbol] converts the symbol to its ASCII code, which is essentially a list of numbers where every number corresponds to a character from the original symbol. In this code, "0" = 48, "1" = 49 ... and "9" = 57. This patch takes the ASCII number and subtracts 48 to get the original number. If there is more than one digits then the further characters are multiplied by a power of ten and added together. If the number is negative ("-" = 45) then it is multiplied by -1 at the end.

This won't work with decimal points yet--you'd have route 46 (code for " . ") from the list and then do something with the arithmetic.

Also, there is one number box in the patch just below the [- 48] object which I forgot to remove. You should delete it and connect around it.

[float] should be given a symbol method that tries to parse the incoming symbol to a float. If it can, forward the result to the float method. If it can't, error out as it currently does.

Downside: a patch author can not rely on [float] generating an error when it receives symbol atoms that can be parsed as floats. But it's a very edgy edge case where a patch author erroneously hooks up a symbol connection to [float], AND that symbol connection is only sending symbols that can be parsed as a float.

Actually, scratch that. It's not general enough-- for example, you still have zero control over creation arguments:

[keyname]
        |
        [select a q 1]

Here I really want to deal with symbol atoms, but that "1" in [select a q 1] is inescapably a float atom. For a new user, this means they must replace

problem -> obvious solution -> implementation

with

problem -> obvious solution -> implementation -> Pd idiosyncracy -> request for help -> lesson on Pd's type system -> replacing human-readable [keyname] API with character codes of [key] -> implementation

Edit: in Pd-l2ork that "1" is a float atom. In Pd Vanilla I believe that argument becomes a symbol atom set to empty symbol.

I think that the best solution would just be to put a symbol-to-list converter in Vanilla, perhaps in the [list] object itself. This is what I had guessed the new [list fromsymbol] function did before I tried it. Surely it would be more important than an ASCII code converter.

@LiamG Maybe it's best to just have a [list carwash] object that takes an incoming message, converts it to a list, converts the list to a string, and finally parses the string as a Pd message and outputs that.

So if we started with "symbol 1" where the "1" is a symbol atom:

1. "symbol 1" becomes "list 1" (where the "1" is still a symbol atom
2. "list 1" becomes the c string "list 1"
3. The c string "list 1" is parsed as a Pd message, which becomes "list 1" where "1" is now a float atom.

If you put a [list carwash] in between [keyname] and [select a q 1] above, it would do the "right thing". (Well, at least in Pd-l2ork it would.)

But there may be other gotchas here due to parser idiosyncracies I'm not considering...

@LiamG Thank you for the explanation. I'm familiar with ASCII, but actually at the first time I just had a quick glance at your [Vanilla_symbol_to_float] patch. Now, with your explanation, I've gone through it again and it is quite understandable.
Somehow and at least in lack of a better solution it seems elegant to me - Thank you again.

I was so grateful to find a solution to this that I ended up spending the rest of the evening rewriting the patch to accommodate a decimal point. maybe not very elegant, but here it is in case anyone else needs to stay in vanilla:

stof.pd

@LiamG said:

@whale-av said:

At the time I could see no way around it in 0.46-7.

Challenge accepted! I'm not saying that this is an elegant solution, but it will convert symbol-floats to real floats using only Vanilla objects. Things get confusing if you start feeding it regular symbols, though...

@matthewscharles But [float] does this already, doesn't it?

@ingox I wasn't aware -- I tried [makefilename %f] but didn't think to put the float in afterwards. help file says that mode is currently broken so I didn't investigate further.

thanks for pointing me to that! it was fun all the same.