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.
The ultimate solution to this would be Iteration: Turn most nodes into iterators by allowing single-value ports to accept lists and Lists within lists. I see how adding 5D, 6D, etc. points could be useful in the meantime, but after discussing with some of the team, we're thinking it would be better not to add these temporary nodes that, for some people, might just clutter their node library, and that would enable us to get to iteration and lists of lists a little bit sooner. If you or anyone else would be interested in a little C coding, it would be pretty straightforward to make custom nodes for as many multi-Ds as you want if you started with the source code for 4D point nodes.
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.