I might lack the full picture of what you are trying to do, but it sounds a bit like you are trying to mix things that don’t mix well. I think this is a pretty tricky lesson to learn and I think everybody is at times stumbling over it.
I am talking about distinguishing all things which can get tackled at compile-time already vs. stuff that has to be postponed to runtime.
Compile-time topics:
- generic types, type parameters
T - VL is trying to figure out types. Those that get displayed even when in stopped mode. Those are the so-called compile-time types.
- Adaptive node implementations can get picked already
Runtime-time topics:
- objects and ungeneric types
- TypeSwitch making use of runtime type (which you get via object.GetType)
MakeGenericVLTypeInfo→ CreateInstance- or even things like CastAs again testing for certain types at runtime
…
The compile-time part is there in order to make it easy to use the system and to already know which pins can be connected.
But sometimes your application is so “dynamic” that you don’t know at compile-time. So suddenly you need to make peace with the idea of working on another level. A level where you can’t know the type of your pad. It’s not float, it’s not Vector3. So you need to make it of type object in thus postpone that decision to point when the program is running.
I have seen different approaches to dealing with this situation over time.
There are libraries that are non-generic in their core. And only offer a generic wrapper. Expression<TDelegate> Class (System.Linq.Expressions) | Microsoft Learn
If you want to, you as a user can make use of the non-generic part of the library, if you don’t know at compile-time which types will flow. And in other cases, it’s just more convenient to use the generic wrappers. Point being: you have the choice of which one to use. And it’s both supported.
In other cases, you will find libraries that only offer generic nodes and types. In those cases, you will need to instantiate them at runtime via reflection & by dynamically feeding the type arguments.
So, from library to library it’s a bit different how easy it is to postpone typing to the point in time where the program is already running. But what’s really important is: you need to be aware of what’s what. You can’t switch types with an LFO at runtime and would like the compile-time type to be switched in a pad. That’s just impossible.