I think Apple doesn’t need to market Swift heavily b/c it’s that, Objective C or cross-compile from another language using another tool to access one of the biggest centrally located software markets in the history of computing. Vuo is at the extreme opposite end of the spectrum, it’s entirely niche, so comparisons are going to be fraught.
Oh boy. We have tried sooooo many things for marketing, including: …
Good marketing can be very hard. Especially now with all the different SoMe platforms around. I think Vuo might gain from a more concentrated effort in key areas though. You can separate the current social media into three categories. Instagram (and Twitter to some extent) is for showing off, Facebook is for community contact/outreach, and YouTube is for learning. If these places look “dead”, people are quick to assume the product itself is as well. To manage expectations, I think it would be beneficial to post once a week on each of the platforms, and link to it on Facebook to make for maximum outreach. A website and forum/blog is great, but it is mostly for existing users, not for introducing it to new users (but do mention and link to it in posts). You could also look into social media management platforms that consolidate efforts to one place/tool.
A SoMe plan could look something like:
Mondays:
Devlog post on Facebook, interaction with the community. *Short *updates on what has happened with the code within the last week. Not walls of text, just small treats to show things are happening and what’s important. I.e. a picture of Steve by a computer tagged with “Steve working on M1 compatibility” or stuff like that. Possibly link to a discussion of the M1 on the forums.
Wednesdays:
Post short treats on Instagram, for instance showing off creations tagged with #MadeWithVuo every even-numbered week. Quick tips (no more than one minute long) videos showing how to do basic steps in Vuo (for instance displaying an image 3 different ways) every odd numbered week.
Fridays:
Youtube tutorials talking through how to do more complex tasks like face tracking and applying it, lasting from 3-8 minutes.
10th of every month:
Live-stream lasting 30 mins to 1 hour where you can take questions from the community, have interviews with users, discuss development plans, do in-depth builds of specific cases like live streaming from Vuo and so on.
A really important thing in this is consistency. You’ll likely not get the big influx of people when starting out, but it should improve within a year or so when you have enough content stacked to look big and inviting. It’s kind of like the veggie section at a store. If it looks full and fresh you’ll get drawn to it. If there is a single stale leek - you’ll probably go somewhere else.
3 Likes
I’d love to hear more about the cross-platform plan. Is there a desire for .vuo files to load cross-platform?
Not only load, but create! The graphical performance in recent hardware for PCs has been leaps and bounds beyond what you can get from Macs at the same price point. At the top end Macs haven’t been able to compete since Nvidias 10-series cards, even with systems at half their price. With AMDs recent ventures into the high-end market, this could have changed, but they are more than likely dropping AMD as well to focus on their own stuff which will hopefully be competitive. I’m eagerly waiting for the next iteration of the M1 but am not expecting miracles. In addition, most professional media servers run on Windows (Disguise, Hippo, etc) which would open up new markets and possibilities for Vuo to shine (and make money).
2 Likes
A really important thing in this is consistency
Another important thing is that marketing is done by people with an enthusiasm for marketing. If marketing is just another a chore, that lack of buzz is going to be there in many of the non-verbal cues, and this can poison marketing efforts. I’m not saying that is happening with Vuo, to be honest I wasn’t aware of many of the efforts made in marketing it other than community emails and Facebook page showing the featured artist/user.
I’d certainly consider enlisting help, and also help in determining the viable future direction of Vuo. Passion projects are great, and Vuo has been a passion for all of us at some point, not least the developer team. Realising the kind of market share that can fund growth to the point Vuo starts meeting people’s dreams of 10 years ago takes many skill sets, and even the user community is not necessarily best placed to figure all that out, though I’m sure we can have some good takes.
I drafted a longer reply to @jstrecker’s comments a week or so ago, I’ll see if I still want to post it after re-reading it and time to reflect.
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 @MartinusMagneson), 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 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 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 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?
2 Likes
@George_Toledo 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.
@useful_design 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://community.vuo.org/t/-/4929) 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.
1 Like
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!!
1 Like
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 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.
2 Likes
@George_Toledo — 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.
1 Like
@MartinusMagneson — 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.
1 Like
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 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 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.
2 Likes
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.
1 Like