depending on state of a running composition programatically
Alastair (@usefuldesign), since that's not covered by an existing feature request, you should create a new one. On that FR, it would be helpful if you could give specific examples of situations where the Edit Details context menu (exists for published input ports, proposed for the Share Value node) would not suffice. I understand that you're requesting something more dynamic than Edit Details, but I'm not yet understanding what you want to use it for.
If you want the data type's "zero" value, you can do VuoGenericType1_makeFromJson(NULL). This returns 0; (0,0); (0,0,0); or (0,0,0,0) as needed.
For non-zero values, one way to do it is demonstrated in the vuo.math.multiply.list.2 node class's source code. The nodeEvent function calls a (placeholder) function named VuoGenericType1_make1, which is intended to return the "one" value for the appropriate data type. The node class's source code defines a version of the function for each numeric data type — VuoInteger_make1 that returns 1, VuoPoint2d_make1 that returns (1,1), etc. It's long-winded but it works.
Thanks! But what I think I mean is, if I scale a VuoGenericInput1 by a real, will the real convert itself to a 2d/3d/4d point as needed? Since the _scale funtion takes scale values in the same format as what they scale that is?
Vuo GenericType1 value;
VuoReal scale = 0.2;
VuoGenericType1_scale(value, (0.2, 0.2)) //for a 2d point?;
When your generic node class is specialized to a data type, VuoGenericType1_scale is replaced by the function for that data type. For example, when you add a Scale List node to the canvas and choose Set Data Type > Real, the call to VuoGenericType1_scale in that node is replaced with VuoReal_scale (documentation).
It's actually just a text replacement. Everywhere in the node class's source code, the string VuoGenericType1 is replaced with VuoReal.
The available variations of the scale function are: VuoInteger_scale, VuoReal_scale, VuoPoint2d_scale, VuoPoint3d_scale, VuoPoint4d_scale. While there's no entry for VuoGenericType1_scale in the API documentation since it's not an actual function, there are entries for each of these variations.
Im kinda sorta wanting to have a tiny bit more info about the VuoGenericValue1 in the API documentation. It usually works great, and I can look up functions for the real case inputs mostly. Now I've encountered a function that leaves me longing for a bit more clarification though, the VuoGenericType1_scale.
Thanks for the great info Jaymie (@jstrecker)! As always it looks like Apple has pressed fast forward on the EOL of OpenGL. Hopefully it will be positive for the industry, and for Vulkan (which didn't look like it was gaining traction on MacOS). All I know about Vulkan vs OpenGL is that it's very different, very low level, and not always faster (for high resolution outputs no; but for 1080 much faster).
(When looking at game benchmarks etc)
UPDATE: Just been playing with the 'Vulkan Traiangle' tutorials... looks like I am wrong, and Vulkan can swap out shaders on the fly, (at least if I recompile the shaders obviously...) Having a default way to compile shaders (with error feedback) is a nice change to the silence that was GLSL.
For a while now, it has seemed like Apple has been devoting most of their resources to Metal at the expense of OpenGL. Most or all of Vuo's known issues with certain GPUs (https://vuo.org/node/2038), not to mention many issues that we have fixed, are due to bugs in Apple's OpenGL drivers.
So it's not too surprising that Apple has officially deprecated OpenGL. We've been researching and experimenting with alternatives over the past few years.
Whatever changes we may see in macOS graphics support in the future, we can count on there being a great many potential Vuo users who, for whatever reason, are on Windows. We've promised to support Windows eventually and intend to keep that promise.
Ideally we’ll be able to find a viable cross-platform solution — something that would add support for Metal while paving the way for Windows support. MoltenVK is one possibility. We would convert Vuo's OpenGL code to Vulkan, which runs natively on Windows (and Linux and Android). MoltenVK would enable the same Vulkan code to run on macOS (and iOS). Of course, we'll have to do more testing of MoltenVK or any other graphics library to make sure it's a good fit for Vuo.
If any of you have developed with Metal, Vulkan, MoltenVK, or other cross-platform open-source C/C++ graphics APIs, we'd like to hear your thoughts. Any pitfalls we should watch out for? Any slick features we could take advantage of?
Once we've done some more research and testing, we'll let you know our tentative plan.