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

As soon as I can use Vuo to

funwithstuff's picture
Submitted by

As soon as I can use Vuo to create FxPlug4, I will shout about it as loud as possible. Right now I can’t release anything serious as there is no M1 support. But there certainly are plenty of possibilities.

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.

GeorgeToledo — Rather than a

jstrecker's picture
Submitted by

@GeorgeToledo — Rather than a flat-out "majority rules" system, ideally what we'd like to see is people not just stating opinions in favor or against, but explaining why they want something. That's why the community agreement goes further than just "criticize ideas not people" and says "when criticizing, we discuss specific points."

When 8 people strongly support an idea and 5 people strongly oppose it, that alone doesn't help the dev team or the voting community make an informed decision. Rather, we appreciate seeing comments like @Joëlle's above describing the utility of different color coding schemes and weighing the pros and cons and alternatives. Or (the rest of these are hypothetical): "The MM.Time nodes are really helpful for basic timeline stuff, so I'd like to see those incorporated into Vuo." Or on the spline mapper feature request: "I used an equivalent patch in QC to do such-and-such projects." Or on a new discussion: "How would I recreate this QC composition with timeline animation in Vuo? Would such-and-such node simplify it?"

Reminder to everyone — When you make requests through the bug reports and feature requests system, that helps make sure that good suggestions are remembered instead of being buried in more recent posts.

I’m trying to help you by

George_Toledo's picture
Submitted by

I’m trying to help you by spending my time to write constructive criticism, and that sometimes includes perspectives people don’t find comforting, because that is part of criticism. If you’d like to continue to chide me as a reaction to that effort then please move this to private channels.

I must add…When I state that evaluation of graphs are made more obvious by having color coding, well, I don’t see how Joelle’s statement above is any more constructive or helps solve issues that users bring up. In fact, I raised this point about color coding in reference to a complaint within this very thread about lack of visual clarity, as a possible solution. That is constructive.

Initially, this thread seemed to be taking a bit of a thousand foot view, so it seems totally appropriate to just summarize some larger issues I have in attempting to use the system and to respond to some points raised by others with my own authentic opinions.

I am obviously raising these points in hopes that they get accomplished, because I truly think it would be beneficial to the VUO project, probably much more so than being of any benefit to me. I really regret commenting in the thread at this point, sorry for that.

I must work and organize in a

cwilms-loyalist's picture
Submitted by

I must work and organize in a similar fashion to Joëlle as I too really appreciate the ability flexility we currently have to organize nodes by colours of our choosing as well as miss the QC Macro way of grouping nodes. In fact I was thinking about QC macros on several recent projects so it was nice to see someone else thinking the same thing.

To comment on the use of colours for organizing a composition, there are a few colours I regularly use to identify certain types of nodes; similar to the way QC used pre-coloured nodes to identify different node groups. However for the most part I use the colour options we have to group sections of my composition so I can more easily see which part of the composition I need to zero in one when I'm editing. Once in a very complex composition I used a specific colour to identify what parts of the project I've committed as "working" when I was trouble shooting and playing around with different possible solutions. I'm certainly not opposed to additional organization methods but I really like what we already have as well.

In regard to QC style Macros. While I have used sub-composition from time to time to simplify part of my composition, I find I usually don't want it in my node library as it's almost always a one time solution for a specific composition. So in saying that I really do miss the way QC Macros worked, just simply grouping nodes and making things less cluttered. I also find that sometimes changing nodes into a sub composition breaks what it was supposed to be doing. I haven't figured out why this happens, likely because I am not understanding how events are traveling through them, but it is the reason I rarely use them.

Agreed with Chris here on

keithlang's picture
Submitted by

Agreed with Chris here on approach. I find colours very helpful as a way to label certain types of elements (For example, those controlling logic, or those with video going to the feed as opposed to the UI)

I also miss the QC style macro grouping. And to echo what Chris said, I find the current Vuo subcompositions have resulted in a broken composition due to me placing them in the wrong folder, or changing it somewhere and not knowing it would effect somewhere else. The general idea of a reusable node is good. But without managing dependencies (to use coding terminology), it's more liability than asset, to me.

Even with the QC approach, I often felt the desire to move the 'walls' around a bit. That is, continue to adjust just where the composition meets the sub-composition.

In my perfect world, I would imagine the ability to not only easily make a sub composition, but a one-click share to a public Vuo library. And that this library becomes a searchable one-click-insert flow. Figma does this with plugins, and I find it's a revolution.

I spent a lot of energy and

useful design's picture
Submitted by

I spent a lot of energy and time on GUI design and improvements back in the Vuo alpha/beta/0.n/1.n days and I was passionate about the possibilities and the conversations so I don't really care too hard about the outcomes, but much of what I advocated didn't get adopted. That's life. The general look was improved drastically at one point so that was a great day for Vuo IMHO.

One common point I used to make was that if features requests are perceived by some to be overly complicated or confusing for some users there's an easy solution. Set Vuo up to default to a "no-choice" Vuo stock mode, so in the case of node colours, each node has a default colour in the standard scheme and have a pro user mode where user definable colours are available (both the node colours as user definable and the 8 colours we can choose from are user definable).

If I download a comp I want to work with created by someone who used colours i find disgusting/confusing/inappropriate it's pretty simple, have a menu item that reverts all node colouring to the Vuo stock standard colour. Custom nodes can default to a set colour depending on some relevant assessment of their function, or make all custom nodes a separate colour. Then I can go into "advanced mode" for node colours by ticking a box in preferences or a menu item that gets checked again and I can recolour how ever I want. I have to admit I've wasted time trying to come up with a good set of node colouring rules myself, and end up reverting to select all, one colour, but generally I use the colouring schemes I developed in QC for the canvas notes, there were six colours I think and I would use green notes behind a block on input type nodes, blue for calculations, functional stuff, yellow for image processing, red for rendering rendering tasks etc that sort of thing.

(remember when the patch colours changed in v3 (IIRC) that took some getting used to but then it was fine in a few days, though I did miss the extra colour for input device patches)

I often suggested that Vuo could have a preferences dialogue box to set all these conditions, but sometimes Kosada said they didn't want too many preferences, which I didn't really understand. QC had loads more, any Adobe or 3D app has hundreds of preferences you can set. Pro tools have lots of preferences because creative users tend to have different needs, ways of working and perceiving information and tolerances for "superfluous" features.

My FR is for a vastly expanded Preferences modal dialogue to cover all the disagreements on threads like this where both outcomes are possible concurrently in the same Vuo app if there was pro level user preferences.

thinking on this some more,

useful design's picture
Submitted by

thinking on this some more, having a hackable XML(?) file with the default conditions for things like node tints (0 to 9) RGB values, standard or advance modes (boolean flags for each feature to turn it on or off), node title font face, node title font size, port font, port font size, node corner radius (the nodes still looks a bit Duplo™ rather than technical Lego™ to my eye but I'm sure that's entirely subjective) etc etc would open up lots of room, maybe user definable fonts for node labels would break too much Editor code, I seem to recall us that having convo with Kosada a long time ago. But at least some of these things could go into a file that we can edit and have other versions saved in our own system.

@Joëlle much of the Origami

useful design's picture
Submitted by

@joëlle i think much of the Origami Studio nice stuff is because they built on top of QC which was already nice but needed lots of shortcuts and integration with graphic design tools like Sketch, which is commonly used for app UI/UX desgin. Things like single key strokes for ubiquitous patches, value printing on the ports all that stuff, and some of their developers came from the Apple QC team prior to working on Origami plugin and then Studio . The GUI is very slick, as they seem to have loads of devs working full time on it though and many in house users at FB constantly pushing for new features. FB has ridiculous amounts of cash to throw at tool development too. We are in a different boat here at Vuo, but i'd love to see some of the Editor craft of Origami adopted in Vuo. I guess node shortcuts would be somewhat of a challenge, given how many nodes Vuo has and not a lot of them are what you would call ubiquitous.

Magneson I expect you are

useful design's picture
Submitted by

Magneson I expect you are correct about shedding the QC ways when it comes to Vuo. I haven't used Vuo in ages and just tried to make a simple demo app of the classic animation case for when to use what in QC was called the Integrator patch. (too avoid the jerking/juddering when you adjust a user input for something like the period of an LFO that is feeding into rotation value).

Even adapting example comps I couldn't get a curve (why don't curve/wave/animate have their own example comps, that's the stuff novice users go to first isn't it?) to receive it's time input from a Window from Layer node (that used to be the way to do it right?!). Gave up in frustration, it was only to put in a feature request for Integrator. Perhaps the Count patch does the same thing, but I couldn't tell inside 5 minutes i could be bothered trying. I feel like I'm trying to do Lego with boxing gloves on in Vuo, even when I was a little bit into the flow of it a few years ago.

I think a time port value that can just be selected from a drop down to sync with composition run time or system time would be good as you described it. I tend to use After Effects now rather than Vuo because I get a bit frustrated repeatedly diving down rabbit holes to try and work out things I haven't learnt yet, or learnt and forgot about it. In QC i could conceive of a composition in my head one day and pretty much then spend a couple of hours building it the next, i wouldn't have to go down rabbit holes, though it was easy to get distracted with all the possibilities for variation. But the way to do things in QC seem pretty natural to me, as you said start with primitives ('box') and then modulate and iterate until you get there. Hide itsy bitsy state logic in macros and never think about them again.

Learning a new language like Haskell I understand that sometimes a big learning curve is the price of admission, so I'm sure it is me not Vuo that has the problem, but QC had an on-ramp that was manageable and even exciting with instant gratification at each novice level step of the way. Plus a vibrant Kineme community too which really helped us all learn, along with Steve, Chris and Jaymie devoting lots of time to some of us who were keen to learn more and commission plugins for custom use scenarios.

I was building applications using Kineme's App Builder that were used in stadium events for international sporting events, I wouldn't be confident of quoting on doing something in Vuo at this stage because i don't feel like I can be confident it has my back on all the basic stuff I'm going to need. Again, that's probably me, but I'm part of the target audience. All software needs a "killer-application" to get it over the adoption hump out of extremely niche and into mainstream adoption, I really hope Vuo finds it's professional audience "killer application" soon so funds can drive it forward at a faster pace.

I don't care if that adoption "sweet spot" includes me or not, whatever that minimal viable product is in the mainstream motion/animation/effects/theatre/installation/museam industries Kosada should be patient and persistent in finding then targetting that user group, in my opinion. My spot is compiling to motion/visual effect plugins for all the NLE so i can release commercial products, a decade worth of QC effects and ideas which i could port to Vuo if I could sell into all those markets not just FCP X/Motion, it's too small a user base for the time investment, I think, could be wrong. I might even by FCP X or motion next year so i can see what Vuo comps look like inside an app that is more powerful creatively for visual effects, then I can speak with a bit more authority maybe :-)

Nice ideas keithlang

useful design's picture
Submitted by

Nice ideas keithlang!!

  1. Easier sharing that's killer but I expect would take as much web programming as a serious FR in Vuo itself.

  2. Easier packaging a bit like my FR for Node Code Editor (in C) node and have Vuo do all the QT wrangling behind the scenes. Ultimately it would compile into a set/family of nodes in the one file, as when users manually create them, right? Not sure how we would manage all the settings to execute the compile inside the Vuo Editor though… nodes don't have any Cmd+"2" special inputs options the way QC patches did for unique data types.

  3. Nicer neatening honestly don't know why QC/Origami wasn't appropriated for Vuo, it's streets ahead to look at and navigate around the composition. Different for difference sake isn't always desirable or necessary, even from a marketing perspective, especially from a marketing perspective. Fortunately Vuo has been coming back towards a Origami/QC look, still too much junk hanging off the nodes for my liking but I guess it has a functional rationale. I also did some work on tidying up drawers before the Vuo GUI was redesigned for v2.0. See drawers that open and close and detach from nodes here.

  4. Sub-compositions vote here if you value compositional sanity!! –> https://vuo.org/node/1723

  5. States Yes. I hear you on this. I can't even.

  6. Easy to read I used to put notes under entire blocks of code in QC with a comment or two in the note to describe the function/states etc and to track version control on really big compositions. Would have loved for them to have been selectable along with the nodes so i could move them together not one at a time, but worth the extra bother to have visual guides to the composition for when I come back in a months time and have no idea what i did back then! I liked your align nodes to top/centre/bottom/cable suggestion elsewhere. I spend a lot of time frigging around with OCD attempts to make compositions look neater. There has to be a better way.

I feel like the 🐘elephant in

keithlang's picture
Submitted by

I feel like the 🐘elephant in the room is Vuo's small customer base.

At the same time, I've been playing with Bubble.io for some web projects. I had initially wanted to make a little website that let people put their company logo automatically into a nice 3D Zoom background (not original idea, I know)

But the tools to do this are like, to quote Steve Jobs, baby software. Just doing the most basic compositing of images requires paid plugins, and the UI looks like the very first pass.

Alastair I'm at what ever

MartinusMagneson's picture
Submitted by

Alastair I'm at what ever floats my goat as fast as possible. For some things it's Vuo, for other things it's whatever would be the appropriate tool - or usually a combination of several. Regarding the time outputs, they have changed. I don't remember now which version that happened in, but to avoid cable clutter and increase clarity you now use a fire node (or several) and get time from that instead. The "Updated Window" port only reflects changes to the window (resizing etc.). For timing you now can use for instance a "Fire on Display Refresh". This way the graph flows more intuitively from left to right. To ease you back into Vuo, maybe my compositing tutorial found here: https://vuo.org/tutorials could help? It should at least list a few pitfalls that are good to know about.

When I got into QC there were quite a few addons from the community that were widely used, but perhaps more specific in nature than what is the case for Vuo's nodes. Some also had more interesting and somewhat self-explanatory names, like the Rutt Etra node from Vade. That one actually has an equivalent in Vuo named "Displace 3D Object with Image". Search for "Rutt Etra" on google, and it is pretty telling what the idea is. Search for "Displace 3D object with image" and you'll get Github or some smelly 3D-software forum. There are also more steps to the Vuo approach to get to a Rutt Etra-like composition. With the Rutt Etra node in QC, you could pop in an image, and you were ready to go. With the "Displace..." node you'll have to feed it an image and a 3D object made up of lines. To feed it that object, you'll have to make it first and shade it the way you like. The Vuo way is infinitely more modifiable in itself, but also a lot more fiddly to get going quickly if you're not used to the tasks. I think the idea is that someone should make a Rutt Etra subcomp, share it, and then it will get easier for others to look inside and tweak. But nobody does.

I'm also not sure how many has actually looked around in the node gallery and tried out some of the custom nodes. I have at least 3 votes on my list tools for instance, but I have no idea how many times it has been downloaded or been in use. I make these nodes for myself so I don't really care isolated speaking, apart from them perhaps being a starting point for more people to create their own custom nodesets (which you should, my source is in the sidebar if that helps, and the API is neat!). When good ones gets shared, that would in turn benefit me. I think there are several nodes both from myself and others that are both convenient and expands the possibilities of Vuo that should be checked out by more people if the votes are anything to go by.

For neatening I think sub-comps (as Macros) should be the way to go for the most part. When that is said, I find sub-compositions somewhat sluggish to work with at the current iteration (could be due to old mac, got a new one waiting for me at the office). I was working on a huge tutorial about UIs in Vuo that includes how to pack things into subcomps for clarity and sanity in a build. However I think I hit a wall with a bug somewhere, and it kind of fell into the backburner, and then time happened. Conceptually sub-compositions offers a great way to both stow away and ease complicated and repetative build tasks, but a more cohesive and quick workflow surrounding them would be nice.

"That one actually has an

cwilms-loyalist's picture
Submitted by

"That one actually has an equivalent in Vuo named "Displace 3D Object with Image". Search for "Rutt Etra" on google, and it is pretty telling what the idea is."

Magneson it is important to note that the Vuo Team has taken the time to ensure typing more advanced terms like "Rutt Etra" into the Node Library search pane will still bring up the appropriate, more commonly named node "Displace 3D Object with Image". I think this is a good balance of ensuring newer artists aren't overwhelmed with confusing, albeit more accurately named, terminology but also allow experienced artists from different backgrounds to find the nodes they are looking for.

I think that meta issues will

George_Toledo's picture
Submitted by

I think that meta issues will always tend to lead to disagreement of opinion between members of user base.

When brands change labels, coloring used for advertisement, some will voice preference, some will not.

Certain types of issues are fundamentally style related.

When it comes to the issue of how people express concepts, focusing on the style of expression is also “meta”, as opposed to focusing on the underlying content.

I will suggest that focusing on pure functionality will always be the bigger win for achieving a wider user base and more impressive showcases of VUO being used, as opposed to focusing on meta issues.

I believe that in any discussion of ideas, taking the discussion into meta territory is typical fruitless and grinds any forward movement to a halt.

I think that when one is using a system such as VUO for the intended purpose of achieving some end result in programming, that the most important issue to the user is actually whether or not the end result can be achieved, and that style issues such as the look of the editor, the name of nodes, the app logo, etc., etc., are as unimportant as could be. Even when a user may have voiced some style preferences on a more general level.

I also believe that feature set can ultimately guide style issue choices, and reveal what is relevant and what is not. Sometimes it is possible to spend a great amount of time deciding the perfect look, name, font, etc, but as the underlying content gets further developed, the earlier style level choices don’t seem to work as well and everything winds up getting redone.

—-

On the side discussion of color coding, I find that I have had graphs with color code schemas that had some logic behind them at the time that becomes utterly lost on me when opening it up later. The interesting thing about having functionality of color code be based around evaluation, or at least an option for it, is that something meaningful and standardized is conveyed to any user that opens a graph at any time.

I hear what you are saying

Joëlle's picture
Submitted by

I hear what you are saying George but things like colour coding, node naming, being able to search with names mapped to QC, the notes and details added to each node that was missing in QC etc. contributes to an overall improved user experience. This is not just "styling". The UX of Vuo is way better than QC and it's finding that balance. Origami improved a lot of things in QC but this was not native and ran super slow if you exposed the values on the nodes for example. There is also not much use having something purely functional that is not intuitive to use, I feel Vuo has done a lot of good work in this area, a huge amount of effort has gone into the documentation too.

I like to add coloured coded notes with my colour coded nodes so I understand what they are when I open up a comp at a later stage. Anyway we are talking about this ad nauseam but I don't think it should be all about function over form. Yes we have different ways of working - as a product designer I've appreciated the care and attention taken to the details even if I don't have a native particle node yet for example because even QC particle node was crap and we used external plugins.

Magneson I actually don't visit the node gallery too often! I should do!

Pages