hello, how do I route /1 and /2 in a way that I just get rid of the slash and get the output 1 and 2 in order to multiply them with another number?
In that case what I posted above should work, but you have to manually list all possible messages. But what Liam proposes actually work much better, but I also feel it is an inelegant solution (though very very clever!). But yeah, modifying strings in Pd can be a bit of a hassle as far as I know.
Just making it a bit more clear by what I meant above: Liam's answer works like a charm and is really clever. I just meant to say that I wished there was a more direct way to handle this in Pd. It does look silly to have to go back and forth from symbol to list to symbol, from characters to ascii numbers to characters to floats. But yeah, it really works:
..or is it about osc routing? There are objects for this [routeOSC] or was this [OSCroute]?
@Johnny-Mauser I can't see how that would help removing the slash from those symbols. Do you have a specific patch in mind that could do it using OSC?
@gsagostinho no patch in mind!! Just the intuition of hinting to the regular (?) use of osc style messages e.g. "/path/to/osc/receiver/1 1" or just the adress "/1" like it might be coming from remote apps like v-control. Still you would need a solution like yours if you don't send a value..
As Liam said 'There are several ways you could do this.'
So here's another
thanks for all the help. Unfortunately I can't uses extended versions of PD (working with MobMuPlat).
I'm using Pd 0.46.7
I need the result as a float not as a symbol in order to use it for math.
The reason I have the symbol /1.../n is that they got sent from an iPhone with MobMuPlat and I don't want to route each symbol separately.
I made it work from /1..../9 but not with /12 or /45630
@gratkowski Hello there....... It is a bug in vanilla where an expected float is sent with a symbol tag......that I reported here..... https://sourceforge.net/p/pure-data/bugs/1232/ and IOhannes M Zmoelnig has posted a workaround there....... which could help you?......
Otherwise the solution is to keep your message header populated entirely by symbols..... eg...... xxx/yyy/zzz value....... and then the routing will work........ and then do a "translation table"...... i.e a=1 b=2 etc. using [sel a b c d etc.].......although I would have expected you to want to do some math with the value, rather than the message header?
Anyway, the link above should solve your problem I hope...
......from the bug report......