Is VuoList_VuoShader gone in recent Vuo versions ?

[Bodysoulspirit]

Hello,
Question, is VuoList_VuoShader gone in recent Vuo versions ? I had a node to apply different shaders to different objects but no longer usable.
Searching for VuoList_VuoShader in recent API retrieves no matches (starting from Vuo 2.4.3).

More of a general question, is there documentation somewhere about the API changes from version to version ? Or is it only documented in version updates info like here : Vuo 2.4.3 ?

Thanks

[jstrecker (Jaymie)]

VuoList_* classes are now (as of Vuo 2.4.3) automatically generated as needed when Vuo builds a composition, rather than existing as files within the Vuo source code.

You should still be able to use VuoList_VuoShader in nodes. Could you let us know what error or problem you’re running into with your node, and we can try to help?

In release notes like the one you linked to, we try to cover any significant API changes in the SDK section. If there is a similar node to yours in the open-source code, you could also look at how that has changed between versions.

[Bodysoulspirit]

Thank you for your answer Jaymie

Love the idea of “Vuo 2.4.3 contains some API changes to lay the groundwork for supporting iteration”

When looking at the sample open source nodes, specific Vuo list types are not used so frequently because so many nodes allow generic / several types (at least in the vuo.list nodes folder).

The node is joined. It is pretty basic because it doesn’t cap or handle an input list being longer than the other list

I got the following errors :

Error compiling module /Library/Application Support/Vuo/Modules/bss.shader.applyShaders.c:
/Library/Application Support/Vuo/Modules/bss.shader.applyShaders.c:13:120: error: unknown type name 'VuoList_VuoShader'
/Library/Application Support/Vuo/Modules/bss.shader.applyShaders.c:20:21: error: implicit declaration of function 'VuoListGetCount_VuoShader' is invalid in C99
/Library/Application Support/Vuo/Modules/bss.shader.applyShaders.c:22:29: error: implicit declaration of function 'VuoListGetValue_VuoShader' is invalid in C99

But … reading the sdk changes for Vuo 2.4.3 again after your answer, I did : #include "VuoList_VuoShader.h" and the errors are gone
But from your answer above and from the notes in the SDK changes in 2.4.3, should #include "VuoShader.h" rather have solved the issue ?

But what is confusing me is that when searching the Vuo 2.4.5 api for VuoList_Vuo you get a bunch of alphabetical answers, but VuoList_VuoShader not (see screenshot below).

But on a more general note, how bad is it to still add #include "node.h" ? I mean so the .c node could potentially still work with earlier Vuo versions if it doesn’t for example use any recent sdk change in the code ?

Thanks

bss.shader.applyShaders.c.zip (1.1 KB)

[jstrecker (Jaymie)]

But … reading the sdk changes for Vuo 2.4.3 again after your answer, I did : #include “VuoList_VuoShader.h” and the errors are gone

Yep, that indicates to the Vuo compiler that it needs to generate the VuoList_VuoShader type (if it hasn’t already been generated and cached).

But from your answer above and from the notes in the SDK changes in 2.4.3, should #include “VuoShader.h” rather have solved the issue ?

No, what you did is correct. If you #include "VuoShader.h" it doesn’t fix the problem since that file doesn’t #include "VuoList_VuoShader.h".

how bad is it to still add #include "node.h" ?

In Vuo 2.4.3 and later it’s redundant (but harmless) to #include "node.h".

But what is confusing me is that when searching the Vuo 2.4.5 api for VuoList_Vuo you get a bunch of alphabetical answers, but VuoList_VuoShader not (see screenshot below).

Huh, that’s weird. I’ve made a note that we should handle this better.

[Bodysoulspirit]

Thank you, although the more I read your answer and sdk changes the less I understand

From the changes in Vuo 2.4.3 :

• When implementing a type, you should no longer implement a VuoList type to go with it. The list type is now generated automatically.

but from your comment :

Yep, that indicates to the Vuo compiler that it needs to generate the VuoList_VuoShader type (if it hasn’t already been generated and cached).

I don’t understand if Vuo needs List types anymore or not

VuoList_VuoShader.h is a header file for a list type right ?
Why when someone would be implementing a new type he should not implement a VuoList type anymore, but Vuo itself still have these ?

And from :

No, what you did is correct. If you #include "VuoShader.h" it doesn’t fix the problem since that file doesn’t #include "VuoList_VuoShader.h" .

I thought vuo list types were going to completely disappear and be generated and that’s why VuoShader.h should have been included instead of VuoList_VuoShader.h"

And from your comment :

VuoList_* classes are now (as of Vuo 2.4.3) automatically generated as needed when Vuo builds a composition, rather than existing as files within the Vuo source code.

Or am I confusing classes with types ?

In Vuo 2.4.3 and later it’s redundant (but harmless) to #include "node.h" .

Ok thanks ;)

Huh, that’s weird. I’ve made a note that we should handle this better.

What I don’t understand here is why so many VuoList_* appear upon search in the api, but specifically VuoList_VuoShader* not

See, I’m confused
Cheers

[jstrecker (Jaymie)]

Let’s see if I can explain without making it even more confusing

I’m going to talk about “building Vuo”, “building a module”, and “building a composition”. When I say “building Vuo”, I’m talking about when we on the Vuo development team compile the Vuo source code to create Vuo.app. “Building a module” and “building a composition” are things that you do using Vuo.app or the Vuo SDK.

Before Vuo 2.4.3, all of the VuoList_*.h and VuoList_*.cc files were created during the process of building Vuo. We had a shell script that would locate all of the data types in the Vuo source code and, for each one (e.g. VuoShader), generate a corresponding list type (e.g. VuoList_VuoShader.h and VuoList_VuoShader.cc) by substituting the type name and other info into template files. The resulting list type files would be compiled, and the compiled files packaged within Vuo.app.

The problem with this method of generating list types is it doesn’t scale if you want to support list-of-list types, list-of-list-of-list types, and so on. Or if you eventually want to support other types of collections, such as dictionaries.

So in Vuo 2.4.3 onward, we handle list types differently. We no longer have the script that generates list types when building Vuo. Instead, the Vuo compiler generates each list type as needed when building a module or composition that refers to it. However (with an exception that I’ll explain in a moment), it no longer generates actual files in the filesystem like VuoList_VuoShader.h and VuoList_VuoShader.cc. Instead, it generates that source code in memory without saving it to a file. Then it uses the source code in the process of compiling the module or composition.

The exception I alluded to is that there is one case where source code files do still get generated. As part of building Vuo, we need to generate the header files for some list types. The Vuo compiler generates those files and they are packaged within the Vuo framework. I suspect that those are the list types that show up in the API documentation, while the rest do not.

[Bodysoulspirit]

Thank you