Plan for next releases

Discussions
1

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?

7 Likes
3

Will the Metal implementation include Shadows from Lights that has been one of the most voted for features for a looooooooong time. I’m getting a little impatient for it.
As for FX plug support, I see two or three users who want it, and FinalCut users are very thin on the ground these days. I don’t even remember seeing a job advert requesting a FC editor in the last few years. If you were to implement a cross platform output: making Adobe plugs would make much more commercial sense IMHO.

I assume you’ll update to the newest NDI at some point soon too.
Thanks for all your work to date.  

1 Like
4

I agree with the order of major features and goals you’ve set. I could see when Apple Silicon was announced the urgency for supporting the new M1 architecture, Metal Graphics and the Latest MacOS had became much more critical to Vuo future than any other feature request. In fact there would have been a major roadblock to expanding the Vuo community if it were unable to support the new hardware!

As much as I am looking forward to seeing particle systems happen I don’t see a feature in the list I would put it ahead of it. :)

One question: How does rewriting Vuo for Metal effect the cross-platform goals?  

1 Like
5

Thanks for keeping us informed !

Any idea where Code sign and notarize fills in here, because exporting apps & screensavers for distribution seem broken for recent macOS versions :(

To quote the 2 previous comments, I wonder, what’s the % of the Vuo userbase that export Vuo into Final Cut plugins (or Adobe), vs people using it for VJing, and exporting things using FFGL and that are awaiting stuff like particle systems to create even cooler animations ? ;)  

1 Like
6

Will the Metal implementation include Shadows from Lights

Vuo 2.5.0 won’t — adding Metal by itself is already plenty of graphics-related changes for one release — but maybe we should move shadows into Vuo 2.6.0 and bump particles down to 2.7.0, since shadows has more votes.

As for FX plug support

We did already promise FxPlug 4 in Vuo 2.4.0, so I would hesitate to go back on that. Other than updating NDI, it’s the last piece needed for Vuo to fully support Apple Silicon.

I assume you’ll update to the newest NDI at some point soon too.

Yep. We’re still waiting for NDI 5 to be released, but it should come in time for Vuo 2.4.0.

How does rewriting Vuo for Metal effect the cross-platform goals?

Our plan is to switch to a graphics abstraction layer that can use Metal on macOS and (eventually) the native graphics APIs on other platforms.

Any idea where Code sign and notarize fills in here

Since that feature request doesn’t have as many votes and voters as others such as animated meshes and iteration, we’re thinking it would come sometime after those. One other factor that we’d consider for this feature request is ongoing maintenance — keeping our code up to date as Apple changes their requirements for codesigning and notarization. For now, people creating apps or screen savers could hire the Vuo team or another developer to sign and notarize them. (Keep in mind that this also requires a $99/year Apple Developer membership.)

2 Likes
7

This is great!!! Thanks for the work guys.

8

Thanks for this update! I agree with the order of goals and features and don’t have anything to add. It’s also a good reminder that paid support is available, will keep this in mind.

9

Sounds great!

I would love to see a UDP/TCP/Networking implementation (https://community.vuo.org/t/-/5674) as it would open up for more cross platform/application usage while waiting for proper cross platform support. I understand this might be a bit niche for most though.

Seeing that you do a lot of other work to finance Vuo, it would be interesting to see what it would cost to pay for the different feature requests. What would be cool would be the possibility to give an amount/chipping in towards getting the features implemented. Ideally, if the TCP/UDP one estimated to take a few day cost $1000 to implement, users would be able to give for instance $10 now and then until it’s fully financed, or it has gained enough votes along with some financing that it gets viable to get done.

I know this could be a bit daunting as I expect it would be an estimated amount of hours, which could bite you in the behind if the estimation is incorrect. Or it would generate too much overhead from a managing perspective. Your thoughts on such a financing model would be interesting at least.

2 Likes
10

@jstrecker, does the roadmap include sometimes smaller in-between updates with smaller feature requests to keep us excited ?
Sometimes waiting so many months for bigger updates feels so long :(

@martinusmagneson absolutely!
Was going to write the same !

I asked a while back for feature requests to display an estimated funding price.
I could imagine spending some dollars for smaller requests alone, but being able to crowdfund stuff would definitely be cool !
Pay money, and get refunded if the total crowdfunding price isn’t reached within a certain amount of time !

EDIT :
Found that discussion where I asked about the funding prices of feature requests here : Display funding cost of feature requests with Jean Marie’s answer.
Would it be in our hands, us the Vuo users, to create some crowdfundings on some crowdfunding websites (although fine-tuned estimations would be needed maybe, ranging from 300 $ to 1800 $ is a bit too wide for a crowdfunding) ? Or could there be some money pools here on the Vuo Website ?  

1 Like
11

+1 for your marvelous plan, and also for the crowdfunding-like model.

I add a proposal. Obviously most of the actual FR can only be added by Vuo team, as they are structural changes to the framework. But, some of the FR are “just” new nodes, sometimes porting of existing C libraries, and I think that could be implemented even by more skilled users writing them with C, without waiting for a “official” implementation by Vuo team. For example, although I don’t consider myself a skilled C programmer, but neither a newbie, waiting for a future “ML based background subtraction” implementation I’m trying to port this library to a node to achieve a classic way to do it. I’d love to learn better how to deal with errors and issues I meet in this effort. So, I think that in the roadmap could find space the goal to create a better documentation on C node programming, that actually is based on an old video tutorial, some useful but essential reference in the manual and some hints in the forum. Perhaps this would allow Vuo to evolve quickly also thanks to autonomous programmers. This old (not very popular I admit) FR is something goes in this direction.

Just my 2 cents. A great thanks anyway for all your efforts.

michele

2 Likes
12

I love the idea of crowdfunding features, though I understand that the time spent to estimate alone is a task in itself. Would support any efforts around this very happily.

2 Likes
13

Seeing that you do a lot of other work to finance Vuo, it would be interesting to see what it would cost to pay for the different feature requests. What would be cool would be the possibility to give an amount/chipping in towards getting the features implemented.

Direct link to the rough cost estimates that @Bodysoulspirit referred to: How can I help decide which features will be in future versions of Vuo? | Vuo

Way back when, the Vuo team used to put a more precise estimate on each feature request. We no longer do that because it takes too much time away from actual development, and the estimates change over time due to changes in Vuo or other technology.

However, if there’s a particular feature that a group of community members are willing to fund, maybe we could come up with a more precise estimate and run a Kickstarter or Indiegogo campaign to collect funds. This could potentially help with our team’s goal of funding more of Vuo through Vuo-related development rather than unrelated work for hire, as well as getting features developed faster.

From our team’s perspective, our biggest question is how to make sure we’re making estimates and running campaigns only for features that are likely to be funded, so that the time we spend on this is fruitful and doesn’t slow down overall development. Any ideas?

does the roadmap include sometimes smaller in-between updates with smaller feature requests to keep us excited ?

We may do bug-fix releases (like the one we just released, Vuo 2.3.2), but weren’t planning on any additional feature releases beyond the ones listed. For each feature release, I only listed the major features. Vuo 2.4.0, 2.5.0, etc. will include bug fixes and small features as well. Sometimes we’re able to add a feature if it’s closely related to something else we’re working on, or if it ends up being much easier than expected.

But, some of the FR are “just” new nodes, sometimes porting of existing C libraries, and I think that could be implemented even by more skilled users writing them with C, without waiting for a “official” implementation by Vuo team… So, I think that in the roadmap could find space the goal to create a better documentation on C node programming

Our team is eager to support other developers making Vuo nodes, whether they’re doing it on their own time or professionally.

I’ll respond on the ML-based background removal feature request with some information specific to that library, and can try to help you figure out any errors you get stuck on.

I’ll respond on the advanced tutorial on plugin developing feature request with some general information about libraries.

5 Likes
14

From our team’s perspective, our biggest question is how to make sure we’re making estimates and running campaigns only for features that are likely to be funded, so that the time we spend on this is fruitful and doesn’t slow down overall development. Any ideas?

True ! Good question.
Maybe sometimes the team can select some feature requests and create campaigns.
Or users can maybe also create some ?

Or maybe, was thinking of some kind of wallet here on the Vuo website, that users can spend on feature requests. A little bit like voting points.
So for example I can upload some money, say 200 $, and pledge it towards a feature request.
From there on, this is displayed on the feature request, as well as the amount of money that is still needed for this request to be implemented.
That money stays available and is not used until the request is marked as “chosen to be implemented”, and I can choose to spend that money elsewhere on other requests if I see not enough people want to participate with me ?

15

This whole crowd funding thing on the face of it sounds good but it seems like it could just get a bit complicated. If there were more Vuo users overall crowdfunding would be unnecessary. Do you pay to advertise Vuo anywhere? Maybe we could crowdfund a marketing campaign and see if it helps?

I get the feeling a lot of the founders are no longer here because it’s just taking too long to mature into a fully featured product, a whole new batch of Pro users would be a boon. Having watched the release of Resolume Wire over the last few weeks the interest in node based tools is out there if the marketing is good.

2 Likes
16

Joe, I’m a founder and I’m still here. :)

But I agree, growing the community is needed. Vuo is already very capable and can do some amazing things. I’m sure the developer team would love to spend more time on Vuo and maybe even have some options to hire additional coding talent. A well executed marketing campaign aimed at expanding the community could be what’s needed to help accelerate Vuo’s development. I think it’s a good idea.  

2 Likes
17

A marketing campaign is a great idea! I’ve introduced a couple of people to Vuo in the past months and they love it, it’s definitely at the point where it’s pretty complete and robust enough now to do more than that I was able to do with Quartz Composer personally.

1 Like
18

I’d love to hear more about the cross-platform plan. Is there a desire for .vuo files to load cross-platform?

19

Agree with Joe’s comments about Adobe plugins vs FCP/Motion. Much as i’d love to buy and learn FCP/Motion, I’m sticking with Adobe for the low level use I have and if I went elsewhere more likely to be BlackMagic Design DaVinci Resolve. Davinci Reslove itself has a nodal system on the Fusion page, although experienced users prefer to use Fusion itself and port the result via a VFX link which is more performant and less prone to frustrations. (A bit like dynamic linking to AF from Premier Pro I guess)

Developing FX plugins on the other hand, I’m much more interest in the Adobe market followed by the OpenFX market (Resolve/Fusion), and with their fairly recent userland Motion Graphics templating system (can be authored in After Effects or Premier Pro) it would be possible to generate a sophisticated front end for a Vuo FX composition (given the poverty of UI chrome options for Vuo apps/filters).  

20

Great to see this roadmap, even if it feels like a lifetime ago these ideas first came into existence. I’m super happy for M1 and Metal updates, pretty essential to stay in the race. I second particle systems taking a back seat to shadow mapping.