Forum

Plugin interface feature request

vvvv beta question
#1

Hello, here are a few feature requests that would be handy to have (mostly plugin interface based).

  • Allow to set vvvv time from plugins (instead of readonly) : Would be really useful and should be rather easy to implement.

  • In node plugin interface, we have a connection handler to tell if a pin can accept a connection. However for now it only works with node pin types, would be great to have custom node pin that can also accept value/color/string/transforms

  • Input pins to accept multiple outputs: In many cases I tend to have connections that only need to register for event, and this forces to have cons for datatypes everywhere, which is rather cumbersome (also makes it harder to have connection events since custom cons node needs to dispatch them).

That’s it for now

#2

what would you expect from setting the time? non real time rendering?

time is time is time… it should not matter when it starts or whats the value. if you need a custom time in a plugin you can add/subtract an offset. setting the time from inside a plugin might lead to unexpected errors in timed nodes like filters and LFO.

#3

That’s exactly the point, to get rid of all those offset which make a mess, and be able to set this time value from anything (midi clock, timecode, osc) once and for all, instead of passing it by all around in the patch.

#4

Speaking of practical benefits,
the second and the third request would allow vux to implement a new multibuffer renderer.
it means you could create multiple buffers and have access to them (read-write) from the same compute shader.
this would represent a huge step forward in particle systems, in terms of performances (avoiding big struct) and features (advanced and clever emitters algorithms, spatial hashing,…).
It would be also a new general way of manage data at all the stages of the rendering pipeline.

Since dx11 is the main graphic API of vvvv (I hope there are no doubts about this), it would be great to keep it growing and improving :)

cheers

#5

quoting vux: “…the main point is to have “implicit cons”, since registering connections is also an utter pain in current way to do things”…

#6

+1 for implicit cons (and hey, why not time too :))

#7

a comment from devvvvs would be appreciated.

thanks

Natan

#8

as far as I remember time in Quartz composer works the way Vux describes. I would LOVE this in v4 too. This would make using an external sequencing tool (such as Ableton Live) with v4 much more productive.

In fact i totally need this for the project I’m working on right now. And the one before, and the next one :)

I’m massively also in favour of anything that is needed to make a multibuffer renderer.

It’s all about dx11 for me

#9

i’ll report back

#10

few inspiration videos…


#11

thanks Gregsn

#12

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)

#13

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)

#14

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

#15

external time sync sounds very useful.

#16

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.

#17

@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.

#18

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.

#19

@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!

#20

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.

© vvvv group