Plan for next releases

Discussions
49

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

50

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.  

51

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.  

52

Agreed with @cwilms-loyalist 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.

53

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.  

54

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.  

55

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

56

@MartinusMagneson 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 :-)  

57

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://community.vuo.org/t/-/5751

  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.  

58

I feel like the :elephant: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.

59

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

60

“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.”

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

2 Likes
61

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.

62

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.

@MartinusMagneson I actually don’t visit the node gallery too often! I should do!  

1 Like
63

Joelle,

If you heard what I was saying, you wouldn’t reply that way, because I am not suggesting to eliminate the ability to color code.

Here’s the third attempt at writing the same thing…

Someone in the thread wrote that the graphs are confusing. I partially agree. I wrote that some sort of mode to reveal graph evaluation, whenever colors being tied to evaluation type would be desirable.

I was actually a big advocate of users being able to choose custom colors in the early pre-release stages of planning VUO. Now I see there are issues.

Anyway, when users mention problems, my mind goes to “how do you solve this frustration”, not to deny that there is potentially an issue. Reflecting on it, I think there is a huge issue when it comes to the graphs no longer being able to visually convey evaluation.  

64

You could actually do a lot with the stock QC particle node, because you could place it inside a GLSL shader environment to influence the movement and have more control over the textures. It wasn’t the greatest thing in the world, but I could do plenty of cool looking stuff in five minutes time that I think are impossible to do in VUO without making some sort of custom node(s).

And of course you could do OpenCL particle systems directly in QC, lol.  

65

I must have completely misread your last comment then somehow. :roll_eyes: The language that you are using to communicate your thoughts is coming across somewhat negative and hostile.

Ps. I wasn’t advanced enough to do OpenCL particle systems. I’m a noob with GLSL too. I’m a designer who learned a bit about code. Sitting here making snide comments is quite frankly unhelpful. This is meant to be a positive space to discuss Vuo. I’m out.  

1 Like
66

Yes, you apparently didn’t focus on the part where I suggested evaluation could be revealed through a mode.

I find that your post in response was very snide, as is your eye roll emoji. You misread my statement, I have alerted you to that…and now you choose to lash out.

I’m attempting to have a professional level discussion.

I see that my criticism of all of the time spent revising the logo could be considered “coming in hot”, but I was just trying to convey my feelings as a user. When you rely on a system like this for professional endeavors, and you can’t get things done because there isn’t the raw functionality, and every time you come on the forum people seem to be spending a lot of energy on revising a logo…well, I found it frustrating. The bigger picture is that I was trying to express that I thought maybe other users may have felt similarly.

I also see that asserting that more weight should be given to users who do high level projects or use the system professionally, and my suggestion that it could be perceived as arrogant…actually put in people’s mind that it is arrogant. But in fact, what long lasting company that finds itself in similar circumstances wouldn’t put more weight on the views of some select group of professionals? I think it is completely reasonably to criticize the functionality and efficacy of the feature voting system from this standpoint.

If my thoughts come across as negative, it is probably because the main emotion that VUO triggers in me is frustration, and I guess that has pervaded these comments.

I apologize for offending you in my attempt to clarify my comments. I have spent a lot of time and energy trying to benefit people within the community, and that motivation is the reason I’m spending my time right now getting grief for my attempts to give suggestions that could help make VUO more popular.

Maybe my perception that I helped make a lot of people aware of Quartz Composer and Kineme, and thus have some sort of insight into how that may be repeated, is simply in error.  

67

Maybe something fruitful for the team/community would be to solicit opinions concerning VUO from other people who were perceived as high profile QC users, such as Vade/Anton, Momo, etc.

I have felt attachment to VUO from being part of the team that conceived it, and having a license in perpetuity as trade for those contributions. I am sure that initiating some of the fundamental concepts behind VUO colors the language I use when it comes to my opinion about the path it should take.

There are other heavyweight QC users who have never delved into VUO as much, and in some cases have been far more critical than I have. I still think it would be worth the effort to attempt to appeal to those people.  

68

Since this thread is no longer contributing anything constructive to Vuo development — in fact it’s now taking away time from Vuo development — we are closing it.

@George_Toledo, as I said before, your comments are out of line with the community agreement. It sounds like you disagree with some of the community agreement’s principles, or have a very different interpretation than what we intended. As we have stated, we want all Vuo community members to feel welcome and respected. If you can’t abide by the community agreement, then please don’t post on vuo.org or Vuo’s social media groups. If you continue to post comments like this, we’ll have to ban you. On the other hand, if you can approach Vuo community members in good faith — e.g. not making statements like “If you heard what I was saying, you wouldn’t reply that way” and not disrespecting people with different skills than yours — then you are welcome to post. If you have further concerns about this thread or the community agreement, you can contact us at info@vuo.org.  

1 Like