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