Lists within lists

I'm wondering if you can't sort of do this already… maybe I'm wrong but if a list is a bunch of elements you could assume structure to the list were no actually is evident in the list.

say the list had 120 elements. you you define each element in the top level list as having 120 elements. that would make each element have 10 of it's own elements. (Stay with me here…)

The first, say, three items of each top level element could be (a, b ,c) followed by elements 4-10 null if not required (d, e, f, g, h, i, j). Now (a,b,c) could describe the indexes for a 3 dimensional Array, while (d, e, f, g, h, i ,j) could be the data elements.

I think the only change that would need to be made to Vuo and list handling to do this would be to allow different datatypes in lists. I don't know if that is allowed, not allowed or not disallowed but also not possible with existing Vuo nodes. I imagine one code write a node to put various datatypes into the elements if a new class of datatype was created to handle it. Almost all current nodes would not be able to receive such a deep list — only a couple would get modified to accept such complex data.

We would need a new Make Deep Listnode to accept multiple single element lists of various things incoming and building the master list from them and metadata about the nature of the construction from other value ports. It's how I imagined I would create my 'triangle structures' referred to on other Q&As i posted with 3x 3D points for each vertexes along with a colour value for each vertex. Then write a node to fiddle with some of the positioning using transforms etc either before initial master list is made or by modifying it (so either before Build a List or using Process a List and clumping 6 or more elements as blocks of data when I process it, each block describing a vertex and its colour) Then parse in a final node that converts the data to scene objects for rendering.

Lists already have a datatype other than 'list' associated with them obviously since we can have a list of integers as well as a list of 4D points and the Editor knows the difference. This in a sense is List metadata. Maybe we just need a bit more List metadata to describe more complex set ups.

Team Vuo could create two new datatypes, one of deep list or matrix (but it's a multi-typed matrix not the typical kind where all elements are the same type) and another datatype say multi-list for the deep list elements of, say, 10 items where the first 3 or 4 are positive integers that represent the array indexes (a, b, c) allowing say a 3 deep lists of lists of lists, and the following items in this object could also be predetermined so Vuo always expects the same basic datatype at each element, so d is real; e is text; f is 2D point; g is 3D point (which colours can be converted into); h is 4D Point (which CMYK colours can be in); i is image; j is layer elements… and so on. Or maybe just allow them to be anything and the user must set up the code to process them carefully.

Normal list handling nodes wouldn't know how to handle these Deep Lists but we could write our own nodes to peak and poke at them and perhaps Vuo could provide basic Make a Deep List and Get Elements from Deep List and Choose element from Deep List and Sort Elements by Index Orders from Deep List or Extract Data from Deep List nodes both of which would output a conventional list from a subset of the full data contained in the element. Plus a Change an Element in Deep List using Indexesfor poking at a bit of data in a single Multi-list element in the Deep List.

Philip you mentioned that Jaymie demoed a way of constructing a list using the Share List node somewhere else (forget where). Wondering if either of you have a link handy, if not no probs I expect I'll figure out how at some point.

Hi have no credit anymore to vote on this... but +1 by me! Lists of lists, or in other words, lost treated as every other kind of data type, is a must-have feature for me.

Yep, we (Vuo team) are still strongly thinking of adding lists of lists in Vuo 2.5.0, more so now with the recent votes. The plan for next releases is probable but not set in stone. We'll be marking feature requests as "chosen" when we can definitely commit to them being in the next release.