If the inlet of the MSP object inside the abstraction—the one that the inlet object is attached to—takes both signal and float, then the inlet object will properly pass either signal or float. As with almost all MSP inlets, though, it will ignore floats if a signal is attached.

Thanks, but in my case this doesn't help. I have a formula in an expr object. It's for calculating a filter coefficient from an input for cutoff frequency. I've also made a subpatch with msp objects that performs the calulation as there is no such thing as [expr~].

I need to route the input through a different part of the abstraction depending on whether it is a float or a signal being used. It all comes out the end and it would only be either a float or signal input on the first input of the abstraction.

typeroute~

[route float] will also filter out the number from the mixed connection.

btw., in many cases connecting both a number and a signal to a signal object will result in a modulation of the signal - the number will be moved to the second inlet. in my opinion it is not best practice to allow that in an abstraction.

i use something like this - but take care, it will also make strings/symbols go to the signal object.

in order to get rid of max symbols too, you´d have to convert symbols to lists first, then you get the pure signal connection (and NaN and stuff) at the last outlet.

Perfect, thank you both.

Didn't know about typeroute~, or that you could write float as a type in route and it would seperate it, both nice and simple solutions.

My intention isn't to have both kinds of input connected at once to the same inlet, just that you could use the abstraction with either a float or a signal input, like you can for the cutoff inlet of svf~ for example.