Hi,
I'm trying to create an abstraction that contains routeOSC and I want to "pass" a creation argument of the abstraction as creation argument of routeOSC, that is simply:
[routeOSC $3]
Now the problem is that the object doesn't create because of this error:
"error: * routeOSC: float arguments are not OK."
because when you are "editing" the abstraction "as a patch", $3 evaluates to 0 (i guess).
Obviously I'm gonna use my abstraction with symbols as the $3 argument. Indeed if I do, the object will create. But since it doesn't when creating the abstraction, I cannot do the connections.
That relates to a more general problem that is how $-arguments are managed when you "define" an abstraction, since there is no distinction in Pd between defining an abstraction and creating a patch that is not gonna be used as an abstraction. In an ideal world, such a distinction should exist imho.
However usually this "issue" only prevents the abstraction from working properly when you "edit"/"define" it, and you wouldn't expect it to work; but it usually doesn't prevent you from creating it so that you can later use it.
Basically, if an object can accept a symbol as a creation argument (and only a symbol), it is an error to fail to create the object if the argument is not a symbol. Instead, the object should create as if the argument was a symbol, with the number of inlets and outlets that it would have if the argument was a symbol, _and_ print an error message and refuse to work, but not to create.
Now in this case there is a workaround:
[loadbang] | [symbol $3] | [set $1( | [routeOSC /dummysymbol]
Note that [symbol $3] is an example of object that behaves "correctly" the way [routeOSC $3] should. When you are "editing" the abstraction, $3 is 0, so [symbol $3] is just like [symbol 0]. Such [symbol 0] is not OK and you don't expect it to work: if you bang it, it outputs "symbol": [symbol] is not supposed to be created with a numeric argument. However, it doesn't fail to create.