However, without the time to dive in to the sub comps, is it possible there is something with the "size + position" subcomp, where if used after a "position only" sub com it works, but if used first without the "position only" subcomp beforehand (connecting a cable to a "position only" subcomp, launch, re-connect the cable to the "position + size" subcomp, relaunch), it sets a window size of 0x0, aka you get no window ?
There are two included subcompositions. One saves the window position, while the other saves the window position and window size. My original composition for capturing window position and size didn't correctly check if the file existed first, but this revised composition does.
Run the composition and change the window position or size. When the composition is started again, the window will open at the same position, with the same dimensions.
I am programing VUO FFGL plugins for an audiovisual project. We have multiple decks on Resolume Arena 7 that contains video files and Vuo FFGL plugins.
And all these media files are triggered by an I-Pad using MIDI protocol. There are 2 problems that I would like to ask about;
Thanks Magneson. I wish this node suggestion came up when I typed in "layer dimensions", "image dimensions", "Text Dimensions", "Text Size", and a dozen other things into the Node Library (which actually is usually pretty good at matching needs, even with QC patch names with a similar function).
This has to get more tags in the Node Library, I will FR It,
I think the main issue I have in self-tuition with Vuo (ironic given the aspiration that it were to a be code tuition tool in eduction) is that there's a lot more types than in QC and other node programming environments. It's very hard to see beneath the hood sometimes, where as QC was pretty literal in what it passed around, mostly just primitive types and structures. It's good that Vuo has more sophisticate type data being passed around, it can be more powerful, and I envisaged that going a lot further in Vuo Alpha 0.1 days but I think there needs to be some kind of inspection tool that lifts the hood on what is being passed around. Also wires should be colour or dot/dash coded to not special instances of datatypes. Dunno but it's a buffer to learn this for me. I tend to think in first principles and getting the maths sorted first and seems like Vuo has all these tricks that offer less control but more shortcuts, if you know them and they fit what you are looking to do.
I don't have any issues working in [-1,1] space for X, Y and Z dimensions at all. I was flicking between pixels and width units in QC all the time for years (annoying but very necessary!) and used to do quite a bit of 3D modelling (Architecture training too).
My problems are discovering the useful Vuo patterns to do things. It's not like raw power of semantic code that written programming languages bring (and copious code snippets to learn from) and not as effortless as QC nodal bottom up wiring. You basically can't do anything bottom up in Vuo the way you can in QC in my opinion. Arguably with the Vuo methods comes power, but it's frustrating for self-tuition, basically impossible without a full time effort for weeks/months. Whereas QC was possible to get instant results at whatever level you started from. Many of us who backed the Vuo beta came to QC with little to no programming background beyond school level exposure to coding..