From @keithlang his request below, be able to also export sub compositions as .vuonode files people can double-click to install.
Regular sub compositions should still be available, they have their upsides too.
If they could be protected against opening (as an option ?), that could sound as a way to Protect shared compositions and nodes [Save composition as closed composition] ?
PS : this started as a request to double-click regular .vuonodes to install them, until I realised that is already possible.
As a trial, I took your ‘Are Equal with Doors’ patch and change the extension to .vuonode. This changed the icon of the file, and double-click opened in Vuo with a ‘Your node has been installed!’
But alas it was not, actually.
I also tried the same thing with your .c file.
I’m certain I’m missing something— not sure how a user is meant to create and share vuonodes that are easily installed? I’m hoping for the ability to Save As .vuonode, or perhaps just a hack to change the file extension.
I will continue to read the (otherwise excellent) documentation.
@keithlang your comment made me try it with a real compiled .vuonode, for example from Martinus : Node Set: MM.ListTools and IT DOES work. It moved itself to the modules folder and showed up in the node gallery.
The reason it did not work with mine is that simply renaming the file doesn’t compile it. It still does displace the node to the modules folder, but then the extension is false regarding the file so Vuo doesn’t recognise it.
This is my fault because I haven’t yet learned how to compile nodes, so far I’ve just created nodes with a text editor, not an IDE.
C files have to be put manually in the right folders, or embedded. That is just an extra extension that also work, beside the default .vuonodes
My wish would be that the definition of .vuonode would ALSO include a node made in Vuo, that has inputs and outputs and is Exported to a vuonode. Unless I’m mistaken, please do correct me!
.vuonode is a container in addition to being the nodes. I suspect it doesn’t work because it has generic inputs which needs the source along with the compiled node to add in the correct type at runtime. If you select your compiled_source.vuonode and your raw_source.c, zip them and rename the zipped file to product.vuonode it should work.
For more info see: https://api.vuo.org/2.1.2/group___packaging_node_sets.html
I like the idea of changing a .vuo file’s extension to have it saved as a sub composition.
Sounds like a feature request maybe ?
Changing the raw .c file to .vuonode won’t work, needs to be compiled I guess (see the link Martinus gave to the API doc).
Ok thanks, yeah, but I don’t have any compiled_source.vuonode, only a raw .c created in a text editor.
And no other declared header files, does it mean I have to include all the source files this node is capable of working with as generic inputs ?
And from the documentation, does it mean each time you create a node with generic types you HAVE TO embed the .c file, your code, at an unzip step away ? Mmm sad stuff because one can reverse your node package set by resetting it from .vuonode to .zip (but of course that doesn’t work with the embedded compiled .vuonodes).
@Bodysoulspirit This is a feature request, I think??
To reiterate the request: The ability to turn a submodule into an auto-installing .vuonode file. This might be via Export, for example. The easier this is, the more non-coding Vuo-ers could share stuff.
This is a feature request, I think??
Yes I meant this was another feature request, but since I realised my orignal idea already is available, I changed the title and information to your idea.
Let’s await if the Vuo team thinks it’s possible ;)
Oh, I missed the part about subcomps. Those are a different thing entirely from compiled and semi-compiled nodes. The problem with auto-installing subcomps is that they are stored as a regular .vuo files. This means that a double-click to install would break double-click to open which I imagine is a lot more useful in general. To install a sub-comp to the library is already pretty easy by opening it, and go File → Save to User Library, or just by opening the UL folder and putting it in there.
yes @MartinusMagneson, the talk of C code made this conversation a bit ambiguous to me at times also :-)
note the list of three different potential sub-composition types here.
Yes, pure local subcomps that you don’t move to the library or have to sister along compostions is what I’m waiting for too before using subcomps really.
@MartinusMagneson yes, I guess this feature request which moved to @keithlang his idea is about being able, from Vuo, to export a subcomp as a different extension, for it to install instead of open.
Maybe in a container ?
With the ability to prevent it from being opened at all as an option would be cool, if you wanna distribute them (and make money ?).
We’ve opened this for voting. We would implement adding a File > Export > Node menu item, which could then be opened in the User Library.