interleaving lists

I can't figure out how to do this. I'm not attaching anything because everything I have is completely wrong. The idea is somewhat simple:
list A and list B output = A[1], B[1], A[2], B[2], A[3], B[3], ...
There are a couple of reasons to want these lists interleaved. Firstly, the stacking of graphics is not something you can fake. If you interleave your lists, the stacking naturally alternates.

Maybe there is something I'm missing but this seems rather complicated. Any help would be greatly appreciated.

Gabriel,

The problem you are encountering has to do with the difference between reading things as values (one at a time), vs. reading them in as a list (all at once). This is something you can control if you make your own subnetwork.

The combine node reads things in as lists. So if you combine your list A and list B, it first takes ALL of list A, then appends ALL of list B - which is not what you want. You want to take items from each list one at a time.

You can do this by making your own very simple subnetwork. Subnetworks let you control whether each port reads things in one a time (value) or all at once (list).

So to do an interleave, all you have to do is make a subnetwork with two inputs (string nodes or null nodes if you are interleaving shapes) hooked to a combine node. I made such a subnetwork for you - see attached.

My subnetwork, which I called interleave, has two ports, list 1 and list 2. Unlike the combine node, they are both set to take input one item at a time (value). You can change this setting using the metadata dialog. If you peer inside my interleave node, you will see that I simply hook those two ports to a combine node.

But as you can see, this interleave node now behaves quite differently from an ordinary combine node. Interleave does what you want: it interleaves the two lists by combining them one item at a time.

I also included a copy of my mix node from the Cartan Node Library. Mix is a more general purpose version of interleave. You can use mix to interleave any number of lists from 2 up to 7. And you can feed those lists into any one of its seven ports; first come first serve. So mix works just like combine except it takes things one item at a time instead of all at once.

More about my mix node: https://forum.nodebox.net/t/4467207932/mix-node

Hope that helps. This distinction between inputting things by value or by list took me awhile to fully understand. But it's what gives subnetworks their power. Subnetworks are used not just to hide away code, but to choreograph it by controlling whether information is read in all at once or one item at a time. It's a very powerful idea that takes awhile to master.

Please let me know if that solved your problem.

John

Thank you so much! This absolutely solves the problem I was dealing with. It wasn't so much that I couldn't create something I was trying to do, it was just that I felt like I was limited in what I could do.
I have copied the entire "list" section of the the Cartan Library 3.5 and I will explore what you did and try to get a handle on list vs value processing. I went back to my previous question about going from looping to lists and realized that I was just scratching the surface of the topic. I hope to have some simple networks that can help others understand the scope, and function of subnetworks.
All this being said, I do feel there could be another page on the website and a few projects in the examples to get at this issue. They would have to be dead simple though, the subject is certainly subtle. I wonder if often the examples are trying to prove that you can do interesting things with certain nodes or functions at the risk of covering over the basic functions. I'm sure it's a balance.
There was a time when I thought I would just write a bunch of python nodes to get around my lack of knowledge of the basics. I stuck with it, partially because the code nodes are no get-out-of-jail-free card, and partially because I could see that you didn't seem hindered by weirdness of the visual programming.
Thanks again for your help and the Library. I have started to search through the actual XML to see how you used certain things. I can find things based on the overall structure of the file just by the hierarchy. I want to learn all the nodes, you keep making more! (kidding)

Gabriel,

Glad that helped; thanks for the response.

I agree completely there should be more and better documentation for Nodebox, especially regarding this subtle but critical point. You're also right that it needs to be "dead simple". I admire the writing in your blog; you also have the advantage of coming at this from the vantage point of an experienced artist. You may be in the perfect position to create examples or tutorials to better convey some Nodebox basics.

I am surprised to hear that you actually pore through the raw XML of my library; peering inside nodes using the Nodebox editor would seem to be easier. It is true, though, that you can do global searches inside the XML.

Your comments about my library make me think I should not wait any longer to publish 3.6. I have made many new nodes in the last few months, and improved many more. I am still in the middle of a particularly challenging node, but I think I'd better publish what I've got now so that everyone's on the same page. I will do that soon.

I can't quite understand the value output metadata setting for networks. It seems to concatenate values and lists into a list that can't be cast to a type or teased apart in any way. I'm not sure what the use case for this would be.

Gabriel,

I have frequently talked about the range metadata setting for PORTS on a subnetwork, which can be set to either list or value and is crucially important and useful.

But the corresponding OUTPUT RANGE for a node or network, available under Metadata/Settings, is something you generally don't want to muck with. I'm not even entirely sure why it's exposed in the UI. It is sometimes helpful to see whether the output of a node is set to list or value, but it will almost always break something if you change that setting.

Some NodeBox nodes are designed to output a single value, like the add node. Input 2 + 3 and it will output a single value, 5. If you look at the settings for the add node, its Output Range is set to Value. Changing it to list seems to produce a list of one item which, as far as I can tell, makes no difference whatsoever.

Other NodeBox nodes are designed to output a list, like the combine node. Its Output Range is set to List. If you change that to Value, something WILL happen and it's not good. Instead of producing a normal Nodebox list of individual items, the node will now output a single thing called an arrayList.

If you look at the output of an altered combine node like this (with one or more items being output) in Data view, you will see a single comma-separated list enclosed in square brackets. This is the giveaway that you are seeing an arrayList. I talked about arrayLists in a recent posting:

https://forum.nodebox.net/t/8101233582/identify-node

An arrayList is not a valid Nodebox data type. It's basically an underlying Java data type that, in rare circumstances, leaks through. If you try interacting with an arrayList (by feeding the output of an altered node into another node), strange things will happen. As I said in the above post:

"But even though you can cause them to appear, you should not. They do not provide anything you could not get through other means, and if you attempt to use them you will soon run into trouble. An arrayList presents as a single item, but may unpack its contents if you try to do anything with it. It may claim to be one object but produces multiple outputs when inspected. And the items it outputs may look like normal Nodebox objects, but misbehave downstream. Just say NO to arrayLists!"

That said, I did discover ONE use case where changing this value actually was beneficial.

The contours node in my library is one of my most useful and powerful nodes, even though it's very simple. All it does is turn a path (like the outside and inner hole of the letter a) into a list of its component contours. If you look inside, you'll see that the first thing it does is a lookup of a path's contours property.

The lookup node is normally set to return a single value (its Output Range is set to Value). In this case this returns one of those unusable arrayLists. But if you simply go in and change the Output Range of that lookup node from Value to List, it suddenly outputs a list of individual contours. Those contours are not directly useable in Nodebox, but you can convert them to points and reconnect them to form normal paths.

So this was a weird corner case in which it was possible to change the Output Range of nodeBox node without breaking it, and that change was actually quite useful.

That is, however, just about the ONLY time I have found such a change to be useful.

So the short answer: you're right. The Output Range setting is not generally useful, is not something you need to muck with, and you should feel free to ignore it.