As one of Vuo's developers, I work on Vuo's engine (the thing that makes compositions run), work on nodes, and write documentation. You'll see me on the forums answering people's questions about Vuo.
I've been developing apps and frameworks for several years (since I was in college). Pre-Vuo projects include Kineme Quartz Composer plugins, iOS apps for education, an app that analyzes photographs of tomato slices, and software to help people with disabilities use talking keyboards.
I enjoy using Vuo to make live music visuals. My hope for Vuo is that it will grow into a community of people of diverse backgrounds and identities making lots of different artistic, useful, unique, goofy, beautiful, crafty, wonderful compositions.
Vuo is not in any danger of being abandoned. We’re continuing to work on Vuo 1.3 as we promised. And we’re continuing to provide support through our public forums.
We’re in the midst of a lot of big improvements for Vuo 1.3, including the community feature requests marked “Chosen to be implemented” (https://vuo.org/feature-request). A lot of these involve substantial changes to Vuo’s infrastructure, so they take a while, and they’re not things that can be broken down into smaller chunks and spread across multiple releases.
We’re also taking a serious look at how to make Vuo’s funding more sustainable. So far, 12% of Vuo has been funded by the community through sales, and the other 88% has been funded by us (Kosada) through work-for-hire on projects mostly unrelated to Vuo. It would be wonderful if we could increase the amount funded by the community, because then we’d have more time to dedicate to Vuo development. We’re looking at how we can make this happen by adjusting the pricing (hence the poll), improving our marketing, and most of all by far, adding new features that will make Vuo more useful and usable.
I’ve been surprised by how much variance there is in what different people consider the must-have features. It’s an interesting problem, and admittedly sometimes frustrating for all involved, to try to reconcile a lot of different people’s ideas into a coherent and useful piece of software. That’s why I think our community feature requests system is a strength. Everyone gets to see what features are up for consideration and see which ones are scheduled to be implemented next.
You mentioned macros — several of the feature requests we’re working on involve improving usability of subcompositions, which should make them a lot more comfortable for everyone, and more familiar for people who are used to Quartz Composer’s macros.
The reason that we stopped using the roadmap was simply that it had become redundant to the community feature requests page.
I can’t tell you a release date for Vuo 1.3, unfortunately, because we just don’t know yet. But it is coming. One of Kosada’s core values is that we do our best to keep our promises, and part of that is being careful about what we promise. Ultimately I hope this builds trust with the community.
If you or anyone wants to help Vuo 1.3 arrive a little sooner, you can save Team Vuo some time by helping out other people on the forums if you know the answers to their questions, or you can spread the word about Vuo to get more people interested in using it and helping to fund it.
We’re looking ahead to Vuo 1.3 and well beyond. We’re committed to Vuo for the long term, and hope to keep developing and improving it for many years to come.
You're correct that the math expression is parsed once and then cached (in muParser's bytecode form). So really the only overhead after that is interpreting the bytecode, and that's probably not going to make a perceptible difference.
The main usefulness of the one-input, one-output Convert Blah to Blah nodes is as collapsible type-converters. For example, if you drag the output of Append Texts to an input of Calculate, a collapsed Convert Text to Real node is inserted automatically.
However, the type-converter nodes do take up a lot of space in the node library, disproportionate to how often you would actually go searching for one instead of letting it be inserted automatically. Some possible solutions to this problem lie in the area of improving node library organization. Right now there's a flat list sorted basically (with some tweaks) by frequency of usage in example compositions. If you could view the nodes by category, hide nodes, personalize the sorting, etc., that would cut down on the clutter.