Hey y'all. The Vuo development team has been discussing the next releases, and we wanted to share our current thinking and get your feedback.

As a recap, we've made these releases in the past year:

  • Vuo 2.1.0 — video streaming with NewTek NDI and RTMP, other new/updated nodes
  • Vuo 2.2.0 — macOS 11 support, new nodes
  • Vuo 2.3.0 — native support for Apple Silicon (M1/ARM64), new nodes
  • and bug-fix releases in between

Over the next few years, our (somewhat competing) goals are:

  • Fulfill some of the top-voted feature requests from the community.
  • Keep up with changes to macOS.
  • Make Vuo cross-platform.
  • Continue to fund Vuo's development.

With that in mind, here's what we're thinking for major features in the next couple years:

Aside from keeping up with macOS changes, we selected the features for Vuo 2.4.0-2.6.0 from among the community's top-voted feature requests, and would select similarly for Vuo 2.7.0.

During this time, we also plan to work toward cross-platform support. Specifically, we'll be starting on the ability to export compositions to either Windows apps or Linux apps. This will be a multi-year project that we plan to make progress on gradually as we continue to add features and fix bugs for macOS. It won't be anywhere close to done by Vuo 2.7.0, but we would like to reach the first major milestone by then: completing the groundwork needed to be able to compile and run a simple "hello world" composition.

And of course, we'll continue with the other work necessary to keep Vuo going, including:

  • Doing work for hire, which provides the majority of funding for Vuo. Currently we do a lot of web development and a little Vuo-related development. We'd like to shift the balance to more Vuo-related work if we can.
  • Promoting the work that people have made with Vuo, and trying to help people who would find Vuo useful but have never heard of it before to find out about it.
  • Providing free and paid support to the Vuo community.
  • Working with the developers of related software like VDMX and CoGe to help with their Vuo integrations.
  • Making improvements to the open-source software that Vuo relies on.
  • Updating the Vuo website. (It's on Drupal 7, which is reaching end of life in 2022, so we need to upgrade to a newer Drupal version.)

So that's what we're thinking. If you use Vuo in your work, how will this plan affect you? Do you see anything important that we're overlooking?

Comments

A SoMe plan could look

jstrecker's picture
Submitted by

A SoMe plan could look something like:

Cool, we appreciate the concrete suggestions.

Based on our experience so far, the #MadeWithVuo-type posts are the most effective. They generally get a positive response in terms of likes and comments. It's nice that they're not only promoting Vuo but also promoting the artists/creators who use it. So we'll definitely continue doing those as much as possible.

So far it seems like the social media channels are useful to Vuo's current community but not reaching many people outside of it. The most active one is the Facebook group. Whether that's stacked up enough content to reach the status of inviting veggie section (to quote Magneson), I don't know, but it also doesn't seem to get many people walking by who will see the veggies.

I feel as though I used to be

George_Toledo's picture
Submitted by

I feel as though I used to be able to make a lot of noise for Kineme and bring people into the fold but it was contingent on working with Chris and having cool features that I had a gut feeling were necessary get accomplished.

A long time ago now, I think I made a piano key visualizer and had the problem of controlling the colors of each key in an array separately. Are we any closer to being able to do that? I’m guessing not.

I have found the voting system to be generally frustrating…I guess there is some arrogance to say I think some various points I have brought up, features or whatever, are simply more important than features that may have many votes. But I definitely do think that.

Absolutely not trying to rush

funwithstuff's picture
Submitted by

Absolutely not trying to rush anyone, but just curious — how far away do you think FxPlug4 support is? It's currently scheduled for Vuo 2.4.0, and wondering if you have a rough idea of when that might land. Thanks in advance, and keep up the great work.

Vuo 2.5 promises to be many

useful design's picture
Submitted by

Vuo 2.5 promises to be many Christmases at once. For a software project that in Alpha had scoped out lambda programming it's curious to me how long core functional programming fundamentals like recursion, iteration, lists of lists have taken to make their way into the beta code base.

The term Swiss Army knife is often seen as pejorative term when applied to software tools (often I've heard that term used to degenerate Adobe Illustrator) but I think tools like Vuo really do need that versatility but comfortable use for non-industrial-strength graphics programming tasks, especially in the art and design fields. Too often with Vuo i find the tool im looking for doesn't exist, not to do something special, just to manage data in what would be a fairly trivial way in a text based programming language.

If lists of lists and iteration work well, this might be a redundant observation I'm going to make in the next sentence.

A scripting node which can compile it's text-based code (in whatever language Vuo decides is most appropriate) with getter/setter functions for existing and user definable types would be of tremendous utility in opening the scope of Vuo solution sets to creative problems. It would also relieve Kosada of the need to do everything in-house when it comes to providing users with more power and tools. The user community for scripting would be much bigger for scripting in a modern language than for node development in C i hazard a guess, it would if JS in QC is anything to go by. Python (that can compile) or Haskell would be cool but probably too much work to maintain maybe?

GeorgeToledo Controlling

MartinusMagneson's picture
Submitted by

GeorgeToledo Controlling separate colors in an array (or list rather) has been possible for a long time. The issue with it is how to control it from a good UX point of view. To be hassle free, you have to implement a data structure to read from and save to when needed to avoid initializing a blank list and setting it up each time. This can be done with tables, json, csv and probably a few other methods as well. There is no ready-made solution though.

Alastair The implementation time can be seen as both a strength and weakness. I would guess a lot of it has to do with budgeting and time to focus, but there is also something to be said about the philosophy of how things are implemented. There are other applications out there that cost more than Vuo's pro license fee a *month *that's still hiding behind the beta moniker. From what I've seen, and gotten explained, I think that has a lot to do with the underlying code being put together to achieve specific tasks without a strict regard of how it will talk together between different elements. That is where Vuo shines, although it's not really apparent until you start poking around in the API (api.vuo.org). There is a lot more to getting lists in lists than throwing together some structs and enums, especially when it has to translate to every significant element of any type in the code base.

Regarding scripting, I think your own FR (https://vuo.org/node/694) would be a better solution, but again, depends on implementation. Should it have an #include input, library input, header input etc. Those things probably take longer time to figure out than the actual code that runs it.

I wasn't underestimating the

useful design's picture
Submitted by

I wasn't underestimating the challenge of lists in lists in Vuo. It's just that in functional programming (and even imperative programming in an OO environment) it's absolutely core to getting anything half serious done.

I' expect it will help make composing so much more straightforward in terms of the cognitive load Vuo requires of Vuo coders. Well I sure am hoping so anyhow!!

Martinus, it was a scenario

George_Toledo's picture
Submitted by

Martinus, it was a scenario where because of the data source it would have not worked without either some basic QC type nodes (not available in VUO) or writing a custom plugin for VUO.

I think that some suggestions made are basically navel gazing level, whereas other suggestions may have been directly related to doing high profile projects or people needing to make VUO work for professional activity. There needed to be some way of what ended up being the VUO team distinguishing between this but it didn’t happen. These comments are in regard to the post that was referring to not seeing as much activity from founders.

I think that’s possibly as valid of a choice as any, and the team does a good job. I was just opining about cause and effect. I know of another high profile QC user who threw his hands up far before I did and who I discussed this with for similarly reasons. It is also maddening to need VUO to be able to accompany something so you can use it to do professional level work and pay bills, but return to the forum and see people putting so much energy into making the app icon uglier and things like that.

I just have to firstly say

MartinusMagneson's picture
Submitted by

I just have to firstly say that I am kind of agreeing with you about many points, although perhaps not for the same reasons. I know I can read a bit confrontational, which isn't intentional though. I also think Vuo has come to a very capable point at this time. It is however not always too obvious to make the correct design choices early on in a comp, and it can be a bit fiddly to get going with more advanced stuff without a lot of noodling under your belt and the right mindset of how to approach a design. It happens way too often that I'm 30-40 nodes too deep into a problem - that can easily be sorted out with three nodes that I forgot existed.

Regarding cognitive load which is a very important field when it comes to adaption, I didn't manage to utilize Vuo fully until I shed all my preconceptions of it being QC-like or a replacement for it. I find it easier to think about what you want to achieve in a "the spoon don't exist" kind of way with Vuo. This because as you are pushing things down the line, you edit everything "before" you make it. The object you look at in the end is just the result of all the other calculations, and can essentially be replaced with anything else. In QC you add a box, and then you poke around with the parameters of the box. You think about it as a box. In Vuo you prepare all the parameters first, and then you attach a box to it. Thinking about it as a box when you start out with it can be counterproductive as the box doesn't really matter - or exist. It seems like this fundamental difference in the mental process of getting things done in Vuo perhaps is the biggest leap and/or hurdle. I don't think that will change with a script editor - but I might be wrong.

While I do understand the team's wish to keep the editor uncluttered and "clean", I would really like to see an inspector-type pane, and (lockable) tabs to be zoomed in at different areas of interest to help with the organization of larger compositions. I think the want to keep the editor simple, makes it harder to use efficiently. An editor for code (both shader and C), lists and perhaps also Lua scripting of the editor itself would be really nice. Kind of ran with it, but I would think something like this mockup could ease a lot of issues with the editing and understanding of the flow in Vuo:

The most notable part in the mockup is perhaps the inclusion of a trigger/fire/clock option for an input port. This way any node needing triggering could have it checked, and no "Fire..." nodes would be needed. A port mode dealing with simple input mathematics would alleviate the need for a lot of smaller math nodes. For the Time (real) input, a port mode of add, with a value of .25 would for instance easily flip the phase of the time base 90 degrees. This would remove the need for phase ports on nodes. The clock would just add/subtract/multiply with what's at the port. Port modes are an interesting field in itself though, I could imagine "Replace if present" or "Replace above/below threshold" would be neat for list inputs especially. The ability to edit list inputs directly in an editor as opposed to the drawer-method would also be a welcome addition.

GeorgeToledo — Keep in mind

jstrecker's picture
Submitted by

GeorgeToledo — Keep in mind the point in the community agreement about not making generalized negative statements. The purpose is not only to ensure that others can share their work without having to deal with unconstructive criticism ("navel gazing", "uglier"), but also to make sure you're posting suggestions that are specific enough to be actionable.

While Vuo will continue evolving over time, one thing that's not going to change is our intention for Vuo's direction to be determined by the community as a whole. The current feature request system is not perfect. But we don't see it as a problem that someone can request a feature that is essential to them while being useless to someone else.

The ideas for features now in Vuo have come from a variety of people with different use cases. Since Vuo CE is open source, people also have the option to add features themselves or hire a developer to do so. People can also hire the Vuo team to develop a feature that is important to them.

Magneson — Some of your ideas

jstrecker's picture
Submitted by

Magneson — Some of your ideas touch on open feature requests and others go beyond. A few that come to mind are Add more sort options in Node Library, Time Mode/Evaluation Changes, Fire an event from Node when an input value is changed in the Editor, and Edit node C code in the Vuo Editor. It's useful to take a holistic look, like in your mockup. Like you said, when adding a feature, we have to think about how it's going to play well with everything else. As the next step, when you have time, it would be helpful if you could split up your ideas into specific feature requests or add comments on existing relevant feature requests, so that we can more easily refer to them in the future and the community can vote on how to prioritize them.

I think your tutorials on compositing would be useful to anyone trying to understand the thought process behind building Vuo compositions.

My comments weren’t

George_Toledo's picture
Submitted by

My comments weren’t generalized, I think they are somewhat specific.

I was thinking about this thread earlier today, and I believe that what some have suggested is a lack of visual clarity in the node graphs comes in part from the user desired feature to be able to make a node any color. The bigger picture is that it seems constructive to consider how users can sometimes request features that have negative consequences which then outweigh whatever the imagined positives were.

So, I write this as one example of how the majority rules feature request system can end up working. Certain types of requests are always going to be a bit of a wash to some of the user base, because they aren’t directly tied to gaining a feature, to being able to directly accomplish some sort of graphic or interactive programming outcome.

Ultimately this line of thought was all in response to the comment speculating about why some people weren’t as active on the forum. I was actually attempting to make constructive criticism, and I don’t believe that criticizing ideas is the same as criticizing the person who made the idea. The only way to improve any kind of concept is to be willing to be as unsentimental as possible when it comes to revision.

What is the problem with saying I think the initial VUO logo was more attractive and that spending so much time and energy on changing it is frustrating to me when attempting to use the VUO system to do some kind of professional project but finding it difficult to do because of VUO lacking parity with Quartz Composer features? And it is past version 2 without feature parity? That doesn’t even seem compatible with the original roadmap.

VUO is a high quality product with a talented team. I was making an attempt to give some authentic feedback. Sometimes people like things, sometimes they don’t.

Here are some of the bigger

George_Toledo's picture
Submitted by

Here are some of the bigger problems I run into:

-No timeline or value historian type patch makes it very close to impossible for me to use as a system to create and render animation.

-The lack of iteration in provider/processor/render evaluation modes makes it very difficult for me to manage the creation and rendering of groups of objects in ways that are common in motion graphics. Control of size, color, placement of objects, type of objects, etc, not having parity with Quartz Composer makes it difficult to impossible to implement things fully.

-The shader code inspectors are very hard for me to make work consistently while creating, I think because they are tied to the input ports, and having to click in there. They always seem to close on me or get “stuck” in a way that won’t let me click in them in the middle of coding.

-Having JS, as well as third party LUA and Obj-C patches in editor didn’t hurt, OpenCL was great when it worked…having tools along these lines does help.

-Not having a “render in image” type macro environment, or macros in general.

-Having a mode that changes user color coding to evaluation based would add a great deal of clarity for some users.

I think that it might also be helpful to consider allowing people to have custom GUI views for a node, it would really open up what could be done within a VUO graph.

Hopefully these points are taken well. I would never characterize it as anything but subjective opinion, though I am also looking at it from the perspective of usefulness for others.

I want to apologize for any

George_Toledo's picture
Submitted by

I want to apologize for any bad feelings or any feelings that I have been overly critical. I am sure they are right.

It just remains frustrating to have concepts that I think I could pull off with QC, even early-ish versions, then go to open up VUO and not be able to do the same thing. I wind up making concessions about the nuances, or changing the ideas, but there are often fundamental impasses because of the lack of feature parity with QC.

I don’t think it is for lack of competence with the VUO system either, though…maybe!

I feel as though feature equivalency with QC was always the informal promise of VUO - and I think bandied about plenty in public - to the point where it seems like that should take a fundamental level of priority before adding more features that QC never had? I don’t think anyone expected a port of Core Image or anything like that, but I really did expect many more QC patches to have been implemented before 2.0.

I was never a QC power user

Joëlle's picture
Submitted by

I was never a QC power user so a lot of the areas that George mentioned above I personally didn't use or never build from scratch - I was that person that used a lot of George's Core Image patches and shaders :) I have found some things such as cameras and native 3D object support that QC lacked, one of the areas I've loved about Vuo. Vuo 2.5 will bring a lot of missing things I think a lot of us are missing such as iterators and I can't wait for particle systems too!

I actually find the ability to colour code nodes very helpful to visually group things, and to colour code the notes too, however it's an interesting point raised that in QC you knew that purple nodes had a certain function and blue nodes had a certain function and this was useful to learn and distinguish. Perhaps there is another way to signpost this, I don't know. But when I have lots of nodes in the UI, being able to visually group them by colour is super useful and I have sort of created my own colour coding system. There are also so many little UI improvements that I appreciate that speed up my workflow such as the ability to reorganise the order of published input ports without having to republish then (unless I was missing something super obvious in QC lol) and things like the feedback patch which in QC made my computer crawl to a halt.

The one thing I do miss a lot and this has been fed back from another ex QC user is macros - the ability to "group" patches and then publish up to the parent. But I have gotten used to sub comps and they work just fine but this was something that was a bit of a switch to get used to. But maybe this is also part of accepting that Vuo is it's own app and us QC users need to shed some previous ideas about what it "should" be.

As a sidenote I've been working a lot in Origami Studio this week and noticing some similarities :D I wonder if some inspiration has been taken from there as having not worked in Origami for a while I'm finding it easier now that I have a bit more Vuo experience.

I found that in early 2020 Vuo was robust enough for me to make the full switch from QC which I was dreading, I would LOVE to eventually dedicate some time to creating up to date and recent video tutorials, I get a lot of requests for these as the lack of recent learning materials is a blocker for a lot of people I think not coming from QC especially. But we all know how much time this sort of thing takes and it can't be on the Vuo team to create these.

We just need to be a little more patient though I can understand some of the frustrations above - there is nothing like Vuo out there - the next option in my mind is something like TouchDesigner which cannot integrated with eg. VDMX / Resolume - that workflow is special and unique and Vuo will is still perhaps a teenager but once a little bit more grown up I think will be super powerful and adopted widely once we can build up a good catalogue of learning materials.

Pages