Plugin interface feature request

I had a look into the code and i’m already guessing that it’s as always:
there are plenty of ways of how to try to reach some goal.

We really should get a very good idea of the goal first in order to get a better idea of which way to try.

In fact i’d love to have some sample code to see how your code would benefit of some feature. It would also be nice to get an idea of how the patch would look like.

With a good grasp of your use case we could together see how to pimp the api in order to deliver what you need, vux.

I was in the middle of already implementing one idea when i asked myself if the attached boxing trick wouldn’t be exactly what you need?!

boxing test.zip (4.5 kB)

Ok for time, this is really obvious, external sync, no need to more explanations.

Looking at boxing, this is exactly what I don’t want, to add intermediate nodes everywhere.

If I write a node with a pin that can accept either a string or a value, then we should be able to directly connect string or value, no point of adding manual box nodes.

Attached is a small example of custom handler, that can accept several types, then node just decides what to do from it.
You can see it even accepts a bullet type (first node that I found by hand), but value/color are exceptions and it’s really a pain to add color wrappers everywhere.

About implicit cons, another attached example.

With cons you lose the connection status.
So idea is:
Input pin decides what it accepts, and how many (or other whatever rule).
Event is dispatched on connection (as it is now) (very important to capture event obviously)

Example:

  • Particle system accepts emitter/behaviour (unlimited amounts). No need for cons/group, as we also need to process some cooking on connection (instead of reprocessing the spread all the time, which is an absolute pain). Also order or connection is not important, as data structures and processing order is maintained within the system. (Actually it’s pretty much the same for any semi decent deferred renderer, can’t really use dataflow for that if you’re not on Titan X and want to have a bit of spare memory left ;)

  • Pin can accept a combination of ClassA, Class B (one of each), Or ClassC (mutually exclusive, so if ClassC is connected, we can’t connect ClassA). Also really useful (specially for custom pipeline links)

  • Why should even Add or Multiply node have multiple pins? Operation is commutative so just push all to it right away ;)
    Going to inspector to change input count all the time is also a pain (also alternative, bit offtopic, please add a shortcut to increase/decrease input counts on those nodes, done that in my tool, took about 5 minutes to implement (and about an hour to register relevant nodes to it), one of the best time spent/productivity gain ratio I ever did (much easier and much better than auto add pins ;)

Hope that helps as a starter, if you need more elaboration let me know ;)

multihandler.zip (22.2 kB)

quote vux
“Going to inspector to change input count all the time is also a pain (also alternative, bit offtopic, please add a shortcut to increase/decrease input counts on those nodes, done that in my tool, took about 5 minutes to implement (and about an hour to register relevant nodes to it), one of the best time spent/productivity gain ratio I ever did (much easier and much better than auto add pins ;)”
__

for this offtopic +1

external time sync sounds very useful.

Heads up concerning the custom node pin:

I tested a new pin type that just wraps a bunch of existing pin types and delegates the users connection to those hidden native value/string(…) pins depending on what you connect to.
The idea here is that an addition to the api just can’t break anything and therefore is the first thing to try. It worked so far but comes with one problem: There is no common Switch or iobox that works with that new pin. So as a patcher you only can directly connect a value/string/node pin (…) with that “dynamic” pin. As soon as you want to modularize you run into the problem that you can’t decide which iobox to use…

Because of this i will now also have a look at a better alternative which would make any pin type a descandant of the rather abstract nodepin. This of course is a bigger change internally and comes with a bigger risk but feels much less of a hack than the other implementation. The basic idea would be that you can create a node input pin very much like in my box example and access the original data source via some interface very much like sketched. No data would be copied for you and you’d need to use the Upstreamslice mapping to get the right data - like you are used to when using node pins. The only difference to the sketch would obviously be that a valuepin already supports a basic interface, that let’s you access that data and so you don’t need to box it yourself. But you might want to already test the api as sketched since the final outcome would only simplify the patch (get rid of the box nodes) and wouldn’t need that much modifications in c#.

More feedback is coming after upcoming bug fix beta release.

@gregsn:

Yes I guess move all pins to node type has a bigger risk internally, since it also implies potentially changing more core bits. It’s for sure the cleanest way to go tho.

If some changes are in alpha can try those.

bump.

from my side setting the mainloop from a plugin (aka time) could be a powerful feature in many cases.
so it would just be interesting if one of the devs could estimate how much effort it would take to implement such a thingy.

best,

m.

@milo:
it depends on which clock features are needed in the end.

possible priorities:

  • set clock from a special plugin that gets called as late as possible (just at the right time when vvvv needs to pin down one official current frame time.) if latency is a big topic then we need this feature and therefore a different api than just setting the time for the next frame from a standard plugin.
  • there is not one clock, but there are many.
  • we want to be able to patch clocks
  • we want to send clocks and get them recieved automatically by any animation node. With s/r nodes being sensible to distance between sender and receiver we already have a nice mechanism for setting up different clocks in different patches and have clock consuming nodes auto connecting to the nearest clock node. (check the performance penalty that we pay for a receiver in each animation node )
  • we dont want heavy clocks, but just lightweight spreadable time inputs on animation nodes so that we can input a spread of times so we can visualize the future of some animation filter.
  • we want time or clock inputs on patches to be able specify clock/time from outside, again without the need to connect to each anmation node.

let’s hear what is needed and decide for one way to go.

check out the alpha for the easiest solution i came up with: There is a new clock node Clock (VVVV) which outputs the real/original frame time. It allows to input any frame time you want and if triggered within this frame will set that time for the whole upcoming frame. If set will be used in animation filters and the plugin interface.
That way you can patch clocks (check the help patch). I didn’t change the plugin interface for now.

Please give it a shot and see if you can use the clock node for your use case.
Danke!

he gregsn - big thanks for the fast response - i have to test it a little deeper but for the first look its wow!
just to get it right - this node is about to set a global clock (independent from v4s ML) which all timebased nodes use to calc their states - so ML and Framecounter will go on where it allows to stop timebased nodes or even go backward if i input a negative time - as far as i see. (which is awesome!)
for plugins this will not affect evalutation but could be read via IHDEHost.Frametime (but at the moment not set) from inside.

so ja from my point of view the question about latency is definitely an important topic because iam not sure what happens if the patch gets loaded and is not able to set the time within the current frame anymore. from my side this would be the priority - but maybe others have different thoughts on that.

would it further be possible to combine different concepts? because beside a heavy latency aware master clock - the idea of multiple (sub)clocks for (sub)patches sounds very very useful too. so if the animation nodes would have a time input this one could be used for such a clock - if there is no time input set - their would listen to the masterclock.

1000Dank,

m.

@vux. please have a look at the latest alpha.

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.

@milo: i added the low latency way of setting the clock via plugin interface. i added more comments in “girlpower\VVVV Plugin API\Time”.

sounds amazing - i will check that! thanks for your efforts!

m.

nice one gregsn!

well the comments are in the source code of the dyn. plugin “TweakTime”… the rest is play

He gregsn,

unfortunately there is no such folder ord dyn. plugin in lates alpha - or did i miss something.

m.

@milo. strange. since it is here: https://github.com/vvvv/vvvv-sdk/tree/develop/vvvv45/girlpower/VVVV%20Plugin%20API/Time.

but you’re right. it is not in the alpha build… hm. i’ll have look… please wait.

sorry. the build failed randomly. it is up now.

edit: still 64 bit is broken. here is a working build: http://teamcity.vvvv.org/repository/download/vvvv45_alpha_x64/9757:id/vvvv_50alpha34.101_x64.zip checkin as guest

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.

Typo discovered: I think INodeIn.GetUpsreamSlice() was supposed to be rather INodeIn.GetUpstreamSlice() with a T

Also discovered that new interfaces (like IValueData, IColorData etc…) are not included in nuget packages of plugininterface?