- Prefers to be called
- Uses pronoun
- Perth Australia
- 7 years 7 months ago
- Last seen
- 6 days 4 hours ago
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..
Thanks, Martinus. I'm not sure that's what I was after! Need to reflect on how I can apply that. I'm gong to do it in Adobe AE or QC b/c I don't have a week to get this done! If I can then convert to VUO after the deadline, it will help me learn VUO. As you can see from my other post I find Vuo very frustrating just to learn by doing, trying stuff, reading the manual and node library, unlike QC which seems to function in a way that takes little functions and allows one to keep growing on them bit by bit.
I know Vuo has it's advantages over QC (not least being supported!) but the learning curve is not especially pleasant (for me) whereas QC was mostly fun for me (except for learning JS inside such a hard to debug environment to do state machine stuff).
also there doesn't seem to be an equivalent of the QC Integrator patch… do I have to do math to do that? It's important to have a user input to control the speed for the displacement of the front of the line drawing, so that different length lines still have same appearance of animation. Also the speed value can be ramped up and down to give the animation more bounce.