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

Will the Metal implementation

Scratchpole's picture
Submitted by

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.

I agree with the order of

cwilms-loyalist's picture
Submitted by

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?

Thanks for keeping us

Bodysoulspirit's picture
Submitted by

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 ? ;)

Will the Metal implementation

jstrecker's picture
Submitted by

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

Sounds great!

MartinusMagneson's picture
Submitted by

Sounds great!

I would love to see a UDP/TCP/Networking implementation (https://vuo.org/node/1607) 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.

Magneson absolutely!

Bodysoulspirit's picture
Submitted by

Jaymie, 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 :(

Magneson 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 for your marvelous plan,

cremaschi's picture
Submitted by

+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

Seeing that you do a lot of

jstrecker's picture
Submitted by

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: https://vuo.org/vote#complexity

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.

From our team's perspective,

Bodysoulspirit's picture
Submitted by

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 ?

This whole crowd funding

Scratchpole's picture
Submitted by

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.

Joe, I'm a founder and I'm

cwilms-loyalist's picture
Submitted by

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.

Agree with Joe's comments

useful design's picture
Submitted by

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

Great to see this roadmap,

useful design's picture
Submitted by

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.

just a cool effect in 3D land

useful design's picture
Submitted by

just a cool effect in 3D land that sells the illusion better than a lot of other things. shadow in 2D design which I'm much more experienced with is pretty fundamental to design too, even in this era of "flat" aesthetics, it's still there, just more subtle.

keithlang seeing as vuo files

useful design's picture
Submitted by

keithlang seeing as vuo files are pre-compiled code that is essentially just a node graph I can't see why they wouldn't be cross platform. compiled code would be another story of course.

here's the first file I came across when I searched for ".vuo"

/**

* @file
 * This composition does...
 *
 * @copyright Copyright © 2016 [MartinusMagneson](https://vuo.org/user/3272)
 * @see This is a Vuo Composition source code file.  See http://vuo.org for further information.
 */

digraph G
{
AppendLists3 [type="vuo.list.append.VuoLayer" version="1.0.0" label="Append Lists|<refresh>refresh\l|<list1>list1\l|<list2>list2\l|<combinedList>combinedList\r" pos="15,660" fillcolor="yellow"];
BuildList3 [type="vuo.list.build.VuoLayer" version="1.0.1" label="Build List|<refresh>refresh\l|<fire>fire\l|<builtItem>builtItem\l|<builtList>builtList\r|<buildItem>buildItem\r" pos="-240,660" fillcolor="yellow" _fire="64" _builtList_eventThrottling="enqueue" _buildItem_eventThrottling="enqueue"];
ConvertIntegerToRealNumber [type="vuo.type.integer.real" version="1.0.0" label="Convert Integer to Real Number|<refresh>refresh\l|<integer>integer\l|<real>real\r" pos="-1260,405"];
ConvertIntegerToRealNumber2 [type="vuo.type.integer.real" version="1.0.0" label="Convert Integer to Real Number|<refresh>refresh\l|<integer>integer\l|<real>real\r" pos="-1095,1005"];
ConvertIntegerToRealNumber3 [type="vuo.type.integer.real" version="1.0.0" label="Convert Integer to Real Number|<refresh>refresh\l|<integer>integer\l|<real>real\r" pos="-1275,555"];
ConvertIntegerToRealNumber6 [type="vuo.type.integer.real" version="1.0.0" label="Convert Integer to Real Number|<refresh>refresh\l|<integer>integer\l|<real>real\r" pos="-300,975"];
CountItemsInList10 [type="vuo.list.count.VuoReal" version="1.0.0" label="Count Items in List|<refresh>refresh\l|<list>list\l|<itemCount>itemCount\r" pos="420,480"];
CountItemsInList6 [type="vuo.list.count.VuoReal" version="1.0.0" label="Count Items in List|<refresh>refresh\l|<list>list\l|<itemCount>itemCount\r" pos="180,540"];
CountItemsInList7 [type="vuo.list.count.VuoReal" version="1.0.0" label="Count Items in List|<refresh>refresh\l|<list>list\l|<itemCount>itemCount\r" pos="180,555"];
CountItemsInList8 [type="vuo.list.count.VuoReal" version="1.0.0" label="Count Items in List|<refresh>refresh\l|<list>list\l|<itemCount>itemCount\r" pos="420,600"];
CountItemsInList9 [type="vuo.list.count.VuoReal" version="1.0.0" label="Count Items in List|<refresh>refresh\l|<list>list\l|<itemCount>itemCount\r" pos="420,495"];
Divide [type="vuo.math.divide.VuoReal" version="2.0.0" label="Item width|<refresh>refresh\l|<a>a\l|<b>b\l|<quotient>quotient\r" pos="-1245,690"];
Divide2 [type="vuo.math.divide.VuoReal" version="2.0.0" label="Item height|<refresh>refresh\l|<a>a\l|<b>b\l|<quotient>quotient\r" pos="-1245,765"];
FireOnStart [type="vuo.event.fireOnStart" version="1.0.0" label="Fire on Start|<refresh>refresh\l|<started>started\r" pos="-390,420" _started_eventThrottling="enqueue"];
GetWindowDimensions [type="vuo.window.get.dimensions" version="1.0.0" label="Get Window Dimensions|<refresh>refresh\l|<window>window\l|<width>width\r|<height>height\r|<pixelsWide>pixelsWide\r|<pixelsHigh>pixelsHigh\r|<aspectRatio>aspectRatio\r|<top>top\r|<right>right\r|<bottom>bottom\r|<left>left\r" pos="-1635,45"];
GetX2 [type="vuo.list.get.VuoReal" version="1.0.0" label="Get X|<refresh>refresh\l|<list>list\l|<which>which\l|<item>item\r" pos="-1200,435" fillcolor="tangerine"];
GetY2 [type="vuo.list.get.VuoReal" version="1.0.0" label="Get Y|<refresh>refresh\l|<list>list\l|<which>which\l|<item>item\r" pos="-1200,525" fillcolor="tangerine"];
HoldValue2 [type="vuo.data.hold.VuoReal" version="2.0.0" label="Hold Width|<refresh>refresh\l|<initialValue>initialValue\l|<newValue>newValue\l|<heldValue>heldValue\r" pos="-840,675"];
HoldValue3 [type="vuo.data.hold.VuoReal" version="2.0.0" label="Hold Height|<refresh>refresh\l|<initialValue>initialValue\l|<newValue>newValue\l|<heldValue>heldValue\r" pos="-840,750"];
HoldValue5 [type="vuo.data.hold.VuoColor" version="2.0.0" label="Hold Color|<refresh>refresh\l|<initialValue>initialValue\l|<newValue>newValue\l|<heldValue>heldValue\r" pos="-825,825" fillcolor="lime"];
HoldValue8 [type="vuo.data.hold.VuoPoint2d" version="2.0.0" label="Hold Center|<refresh>refresh\l|<initialValue>initialValue\l|<newValue>newValue\l|<heldValue>heldValue\r" pos="-840,600"];
Make2DPoint2 [type="vuo.point.make.VuoPoint2d" version="2.0.0" label="Make 2D Point|<refresh>refresh\l|<x>x\l|<y>y\l|<point>point\r" pos="-1020,510" fillcolor="tangerine"];
MakeColorLayer [type="vuo.layer.make.color" version="1.1.0" label="Make Color Layer|<refresh>refresh\l|<name>name\l|<color>color\l|<center>center\l|<rotation>rotation\l|<width>width\l|<height>height\l|<layer>layer\r" pos="-570,675" fillcolor="magenta" _rotation="0.0"];
MakeColorLayer2 [type="vuo.layer.make.color" version="1.1.0" label="Make Color Layer|<refresh>refresh\l|<name>name\l|<color>color\l|<center>center\l|<rotation>rotation\l|<width>width\l|<height>height\l|<layer>layer\r" pos="-240,465" _color="{\"r\":1,\"g\":0.999969482421875,\"b\":0.9999847412109375,\"a\":0}" _center="{\"x\":0.0,\"y\":0.0}" _rotation="0.0" _width="2.0" _height="2.0"];
MakeHSLColor2 [type="vuo.color.make.hsl" version="2.0.0" label="Make HSL Color|<refresh>refresh\l|<hue>hue\l|<saturation>saturation\l|<lightness>lightness\l|<opacity>opacity\l|<color>color\r" pos="-1035,870" fillcolor="lime" _saturation="1.0" _lightness="0.5" _opacity="1.0"];
MakeList [type="vuo.list.make.2.VuoWindowProperty" version="2.0.0" label="Make List|<refresh>refresh\l|<1>1\l|<2>2\l|<list>list\r" pos="209,686"];
MakeList22 [type="vuo.list.make.2.VuoInteger" version="2.0.0" label="Make List|<refresh>refresh\l|<1>1\l|<2>2\l|<list>list\r" pos="-601,161" fillcolor="blue"];
MakeList6 [type="vuo.list.make.2.VuoLayer" version="2.0.0" label="Make List|<refresh>refresh\l|<1>1\l|<2>2\l|<list>list\r" pos="-31,671" fillcolor="yellow"];
MakePointsAlongCurve10 [type="vuo.point.make.curve.VuoReal" version="1.0.0" label="Make X axis|<refresh>refresh\l|<startPosition>startPosition\l|<endPosition>endPosition\l|<curve>curve\l|<easing>easing\l|<numberOfPoints>numberOfPoints\l|<points>points\r" pos="-840,105" fillcolor="blue" _curve="\"linear\"" _easing="\"in\""];
MakePointsAlongCurve11 [type="vuo.point.make.curve.VuoReal" version="1.0.0" label="Make Y axis|<refresh>refresh\l|<startPosition>startPosition\l|<endPosition>endPosition\l|<curve>curve\l|<easing>easing\l|<numberOfPoints>numberOfPoints\l|<points>points\r" pos="-840,225" fillcolor="blue" _curve="\"linear\"" _easing="\"in\""];
Multiply7 [type="vuo.math.multiply.VuoInteger" version="2.0.0" label="Multiply|<refresh>refresh\l|<values>values\l|<product>product\r" pos="-555,150" fillcolor="blue"];
RenderLayersToWindow [type="vuo.layer.render.window" version="2.3.0" label="Render Layers to Window|<refresh>refresh\l|<layers>layers\l|<setWindowProperties>setWindowProperties\l|<showedWindow>showedWindow\r|<requestedFrame>requestedFrame\r|<renderedLayers>renderedLayers\r" pos="255,660" _showedWindow_eventThrottling="enqueue" _requestedFrame_eventThrottling="drop"];
Scale2 [type="vuo.math.scale.VuoReal" version="2.0.0" label="Scale|<refresh>refresh\l|<value>value\l|<start>start\l|<end>end\l|<scaledStart>scaledStart\l|<scaledEnd>scaledEnd\l|<scaledValue>scaledValue\r" pos="-1200,870" fillcolor="lime" _start="0" _scaledStart="0." _scaledEnd="1"];
SpreadListItemGroups4 [type="vuo.list.spread.group.VuoReal" version="1.0.0" label="Spread List Item Groups|<refresh>refresh\l|<list>list\l|<copies>copies\l|<itemsPerGroup>itemsPerGroup\l|<outputList>outputList\r" pos="-330,105" fillcolor="blue"];
SpreadListItems4 [type="vuo.list.spread.VuoReal" version="1.0.0" label="Spread List Items|<refresh>refresh\l|<list>list\l|<copies>copies\l|<outputList>outputList\r" pos="-330,225" fillcolor="blue"];
XAmount3 [type="vuo.data.share.VuoInteger" version="1.0.0" label="X-amount|<refresh>refresh\l|<value>value\l|<sameValue>sameValue\r" pos="-1545,225" _value="8"];
YAmount3 [type="vuo.data.share.VuoInteger" version="1.0.0" label="Y-amount|<refresh>refresh\l|<value>value\l|<sameValue>sameValue\r" pos="-1545,285" _value="8"];

AppendLists3:combinedList -> RenderLayersToWindow:layers;
BuildList3:buildItem -> ConvertIntegerToRealNumber6:integer;
BuildList3:buildItem -> GetX2:which;
BuildList3:buildItem -> GetY2:which;
BuildList3:buildItem -> HoldValue2:refresh;
BuildList3:buildItem -> HoldValue3:refresh;
BuildList3:buildItem -> HoldValue5:refresh;
BuildList3:buildItem -> HoldValue8:refresh;
BuildList3:builtList -> AppendLists3:list2;
ConvertIntegerToRealNumber2:real -> Scale2:end;
ConvertIntegerToRealNumber3:real -> Divide2:b;
ConvertIntegerToRealNumber6:real -> Scale2:value;
ConvertIntegerToRealNumber:real -> Divide:b;
CountItemsInList10:itemCount -> SpreadListItemGroups4:copies;
CountItemsInList6:itemCount -> MakeList22:1;
CountItemsInList7:itemCount -> MakeList22:2;
CountItemsInList8:itemCount -> SpreadListItems4:copies;
CountItemsInList9:itemCount -> SpreadListItemGroups4:itemsPerGroup;
Divide2:quotient -> HoldValue3:newValue;
Divide:quotient -> HoldValue2:newValue;
FireOnStart:started -> MakeColorLayer2:refresh;
GetWindowDimensions:bottom -> MakePointsAlongCurve11:startPosition;
GetWindowDimensions:height -> Divide2:a;
GetWindowDimensions:left -> MakePointsAlongCurve10:startPosition;
GetWindowDimensions:right -> MakePointsAlongCurve10:endPosition;
GetWindowDimensions:top -> MakePointsAlongCurve11:endPosition;
GetWindowDimensions:width -> Divide:a;
GetX2:item -> Make2DPoint2:x;
GetY2:item -> Make2DPoint2:y;
HoldValue2:heldValue -> MakeColorLayer:width;
HoldValue3:heldValue -> MakeColorLayer:height;
HoldValue5:heldValue -> MakeColorLayer:color;
HoldValue8:heldValue -> MakeColorLayer:center;
Make2DPoint2:point -> HoldValue8:newValue;
MakeColorLayer2:layer -> MakeList6:1;
MakeColorLayer:layer -> BuildList3:builtItem;
MakeHSLColor2:color -> HoldValue5:newValue;
MakeList22:list -> Multiply7:values;
MakeList6:list -> AppendLists3:list1;
MakeList:list -> RenderLayersToWindow:setWindowProperties;
MakePointsAlongCurve10:points -> CountItemsInList6:list;
MakePointsAlongCurve10:points -> CountItemsInList8:list;
MakePointsAlongCurve10:points -> CountItemsInList9:list;
MakePointsAlongCurve10:points -> SpreadListItemGroups4:list;
MakePointsAlongCurve11:points -> CountItemsInList10:list;
MakePointsAlongCurve11:points -> CountItemsInList7:list;
MakePointsAlongCurve11:points -> SpreadListItems4:list;
Multiply7:product -> ConvertIntegerToRealNumber2:integer;
RenderLayersToWindow:requestedFrame -> BuildList3:fire [event=true];
RenderLayersToWindow:requestedFrame -> XAmount3:refresh;
RenderLayersToWindow:requestedFrame -> YAmount3:refresh;
RenderLayersToWindow:showedWindow -> GetWindowDimensions:window;
Scale2:scaledValue -> MakeHSLColor2:hue;
SpreadListItemGroups4:outputList -> GetX2:list;
SpreadListItems4:outputList -> GetY2:list;
XAmount3:sameValue -> ConvertIntegerToRealNumber:integer;
XAmount3:sameValue -> MakePointsAlongCurve10:numberOfPoints;
YAmount3:sameValue -> ConvertIntegerToRealNumber3:integer;
YAmount3:sameValue -> MakePointsAlongCurve11:numberOfPoints;
}

the FR that probably interest

useful design's picture
Submitted by

the FR that probably interest me the most is for nodes being able to operate on lists, and lists of lists. certainly of all the FRs that aren't about adding new hardware platforms options or adding Metal support.

I'm trying to learn Haskell at the moment which is a pure functional language essentially built from the ground up with lambda functions, with tonnes of syntactic sugar thrown all over it. Once upon a time in alpha there was an idea in Vuo of being able to pass anonymous functions (lambdas) that were themselves constructs of Vuo nodes as inputs for other nodes designed to receive general purpose (typed) functions. I'm keen to see how closely "nodes that accept lists" frees up the compositional expression in Vuo and works us towards lambda/closures.

I haven't used Vuo for a long time but still keep an eye on it. Especially with a view to the video effects, streaming and online meeting software market.

While Haskell is quite limited in terms of free 3D graphics libraries for animation (AFAIAA), Vuo (to me at least) is painful to generate and manipulate complex data streams in real time mathematically, short of putting code into C and compiling a node. And compiling a node is fine for a specific and fixed purpose but not so fine for free wheeling creative flexibility. The creative flexility is what I still love most about QC, it has such a low cognitive barrier to creativity play, much lower than VUO IMHO but it not as powerful in many ways and is depreciated, so no point crying about it.

So I'm seeing big synergies for users on both sides if I can build a bridge between Haskell and Vuo. I'm guessing that's going to be a network node in Vuo and a RESTfull library on the Haskell side. Or maybe my old friend from QC days: Websocket, or OSC, or even ØMQ (ZeroMQ) which Vuo uses under the hood to communicate between the compiled composition in View window and the Vuo Editor (I think). I'll probably come back and ask questions about this from experienced VUO engineers down the track.

One other goal for the next

jstrecker's picture
Submitted by

One other goal for the next few years that I forgot to mention, but was reminded of by a comment on the Get Mesh / Object Vertices feature request, is to integrate the most widely used community nodes into Vuo (with the node authors' permission).

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

We're thinking that it would be community members rather than the Vuo team that would initiate the process. If you're interested in helping to fund a particular feature, then you could see if enough✱ other people feel the same way and, if so, ask the Vuo team to make a more precise estimate and set up the crowdfunding campaign. (✱This gets back to my earlier question: how to make sure to focus our efforts on campaigns that are likely to be funded?)

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.

There would be two main difficulties with hosting it on the Vuo website. One is the technical/financial implementation: collecting money, holding it in a trusted and tax-efficient way, issuing refunds. The other is the social implementation: making the whole process absolutely clear and managing expectations. Indiegogo or Kickstarter would solve the first problem and most of the second problem for us, in exchange for a small cut of the proceeds.

Do you pay to advertise Vuo anywhere? Maybe we could crowdfund a marketing campaign and see if it helps?

A well executed marketing campaign aimed at expanding the community could be what's needed to help accelerate Vuo's development.

Oh boy. We have tried sooooo many things for marketing, including:

  • Paid online advertising
  • Sending announcements about Vuo releases to related blogs / news sites
  • Asking creators of hardware/software that interfaces with Vuo to mention it in their marketing
  • Posting about Vuo regularly on social media, vuo.org, and our mailing list
  • Presenting/exhibiting at conferences
  • Improving the way we explain Vuo's value on vuo.org
  • Making Vuo CE free so more people will try it
  • Offering discounts on Vuo Pro

We've had some modest successes, but nothing that has brought a significant increase in sales.

One thing we have learned is that y'all come up with much more interesting demonstrations of Vuo that our team does. Especially the community spotlights. If you have any ideas for how to get those in front of a wider audience, we'd love to hear them. (Keep in mind that when we contact a blog / news site about Vuo, about 99% of the time we don't get any reply. We've more or less given up on these "cold calls" since the time we put into them doesn't seem to pay off.)

Another thing we've learned is that none of our team really has a knack for marketing (despite our best attempts to learn), and none of the marketing professionals we've talked to have understood Vuo or its target audiences. For an effective advertising campaign, we'd need to identify a specific target audience (e.g. VJs, theater technical directors, makers of museum exhibits) and figure out how to describe the value that Vuo provides to them in one short sentence. We'd need to create a compelling advertisement around that essential core. And we'd need to identify the most relevant websites / magazines / ad networks in which to publish it. If there's someone out there who has the expertise to do this, we'd be open to paying them if we can afford it (and would welcome any donations to that end). Any suggestions on how to find such a person?

TLDR; make it easie and nicer

keithlang's picture
Submitted by

TLDR; make it easie and nicer to package small vuos for sharing.

Thought I'd offer an alternate take here. I'm a pretty heavy Vuo user, with decades in design, code, prototyping including Quartz Composer…so bear with me 🙂

Lets compare Vuo to, say, Swift + Apple frameworks + Xcode.

Apple (as far as I know) is not paying to market Swift/Xcode etc. Instead, the community does their viral thing. In fact, if anyone had to rely on Apple documentation alone, they'd be stuck! Instead, there's vast collections of code snippets and explainers spread around the net.

Can we empower the community more?

  1. Easier sharing For example, if I have a code sample I want feedback on, I can literally copy and paste that into a forum. Other users can easily read it, copy and paste into their own environment, make changes, and post back. In Vuo, that's not possible afaik. Instead, one needs to make a sample project, save that to a file, upload that, also take a screenshot of a neat looking version, upload, and insert into their comment. What if a user could, say, copy some nodes, and paste them into the forum? The forum would share the nodes as a file, and have some machine synthesise some nice screenshot? What if other users could now simply copy and paste these into their own editor, or something.

  2. Easier packaging I've got lots of little modules which I'd like to share, things like de-bounce, annotation, etc. But afaict there's no easy way for me to package these up into something I can share as a black box?

  3. Nicer neatening I'm often embarrassed at how messy my patches are, but it's a LOT of work to clean large sets up. I'd love some cable ties. Cable runs. Monster cables/cables that contain a collection of labelled types.

  4. Sub-compositions In quartz composer, one could package up it up into a sub composition easily. I know that Vuo tried to solve for the edit-once-affect-everwhere by turning it into a new file…but in practice this is too much work, for me. Think about code. It's easy to copy and paste a block of code, with comments, from one place to another. Or, turning a block of code into a function which can be accessed neatly from many places, and updated once.

  5. States Often I'll find I build a nice flow, but there's a state I need to inject into various places. Doing this is really, really messy, whereas in code you can access a variable. Quartz Composer had some third party 'broadcast' functions. I realise these can become Async, but for many tasks (like state) this seems acceptable.

  6. Easy to read They say 'write code that's easy to read' — almost any non-trivial Vuo composition is hieroglyphics. It would be great to make it easier to insert comments, for those comments to stick to modules and perhaps wires/cables. Easier colouring, and slightly nicer text handling in comments?

What do you think?

I think Apple doesn't need to

useful design's picture
Submitted by

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

MartinusMagneson's picture
Submitted by

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.

keithlang

MartinusMagneson's picture
Submitted by

keithlang

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

A really important thing in

useful design's picture
Submitted by

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 Jaymie'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.

Pages