@Smokris I was wondering if/how custom nodes could speed up Vuo its development or at least help the Vuo team rather focus and spend time on some fully non existing features.
For example, @vjsatoshi made a great particle emitter node. How could we bring it to users the best way ? How could we get most users to use it ? And therefore how could we get users to vote for some more urgent nodes instead.
Should there be a “Community Nodes Download” page on the website where users could post some nodes ? (beside the composition gallery page).
Should these nodes be implemented in Vuo Releases under a specific “Featured Nodes” section or notification ?
Or could the community be able to submit some custom nodes + source code that could be reviewed by the Vuo Team and then directly integrated into releases ? (with some minor changes, what could reduce the time spent creating nodes from scratch).
Or could some users even be able to sell the Vuo team some custom nodes for some dollars ?
Perhaps these users could be part of a new Vuo group (beside integrators) ?
Perhaps there could even be a “Custom Node Marketplace” like page on the site. Where users could sell their nodes for some bucks ?
This could be done with the Particle Emitter Node until the Vuo team decided to spend some time designing their own emitter from scratch ?
Just asking because I really think there are some great guys like Satoshi & @George_Toledo doing some great job out there too ;)
And because when I see how many people voted for this particle thing, I wonder if they know Satoshi’s one, because I’m using it for a while and it works great, so I keep my votes for some fresh new stuff :)
These Feature Requests could even be kept pending and hidden until the Vuo team produced their own, and link to some featured nodes.
We’re thinking of making a Node Gallery similar to the existing Composition Gallery. The focus would be on free, reusable nodes (rather than final compositions like the Composition Gallery).
If people have developed Vuo nodes they’re interested in adding to Vuo itself, we’re happy to consider that. We’ve already talked with a few developers about doing this.
If people want to sell their nodes in a marketplace on vuo.org, we’re open to that, too. Contact us if you’re interested, and we can discuss the terms.
Also, if a feature request is similar to an existing 3rd-party node, feel free to leave a comment mentioning that node — people might appreciate having an immediately-available solution.
Perhaps when you make the node page, write on top you can consider adding custom nodes to Vuo and also mention you could push a marketplace if users were interested…
Some users surely does not know this would all be possible, and possibly some users would be motivated doing some custom stuff (like Satoshi, Toledo, Vade …)
If one made nodes to sell to Vuo community could they be compiled binaries (maybe all custom nodes have to be compiled prior to use in Vuo editor, I forget now)? Would there be a way to licence them for better security? (not that it’s a concern for now but just wondering, like if Noise Industries released their excellent text handling QC nodes ported for Vuo — yes please do it @vade, because graphic design level text control is way too hard in Vuo and QC without the FxPlugins). Alternatively something that can do a subset of HTML/CSS just for the text handling, maybe?. Anywho bit OT question was licensing.
The VUO team has done a good job on the node API… so far I have really enjoyed using it.
What I had the hardest time with, was the fact that it has been a moving target and has required plugins to be recompiled in order to work. Which is fine, and understood. But I’m unsure if that’s going to be the norm or not as new versions come out. I think it was maybe only a problem with a certain subtype of node that I was often making…
Compositions not having their cable connections when restoring in those cases, makes it harder to figure out what was going on with example compositions, at least for me. Especially when there is some sort of feedback going on.
When I went to update the SDK at some point, it wasn’t working…but now, for some reason, it does!
Anyway, all of those factors got me a bit bogged down on keeping the nodes I have posted up to date as new versions of VUO have come out. So that damped my zeal for making new nodes for the moment - again, through no real fault of the VUO team, they have to keep advancing the system, and if it makes old nodes not work, it’s still overall better.
I was asked if I would like some of my nods to be incorporated into the VUO core, and I thought I had replied that it was fine by me, but I haven’t seen that happen.
I think one thing that VUO team could do to encourage third party node developers is to give them a license if they have developed X amount of nodes.
@George_Toledo yes the outdated nodes as you mention can be disturbing.
I don’t know the technical reasons for that but I would like to know about it too.
Some of your nodes that didn’t work in let’s say 1.2 would sometimes for again in 1.3. Some either just don’t work, some stop the composition from running to show the “some nodes are outdated” window list (where the list should be shrinked and scrollable because on small screens, it pushes the “ok” button below the screen edge on smaller screen (f.e. on my 13" screen). I will report a bug report for that).
A least perhaps the node gallery should have a filter by last Vuo version tested / updated.
On the very long terms, I wonder what would be better, to have different gallery pages (nodes, compositions, apps, screenshots, FX plugins, screensavers) or have one that would list them all, but with filters. Like I could check the filters to see only the submissions that have nodes and apps, or only FX plugins etc …
I remember @alexmitchellmus submitting the idea of rewards for nodes and code. Steve seem to have answered this recently here and updated the how do I get votes to reflect that. Just wanted to be sure you had seen that.
were those nodes not working due to changes to the native Vuo data types? I vaguely followed the launch of VUO beta and recall many nodes had to be written in multiples to handle different types. then there was a planned architectural change that allowed them al to be ruled into single nodes. is that still an issue in some ways? I’m only just scratching the surface of Vuo with one decent session under my belt. But what if you create new data types, can they be passed to existing Vuo nodes for list manipulation or such like functions or is it impossible?
If one made nodes to sell to Vuo community could they be compiled binaries (maybe all custom nodes have to be compiled prior to use in Vuo editor, I forget now)?
Nodes made with the SDK are already distributed in a compiled format, though not exactly a binary. The .vuonode file can be either an LLVM bitcode file or a zip file containing LLVM bitcode files. The LLVM bitcode format is not machine code, but is sort of the next level up from assembly code.
Nodes implemented as subcompositions are currently distributed as .vuo files, which are a kind of text file. Internally, they do get compiled to .vuonode files as well.
Would there be a way to licence them for better security? (not that it’s a concern for now but just wondering…)
Yes, there are various ways that could be implemented. (The LLVM bitcode format doesn’t really offer any security, and wasn’t intended to. There’s a command you can run to translate a bitcode file to the fairly-human-readable LLVM assembly language.) If it becomes a priority for you, please create a feature request.
The VUO team has done a good job on the node API… so far I have really enjoyed using it.
Thanks!
What I had the hardest time with, was the fact that it has been a moving target and has required plugins to be recompiled in order to work.
Between Vuo 0.8 and Vuo 0.9, we made a change to some commonly used functions in the node API (VuoRetain and VuoRelease) that required nodes to be recompiled to work in Vuo 0.9.
Since then, have you had to recompile any nodes? I just did a quick test with one of the first Vuo nodes you posted, HSL Filter. After compiling it against the Vuo 0.9.1 SDK, I was able to run a composition containing the node in Vuo Editor 1.0.1, 1.1.1, and 1.2.1.
Compositions not having their cable connections when restoring in those cases, makes it harder to figure out what was going on with example compositions, at least for me.
I was asked if I would like some of my nods to be incorporated into the VUO core, and I thought I had replied that it was fine by me, but I haven’t seen that happen.
Ack, sorry, we’ve been meaning to review them. We’ll really actually try to do that soon.
Some of your nodes that didn’t work in let’s say 1.2 would sometimes for again in 1.3. Some either just don’t work, some stop the composition from running to show the “some nodes are outdated” window list
were those nodes not working due to changes to the native Vuo data types? I vaguely followed the launch of VUO beta and recall many nodes had to be written in multiples to handle different types. then there was a planned architectural change that allowed them al to be ruled into single nodes. is that still an issue in some ways?
I think you’re talking about generic port types? Like how you can right-click on a Hold Value node’s port and the Set Data Type menu pops up? Waaaay back in the early versions of Vuo you would’ve had to write a different version of the node for each data type. But as of Vuo 0.5.5, you no longer have to do that.
But what if you create new data types, can they be passed to existing Vuo nodes for list manipulation or such like functions or is it impossible?
It’s possible right now, though you do have to add an implementation of the list type. (See the node/customType example in the SDK.) In the future we’d like to auto-generate the list types.
@jstrecker concerning George’s nodes that could stop the compositions from working in Vuo 1.0.x or 1.1.x I don’t exactly remember.
George must remember I asked him on twitter if he planned to update them and he answered me he would do it ! I can find that back to see what Vuo version that was.
However, I can confirm all George’s nodes I have work in 1.2.1 now.
One node however I’m sure that still causes the composition to stop for me in 1.2.1 is Satoshi’s Echo Image Node. This one stops the composition even if no cables are connected to it. Dragging it on the canvas causes the stop. His last node version is 1.2.1 lastly tested in Vuo 1.2.0 he says.
There is also Karl Henkel’s Parabox “get mesh” node but it crashes on my macbook and not on the iMac so I think this one is related to my problematic graphic card.
Again, some nice nodes @George_Toledo I’m glad to rediscover they all work again now and am excited to play with them ;)
was there talk of Vuo team maintaining a test-bench of 3rd party nodes or sub-compositons (or both) to be tested against when a new version of Vuo was being prepared for release? I think it was a Pro level subscription feature to have some of a users important compositions tested to make sure they don’t get broken, or if they do to get pre-release notification (or something). Maybe I’m getting this wrong… it’s a vague memory from a fair time ago before subscription model changed.
Alastair, that’s still a thing: How do I use Vuo’s automated test rig?. It was originally part of one or more of the subscription levels. So far nobody has submitted a composition to add to our test rig.