Dynamically load vl files, interfaces and other stuff


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?

Is there an elegant way to only call Update for the process node actually in use?
To be more precise, how can I call update here, after the GetSlice:

  • is using interfaces the right approach at all?

I’m grateful for any input, thank you!

Ok, I’ve been able to answer the question about Update myself - removed it from the process node and added it to the interface, now I can call it after the GetSlice…


this is called “Assembly Scanning” which in your case would register every class in the project that implement a specific interface or using attributes (in C#) etc.

Unfortunately I have no idea how to do that in VL…

How could we do something similar to this ? : c# - Getting all types that implement an interface - Stack Overflow


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?

Indeed, noticed that too: Forum doesn't send emails

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.

the idea is to compile these docs to DLLs and scan them on startup of the main app.

for example, something like this, but in VL:

using System;
using System.IO;
using System.Reflection;

public interface IPlugin
    void Run();

public class PluginLoader
    public static void LoadPlugins(string pluginDirectory)
        foreach (string file in Directory.GetFiles(pluginDirectory, "*.dll"))
                Assembly assembly = Assembly.LoadFile(file);

                foreach (Type type in assembly.GetTypes())
                    if (typeof(IPlugin).IsAssignableFrom(type))
                        IPlugin plugin = Activator.CreateInstance(type) as IPlugin;
            catch (Exception ex)
                Console.WriteLine($"Error loading plugin: {ex.Message}");

and then call:



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.

1 Like

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.

1 Like

Just remembered @seltzdesign was asking for this a while ago:

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… :)

This is almost my use case, yes. I’ll need this for live visuals and I haven’t decided yet if I can/want to run an exported app though, ie without being able to access the patch…but we’ll see.

Anyway, what I like about the beta workflow I had:

  • somebody else can create “plugins”, in my case the actual visuals, without having to run the full app, but eg a stripped down version dedicated to creating content
  • library management: to have new content available I could just drop files into a folder for this show and remove the ones I wouldn’t need.
  • during a show, I was still able to access the patch of a loaded visual and change it. (I had multiple instances running, so I (almost) never edited the patch which was live…ahh…good old beta :))

I wouldn’t mind invoking some exe after I have changed a loaded “plugin”, if that’s the proposed solution…?

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.