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 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.
Estoy practicando para ser competente en español. Si publicas en el foro en español, trataré de responder en la misma manera.
Looks like the problem (and solution) are actually on the Quartz Composer side.
In QC, there are two ways to look up an item in a structure: by index or by key. When the qcOSC patch turns the received OSC data into a QC structure, it correctly sets the keys (the numbers in quotation marks) but shuffles the order of the indices (the numbers you're looking at). So the tooltip looks wrong, but if you use Structure Key Member instead of Structure Index Member to look up the items, you should get the correct result.
A simple example are all the maths nodes, there are so many of them, that are all unnecessary given the calculate node.
That's a good point, and I'm trying (unsuccessfully at the moment) to remember if there was as specific motivation for doing it that way or if it was mainly because theCalculate node was not added until after the single-function math nodes. The Calculate node might be a tiny bit slower since it has to parse the mathematical expression, but I don't think anyone has measured to see if the difference is ever perceptible.
There are lots of other examples of nodes that I feel could be combined or generalised more resulting in a simpler search and interface.
Discussions like this seem to only allow 4 file uploads. More I could share but can't. :-)
That's odd, there's no limit set. If you edit the post, can you add more files? If not, maybe we'd be able to figure out the problem if you could provide a screenshot, and in the meantime you'd be welcome to put more files in comments.
The text layer behaving differently after you converted the composition to the image generator protocol could be related to event flow through published ports.
The text should be equally crispy as long as you're rendering at the same resolution, regardless of the rendering destination. If the text doesn't look right in the exported movie, I'd suggest checking your export settings, including resolution, movie quality, and motion blur.
If you're still stuck on either of these problems, I'd suggest posting question(s) or discussion(s) and on each attaching a simple composition that demonstrates the problem.