Oh, I was thinking the hypothetical Change Item Ranges in List would have a Ranges port that is a list of ranges, like Get Item Ranges from List. Having a singular Range port would not be as complex. Still, you'd have to do a little math to make sure you're feeding in the desired number of replacement items. (The range 2-5 would take 4 items, not 5.)
You can generate a list of positions in a range currently using Make Points along Line. It would be cool if we also had a node to more straightforwardly generate integer sequences.
Thanks for sharing the non-working .ply. This console message gave a clue as to why textures aren't applying correctly:
4/18/17 10:43:54.676 AM VuoComposition-HQrO63: VuoSceneObjectGet.c:240 convertAINodesToVuoSceneObjectsRecursively() Warning: Mesh '' is missing tangents, bitangents, texture coordinates. These channels will be automatically generated, but lighting and 3D object filters may not work correctly.
Actually the .ply file does have texture coordinates (as seen in MeshLab), but for some reason the library that Vuo uses to import meshes (Open Asset Import) seems to be ignoring them — so I've converted your question to a bug report.
When texture coordinates are missing, Vuo tries to generate some, so that shaders will at least partially work. But because this scene's texture map is complicated/piecemeal, the generated texture coordinates aren't close to what the mesh author intended.
I'd be more inclined to do it for selected nodes. Or even more removed from slowing down the UX/UI, only reveal when a modifier key is pressed and only for selected nodes. So not Spacebar as it's already got Pan and hopefully Pan/Zoom one day. Not Shift as it's a selector modifier, Not Option as its standard copy modifier in many drawing apps. Guess that only leaves the Control Key. :-)
The way I read it there is currently one kind of sub composition which is global and you need to edit it without published inputs and outputs being any use while you edit. Meaning we can't live edit without having a parallel test rig composition and cutting and pasting edits from the test rig to the global sub-composition file to be saved for use elsewhere. Erk.
Whereas I want three kinds of sub-compositions.
Global — effects all instances in any Comp Vuo opens if the subcomp is actively loaded in a Global Modules folder
Local — effects only instances within the Open composition, always belongs to a single composition and if copied to a new comp then is a new thing and belongs to that other composition.
Group Nodes | Macros — effects only a single instance and if that instance is copied to elsewhere in any comp it is completely independant of the parent sub-comp and any changes to it or the Group/Macro it was spawned from have no effect on the other.
In addition are two other desirables: (maybe I need to make these as separate FR to make it transparent that they are part of the concept)
(i) Live input and output state for editing sub-compositions, at least for case 3 but preferably for 1, 2 and 3.
The easiest way for Team Vuo to do (i) could possibly be that a second Vuo window gets created with the sub-composition but feeding and sending data from whichever instance that was double clicked to open it (but then as a separate threaded 'application' maybe that's actually pretty hard?)*.
A QC style down/up level mode in the Editor is the obvious way to do it, although would only really solve 3. Group Node | Macros not Global and Local sub comps (1 and 2 in list above). EDIT: As Jaymie noted, there is already a FR for that behavior here: Open sub-composition in same window as composition
(ii) Nicer would be window in window for all types of sub-compositions in same Editor as I've illustrated above, but that could be a fair bit of pixel work for Team Vuo to wranggle?
.* This got me to thinking, maybe being able «new feature alert!» to send any VUO native value (event, bool, image, list, etc) to another Vuo composition would be a way to help make this subcomp testing thing more readily possible? Like OSC and Syphon rolled into one. Could be trialed behind the curtain for sub-compsotions and if it's stable then exposed as a usable feature. Not to sure how much use it would be to users though given that Syphon and OSC are already available.