Right now the only option I’ve found to extract items from a list is the “Get Item from List” node which currently only allows for single list items to be extracted.
I branched this feature request from “Get Item(s) from List” node needed, and opened it for community voting.
Now that Vuo supports subcompositions, you could add a descriptive name to each list item by publishing each output port in the drawer, and setting the name of each published port.
However @smokris one would need to have a constant number of items in the list for a subcomposition to work correctly for extracting lists (but I do like the idea lots!).
Having a list output draw similar to input draws make sense - and should work well with list-in-list (and make creating compositions much faster, as we will be able to simply “plug-in” list items wherever.)
Obviously more advanced list functions won’t work, (search- get “n” item etc.) but for quick and dirty list access it’s fantastic!
I’m a bit ambivalent regarding the drawers. Noting that the previous feature request mentioned ArtNet/DMX, I’ve been working on a sane way to get fixtures into Vuo. Listifying 22 inputs makes an absolute mess because of the drawers. I think opening for drawers on outputs will make about the same, or even worse clutter. Especially with lists in lists.
As a suggestion instead, I’ve made some “breakout boxes” for lists in my list tools (found here: https://community.vuo.org/t/-/6100) keeping in line with the select in/out nodes of getting 2 or 8 (and 4 as well). It should be about as easy as a drawer, but a bit more maintainable in terms of composition structure. If needed, larger batches can be gotten, but not sure if it is necessary. There are two versions of the three nodes. One will just pull out the following X number of objects, while the other will be based on index.
I think that if you have a full universe open as a drawer, it is probably not the most efficient method. Using an index at least should be a bit cleaner.
1 Like
@MartinusMagneson I see what you mean regarding long drawers vs indexes and lists.
However, I still would love the option for output drawers and no limitations beyond 2 or 8.
Because even if Iteration: Turn most nodes into iterators by allowing single-value ports to accept lists will allow an easier way compared to process lists to process lists, sometimes when I wanna retrieve specific list items, I find myself having to constantly add Get Item From List nodes to retrieve specific items from that list to connect them to specific nodes. Output drawers would avoid that.
To declutter, maybe something like collapsible drawers like mentionned in
Thoughts On Drawers would help ?
Agree with you beyond a certain amount it’s probably insane to use long drawers, but having the option to choose when to stop sounds the best to me ?
1 Like
I get the easy part, I just don’t think it will be that easy ;).
This is a relatively small fixture patch for instance. Totally unusable because of the drawers. I think a build list combined with a single iteration really is a lot more suitable for an application like this (apart from some LTP scenarios). However, if you think about this reversed with a nested list input, I think it can give sort of an idea on how it would be.
If anything, I think a prompt for the index when you connect a list to a single input, or selecting it in the input port window would be better (for this instance of Vuo anyways).
1 Like
I don’t see what you mean in the first part about nested lists.
But the second idea is really cool too ! A prompt that would automatically add a get index x item node ! Maybe even better if prompted on Right Click on the list output port instead ? Will create that feature request !
However, would both worlds be an issue ? I agree that a prompt would make output drawers almost obsolete in regular cases, but maybe some cases / persons would need it ?
Question to the team and the owner of this Feature Request : Maybe output lists should NOT have output drawers, but this feature request should rather be the implementation of a Create List Output Drawer node that could be attached to any output list ?
Maybe also, beside complete drawer collapse/expand or put below node as suggested by Thoughts On Drawers topic, double-clicking a port or port title would collapse/expand the port drawer only ? F.e. expand only the Dimmer list drawer ?
And maybe by default drawers should not be expanded to avoid such situations as above ?
It might be me doing loops in my head, but if you imagine the inputs of the node being the outputs of a nested list (which we’ll hopefully have sometime), it can get messy fast.
Collapsing drawers would be neat! I also like the idea of hidden by default. Then I wouldn’t really care
1 Like