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.
I don't have a very good answer for your question about timeframe for fixing the graphics-related crashes, sorry. For the past several months, we've been working on features/fixes that were originally planned for Vuo 1.3 and releasing the smaller or more self-contained ones in the 1.2.x versions. Since the graphics changes are complicated, they're still planned for Vuo 1.3. I expect that will be some months away.
It seems with the implementation you discussed, existing subcompositions are going to behave quite differently... I think there needs to be some way for us Vuo composers to tell, at a glance, which Vuo version(s) a subcomposition will work with.
@Philip, we could add a “created in Vuo version” metadata that appears in the Node Library documentation area. We haven’t been storing that information in compositions so far, but if we added it in Vuo 1.3 then at least you could tell if a subcomposition was created before or after.
When making significant changes to the built-in nodes, we've been leaving the old node in Vuo but marked deprecated (it doesn't show up in the Node Library) and adding a new version of the node. This avoids breaking old compositions.
With events going only to a single published port at a time, what happens to the data? ... It seems to me that the data should be available for the subcomposition to use, even if there hasn't been an event sent into those ports.
Agreed. The plan is that, when you edit a port's value on a subcomposition node, the new value propagates immediately to the connected input ports inside the subcomposition. In your example, if you edited the port Value2, the new value would immediately show up in the Value port of the Value 2 node (but it wouldn't cause the Value 2 node to execute).
If a subcomposer wants events to be sent along routes in addition to where the received event arrived, it could get a bit unwieldy to deal with... Is it possible that there could be some mechanism built into the editor that would allow for an easier (and less messy) way to make this happen?
Excellent point. Maybe there could be a special published input port (event-only) that transmits an event if any published input port transmits an event.