+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.
To support what's reported in the first point above, this FQ could be useful not only to allow to drag data-only cable, but also to visually highlight the already existing situations where event don't pair with data changement. It's exactly what happens changing constant published data in user defined subcomposition; documentation tells about that:
The data travels from the published input port to any input ports that are directly connected to it by a cable. This is a rare case in which data can travel without an event. The data reaches the input ports on nodes but does not cause the nodes to execute.
I suspected a bug when my subcomposition behave differently if i changed this:
They visually look similar, but they aren't, as in the first example new values dont' exit the "share value" node. I was fooled by the "data and event" cable running from Value published port: because it is in realty a "data only" cable.
I think that a way to visually show it, that automatically is applied in such a case, would give a correct feedback of the behaviour.
I just discovered "frame" port type, "make video frame" node and all the others that makes my job absolutely useless as it's already implemented in Vuo.
But I'd like anyway to understand my mistake, to be able to deal with that in the future.