Returns a boolean 1 or 0 if the value sent to the 1st inlet matches the type specified in the creation arg or 2nd inlet.

You can set the type to be matched against either as a creation argument or with the message [type $1(, or by sending to the 2nd inlet either the type name or an example of the atom whose type you want matched against.

EDIT: the "type" method needed a bug fix. The help file has also been slightly altered:

EDIT2: Now the type can be virtually anything, rather than one of 5 possible types. This allows us to check for specific messages. For example, sending the message [foo 1 2 3( to the object [is foo] will return true.

EDIT3: Defaults to float if no creation argument given. Also added a pointer example to the help file.

EDIT4: A memory-freeing method was necessary to clear the proxy inlet.

is.zip

@myQwil Here is a vanilla version of this: is.zip. The conversion of an example and the usage of [type $1( are not yet implemented, so the text in the help file that i copied from your post is not actually correct. Anyhow, it could be done, i just don't have the time right now. Just wanted to share this. If also the creation argument would be converted if it is an example, it could be renamed to "type" maybe

Neat! I've used route with custom messages, but it didn't occur to me that it could also be used as a type checker.

@ingox Unfortunately, that doesn't work for pointers.

@jancsika Right, i was suspecting this, but didn't test it. It is an unfinished patch, i just wanted to put it out there, because i currently don't have the time to polish it

@jancsika, @myQwil Ok, i found a way to detect a pointer. A pointer is treated by [route] like a symbol, curiously. But it still is not a symbol after the [route], apparently. [makefilename %s] then gives the symbol (null), which can be selected against.

I also incorporated the detection of the type by sending an example to the right inlet. Only the use of the message [type $1( to the left inlet gave me some headaches. Using [route type] on [type list( returns an empty list for example. So i gave up on this. The other stuff should work: is.zip. The help file is also updated an should be correct now.

One additional note: Sending a pointer to [route symbol] and the left outlet to [print] crashes Pd:
Without the [print] the bang bangs, but with the [print], Pd crashes

The pointer falling through the left outlet of [route symbol] is almost certainly a bug in Pd Vanilla. It should instead get routed to the rejection outlet. That's what happens in Purr Data, and there's no crasher sending the gpointer from there to the [print] object.

You might want to submit an error to their tracker-- hopefully they'll fix it since there's a crasher with it.

@jancsika Done: https://sourceforge.net/p/pure-data/bugs/1316/

@ingox I recently made a slight change to how the c external works and went ahead and made the same change to your pd external. I just needed to include the rejection outlet of the left route object. is.pd

I've noticed that pd-vanilla and purr-data currently handle pointers differently, making the is.pd object work in pd-vanilla, but not purr-data. I've created another pd-native variation of the external [is] that works in both purr-data and pd-vanilla.

While the route object in pd-vanilla can detect pointers as a type of symbol, in purr-data, a pointer is detected as a list by the symbol object, but not detected as a list by the route object. So if an atom passing through [route list] gets sent to the rejection outlet, then later reveals to have a string value of "list" when sent to a [symbol] object, we can assume that that atom is a pointer.

is.pd