- Prefers to be called
- Hareid, Norway
- 3 years 9 months ago
- Last seen
- 2 days 3 hours ago
Referring to the underlying tension, I think it is good to be able to have a discussion like this. But venting itself isn't really constructive - although it can be necessary at times to clear the head. I find it a lot better personally, if it comes to it, to write everything I'm frustrated about in my own foul language in a Word document. Then I take a trip outside, have a coffee, read my words, laugh at it and delete it. The problem with saying f-you to Powerpoint is that Powerpoint doesn't really care. If it cared, it would still have done exactly what I asked from it (albeit maybe a bit sweaty) - not what I really wanted to ask from it, as it is a computer application.
When I've calmed down, I can formulate my challenge in a way that is not offensive and more to the point to someone that has the ability of caring. They might not though, depending on the issue being for 1 in a million (nah), for 1 million (yup - in a year or so), or out of interest (maaaaybe?). If you are at a point where your challenges are not regarded as important either from a business or interest point of view, there are some options. You can ask for help with the challenge, do the adaptation yourself, get someone to do it for you, or look for a different solution.
With my venting-venting done, switching over to your challenge, the main point to understand in Vuo as far as I see it is that Vuo is push in opposition to QCs pull. When that is understood on a more fundamental level, a lot of the other mechanics in Vuo is a lot easier to understand and "get" - including the Build List. Pulling sees everything that is connected to the output and drags all the calculations down to calculate the result. Push on the other hand is a way to operate that kicks the data and events downstream from a starting point, to the end result. Where pull can be quite resource intensive, push gives you the ability to have greater control of what gets calculated when. This comes at the cost of complexity, but is what makes the Fire on... and Hold nodes both frustrating and great at the same time.
Thinking about it as streams and rivers may help to visualize the flow. Start out with three lists, these are your streams. Add a Build list node, and hook up three Get Item From List nodes from the Build Item port to the Which port. Combine or process your original lists, and output the result through the Build List node. This is your river.
This is the smallest example I can think of, but all the essentials are there. The input to the Hold nodes needs an event (Fire on Start), the Hold node needs an event (Build Item), and the Items port need an index (Build Item). This is how Vuo knows to push the data, and where to push it. If there are no event, nothing has pushed the data to the port, and you won't get the desired result. If there is no Index, Vuo won't know what to push (or it will know, but it will probably be the wrong one for what you want).
Shortcuts and what-does-what! This is practice and memory, nothing more. A few tips to make it smooth is cmd-enter to go into the library. The filtering system can be a bit itchy when you're not familiar with all the nodes and what they do, but to look at the available options in a certain set, you can type [nodecreator].[nodetype]. For "vuo.list" it will filter out anything but the stock list nodes for instance, "vuo.math" will list all the stock math nodes, "co.parabox" will list all of Karl's nodes, "stv." will list all of Satoshi's and so on (if you have those installed that is).
You also don't need to complete each word in the search bar to find your nodes. "bu li" for instance will pop right to the Build list. "r s w" will go straight to Render Scene to Window, and "r i w" will give you Render Image to Window. You can also define more letters to be more certain the correct one will pop up. "s v" will go to Share Value, but "sp v" will take you to Spin Off Value. Getting the brain-/muscle-memory right there take time though!
(Oh, and next time you get frustrated with an application not doing what you want, try setting up Powerpoint on a MBP with presenter-view on three screens feeding a BMD switcher. Nothing will make you search faster for the hypothetical g d t u p o s node)
we've gone ahead and chosen it to be included in the next major release.
This makes me happy! :)
FFGL plugins exported from Vuo will only work on macOS, not Windows.
This makes me sad :( (but I understand it/why)
I guess it will be good to play around with the possibilities and efficiency on lower specc'ed systems before it goes on to the big rigs though when that time comes.
Nevertheless, great job as always!
Don't use process list for items you need an index for! The Build List is more suited to those things as the item output port gives an index number.
Look up Daniel Schiffman / the coding train on youtube. It's not too long ago he did a double pendulum thing in processing. Should be achievable with some math and a couple hold nodes.
I played around with the record/play movie nodes yesterday, and it seems like it should be possible to simultaneously record to- and playback from the same file. I wouldn't use this in any sort of production environment (or even demo) at this time, but would it be possible to make a node optimized for that to get around the whole RAM stuff? The idea being that the playback part is always at least one or two frames behind the record, and you can adjust your "playhead" from frame 1 to max frame (specified by either seconds or frame number). This way you should be able to skip through the whole recording, scratch playback and timewarp your live inputs. Would be cool (at least if it's a relatively small adjustment of existing nodes)!
4 seconds (240 frames) should be trivial! I would just try the comp, and if it is a problem gear up, instead of gearing up and waste money if it isn't needed. I just enqueued 500 frames (at 30fps) scaling up to 1080p from 720p without a hitch. Even with some processing thrown on top for good measure.