I am the Senior AV Broadcast Technology Analyst at Loyalist College where I primarily design, install and maintain campus AV, Digital Signage and Broadcast systems and equipment. I have also do some teaching for Camera, VFX and Audio/Video editing as well; I love my job. My background includes Broadcast Television, Video Production and Technical work. My passions include traditional and digital drawing, fictional creative writing, VFX, and cinematic video projects. I have also recently rekindled my interest in robotics and have tinkered with Arduino and Raspberry Pi and a few programable robots.
I find I most comfortably find myself in the chaotic limbo between the artistically and technically creative, believing one can indeed excel at both. Which is probably why I am loving VUO! :)
Yes the "Chosen to be implemented" Status is great and appreciated information!
I was thinking though that some of those features are much longer term projects and that a short list just to identify which of those items are planned for the next immediate release would be helpful, both for current users and potential users. I understand that sometimes it may not be clear whether a feature will be ready in time for an upcoming release but that the list just shows the features that are pretty much a sure thing. I'm sure everyone still like the occasional surprise slipped into the next releases too. :)
I realize not all of the "Chosen to be Implemented" features have an exact schedule for which release they will arrive in but I was wondering once you know for sure which features are coming in the next release could they be added to a "Coming Soon..." or "Coming in Next Release" section under the Released tab? We're alway happy with surprise features being snuck in too but I often find myself scouring the Feature Request list to see if there is a solution coming solve a problem I'm running into. Then if it's not there I know I need to go vote on something. :)
Maybe I'm misunderstanding the context of the initial feature request but I think there are 2 distinct reasons for using "Sub-Compositions" and each has it's own expectation for how events should flow.
1) To create a node set as a single node that can be added to the node library for repeated use in other compositions (transmit all events that come in through any published port)
2) To clean up and simplify a very busy or complex composition in the editor canvas (transmit only events that come in through that port) or maybe (transmit only events where the data has changed) so the nodes don't change behaviour when grouped.
I think if they were 2 separate features...
1) Save Composition to Node Library (the current feature)
2) Create Node Group (suggested feature)
I just brought the node group idea up in this thread. https://vuo.org/node/642 Would that make things more straight forward?