Another node that grew out of my recent collaboration with Floris.

Match_list takes a list and repeats and/or clips it so that it matches the length of a reference list.

Whenever you have multiple lists coming into a node or subnetwork, Nodebox automatically does list matching to resolve ambiguities when those lists have different lengths. For more about this see http://support.nodebox.net/discussions/general-discussion/15331-tut...

But sometimes you need to override Nodebox's default behavior. You may always want to apply secondary lists to a primary list regardless of the relative lengths of your input lists. This can happen, for example, when the length of the primary list varies depending on other factors upstream. If you always want to apply three colors to a list of shapes, you will want to maintain this even if there are sometimes less than three shapes. An override may also be necessary when the primary list comes in all at once and a secondary list comes in one at a time.

Match_list provides this ability to control list matching. It takes three inputs:

• List. The secondary list you need to control.
• Reference list. The primary list that determines the target length. THIS INPUT IS OPTIONAL.
• Reference length. The target length. THIS NUMBER IS ONLY USED IF NO REFERENCE LIST IS PROVIDED.

The only thing match_list needs to do its job is the length of the reference list. You can supply this either by feeding in that reference list or by providing that length whichever is easier.

The attached demo shows match_list applied to two lists: a list of shapes and a list of colors. See screenshot.

I form ten stack of colored shapes, starting with a stack of one shape on the left and ending with a stack of ten shapes on the right. In this case the list of numbers from 1 to 10, supplied by the range2 node, functions as the reference list. I want the height to vary from 1 to 10 even when there are more available shapes or available colors than there are total shapes in the stack.

I feed match_list1 a list of 4 polygons: a triangle, a square, a pentagon, and a hexagon. If the stack being built is only one shape high, match_list1 will output a single triangle. If the stack is 10 shapes high it will repeat those four shapes until it reaches the required 10 shapes total.

By feeding in a list of reference lengths from 1 to 10, I cause match_list1 to fire 10 times. The first time it outputs 1 shape, the next it outputs 2, etc. The end result is a single list of 55 shapes.

I then do the same thing using match_list2 with a list of 3 colors supplied by my sanzo_colors node. Again, the end result is a single list of 55 colors. Because these two lists are perfectly aligned I can then colorize the shapes to produce the correctly colored shapes I need.

Now all I need to do is disassemble this list of 55 colored shapes back into ten separate stacks. This is the perfect opportunity to use my new subsets node. I feed in "1,2,3,4,5,6,7,8,9,10" as a proportions list to define the 10 subsets and turn shuffling off and "Output as groups" on. This produces the 10 separate groups I need ready to stack.

A very simple subnetwork called stack_north ungroups each group, stacks it, and regroups it. Then all I have to do is stack those 10 groups horizontally. As you can see, the ten stacks are all the correct height, each one uses up to four possible shapes, and those shapes are colored using the same three colors.

If this arrangement bores you, just uncheck the "Don't shuffle" checkbox in the subsets node!

I think in practice, match_list will usually be used inside your subnetworks. If I had done that here I could have achieved the same effect without needing to deconstruct combined lists using the subsets node. But I wanted to keep match_list visible from the root level (and also show another use case for subsets).

Comments always welcome. Enjoy!