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.
@Bodysoulspirit, I meant that the tentative plan for this feature request was to provide just 1 way of disabling a node (the "black hole" behavior). So a node could either be enabled or disabled.
The issue of "what state would those nodes be in when I restart the application" is that when you restart (meaning hit the Stop button and the Run button) the composition starts fresh. It doesn't carry over data from the previous run. (The ability to save state and resume later is covered by FR A UI for storing and loading the state of running compositions.) If nodes had the ability to continue outputting their current data when disabled, then things would work OK if you ran the composition and disabled the node, but the next time you ran the composition the node wouldn't have any meaningful data to output.
I guess it would be possible, though probably beyond the scope of this feature request, for certain nodes, when disabled, to optionally pass their input data through to the output without processing it. For select groups of nodes (image filters like Blur Image and Ripple Image, for example) the expected behavior seems pretty obvious (don't filter the image). For a lot of other nodes, it's either not so obvious (like Blend Image, as pointed out above) or, even for many 1-input/1-output nodes (such as Convert Text to Image), not feasible.
right now if someone were to accidentally enter a string with 57 characters (when limit set to 50) and no space it will not be trimmed and so expand beyond the width I'm trying to restrict the content to
I would maybe run the text through a preliminary Process List loop to chop up the words, before sending it through the Build List loop. The attached composition makes some progress in that direction. It only breaks up a very long word correctly if the word is the first in its line, but maybe that gives you a starting point.
whenever I try to use a "share value" as an input to the "Is Greater than" that controls the character split it cuts off some of the text, even if I don't do anything else, is there something about the flow of execution in this I need to manage?
I'm not sure what you mean. Could you post the composition? — and please post it on a new question / discussion, since sticking to one topic per page makes it easier to for other people to find answers if they have similar questions in the future.