in the girlpower folder, see: “VVVV Plugin API\VariantPins” and open the patch.
I made all native value, color & string pins implement new interfaces IValueData, IColorData & IStringData.
I kept those interfaces super small for now as they work as a proof of concept.
To make it work i needed to rework the internal class hierarchy so that value pins are also node pins, value subtypes are also node subtypes… Node subtypes internally came as a pair (one node subtype “Supporting” the other one “Needing” certain interfaces). I had to rework that too.
So internally there were quite some changes necessary, to make that work. I am a bit confident that it will work out, but i really can’t oversee all implications of the reworked core bits, with their implications potentially spreading into every corner of the software.
Please do your test and report…
The INodeIn interface is the good old node input pin interface. In my example i just used it in a way that i did not set any needed interface. By that you can connect anything to it.
If you have any further wishes regarding functionality please also provide some pseudo code, so that i can imagine your use case and base the API design upon that.
Ok bit late answer, but had time to test it in a pretty reasonable setup last week, so here are answers.
Time seems to work pretty much as expected, which is really a really big improvement and opens a lot of door (either in patch or in plugin).
Now having tested it reasonably extensively, another feature to make it close to perfect would be to also to be able to notify of a clock reset (like: I return to 0). Doing so should also call reset on LFOs, Dampers…
It can be patched already of course, but that’s just visual pollution to have either Link or R node everywhere ;)
About mixed interface, it seems to work pretty much as expected, I need to check a bit more how it interacts with custom connection handlers now, as also want to allow filtering in (all) cases.