I’m trying to recreate a workflow I had in beta: given a folder of v4 files, all of them subpatches with the same Ins and Outs, I would dynamically load one of them into my main patch using SetPatch. The reason for this has been laziness (I didn’t want to manually create/update a big Cons to join all these subpatches, there’s a lot of them), convenience (new subpatches are simply dropped into that folder, old ones deleted) and performance (even when only evaluating the specific subpatch, the big Cons would be slower than running a single subpatch only).
How can I do something similar in VL?
I have followed @lecloneur’s explanation here to create a bunch of process nodes, which all inherit from the same interface (ie have the same Ins/Outs), as I’ve assumed this would be the right/clean setup if I later wanted to swap these process nodes. However, I’m struggling to continue from here:
can I build this spread of process nodes dynamically on startup, in best case from separate/dedicated vl files in some folder, one file per process node? Or is a (manual) Cons (or similar) the only way to go?
performance: as far as I understand, in lecloneur’s example, the TextureFXs are all executed every frame, since the Update operation is part of the process nodes, which are connected to the FXProcessor, is that correct?
sorry for the late reply, thought I’d get an email, but didn’t, or missed it…anyways, thanks for the info; given that you seem to have a good understanding of vl’s possibilities I assume this is a no, not right now…@devs?
Scanning the loaded assemblies for types implementing specific interfaces should also be doable in VL. We can for sure come up with a little patch showing that if this is still wanted? In your original question you say you want to put each patch in a separate file - if you do that, you’ll still need to reference those files, there’s no load VL doc at runtime feature.
Understood. With the 5.0 release our system can make a dll out of vl files, but we didn’t expose this functionality yet. We are currently only using it to compile packages and load them fast from then on. In your case you’d need some sort of tool you’d need to run on your own over the modified vl file. And when you change the running vvvv it could happen you’d need to create new dlls. Essentially you’re asking for a complete build system. And somewhat I have the feeling this is not what you want once you have it? Any ideas how the workflow should be from your end? Or would a vl compiler exe you invoke on your own be enough?
Well you were asking to load vl files at runtime. And that should probably be the way how it should work. You point to a vl file and get an assembly back - on which you could run the above code / patch that part in vl.
I think one of the intended workflows is to define an interface, export an application and give the executable to someone else. This someone can then extend the fuctionality of the application (without having to have access to the “core source”) by building a dll that makes use of that interface.
So I don’t think the compilation and loading of the dlls needs to constantly happen during development.
Yes, that is the use case. Think of a long-term installation where you want to add certain “scenes” or other content that relies on a new patch.
If it can be part of a compiled exe, that would also be a solution. then you can just place .vl files in the plugin folder, which might also be easier regarding references and versioning. but not in terms of licensing… :)