Currently use QC to make custom layers for Bonix TV - a vision mixing kind of application for OS X with a kind of QC stack of layers, each layer being a composition with published ports and some protocols for data types. Also generate sports graphics and twitter feeds and so on for video score boards at large sporting venues.
Spent a few years learning Quartz Composer as my way back into coding from a decade away doing design related work. Film, graphics, studied Architecture for a few years and got involved in publishing then film. Now moving into front side web development. Hope to get into app dev with Vuo and rapid app prototyping.
Another question for @teamvuo / Jaymie, will Lists of List automatically allow Lists of Lists of Lists, simply because it's a recursive approach to lists, or would that require extra coding? I note that recursion is included in alexmitchellmus's FR, so assuming it's included unless we hear otherwise.
Sorry sinemod I simplified the question, so your response doesn't make sense now.
What I was talking about in original version of the question is that in many programming languages there are ways to make heterogeneous definitions of types, data-types or classes.
In Haskell for example it's trivial to create a new type which may be a combination of more elementary types, say a pair comprising of a string and an integer number value
e.g. ("pineapple", 5)
nothing special is required to make a list of instances of that type
e.g. [ ("pineapple", 5), ("apples", 1), ("oranges", 0), …]
the only way to create a new datatype in Vuo is to do so by making a node or nodes in C (I assume). Would Lists of Lists benefit from some nodes to create heterogeneous datatypes that can be used in lists?
I have a question for @teamvuo/Jaymie, lists in Vuo currently have to be homogenous (AFAIK)? So this will apply to lists of lists too right, all elements in any list of lists will be of the same (predefined elsewhere) datatype?
Most XML files have heterogeneous datatypes in them (often serialised as strings), so will need to be parsed outside of any list of lists to get say, real numbers from the data right?
Thanks for the comments, Jaymie. Would you be able to shed any light on the speculative comments in this thread about nodes dynamically setting input ports? Changing the names, adding additional port, removing ports where the input variable has been removed from the expression or C/GLSL code?
Is that functionality a show-stopper ATM for nodes that would need it, or is it a relatively simple change to the Vuo Editor to do something like that?