I’m still struggling to find a clean way to dynamically unload/load parts of a patch during runtime. Are there proven patterns how to do this without blowing up RAM and CPU load too much?
Here’s my situation:
For a course I prepared a set of patches for my students that will be executed on a powerful system with some hardware that is not available to the students. My wish would be to have a system, where only a certain part of the patch can be used to create their own content (on their own) and when in class quickly exchange the content patch with another one from the students. Right now I handle the situation like this:
There is a full patch (with the entire setup, not accessible to the students) and a simulator patch (that can be used by the students to simulate the full patch)
students work in their own content patch and folder (which is a copy of a template folder containing a demopatch), which can be referenced from the full patch.
student patches are all structured the same way, therefore…
… when replacing the reference in the full patch to a different student’s content patch, the new patch is loaded and can be worked with.
sounds great. however: replacing the reference (from the document menu) will load the new patch in place, but the old document will still be loaded (which i can see in the quad-menu/all documents).
after switching several times, those documents need to be closed manually (tedious work) or Gamma needs a restart
multiple documents (contentpatch) remain open, even though only one is needed
My questions:
can one replace a reference and automatically unload the replaced document (which would be my intuition when chosing replace)?
is there a more convenient way to implement such a “plug-in” architecture?
Sidenote:
having an understandable overview over all open documents (and if they are executed or not) is really not a strength of the current gamma editor. really hoping for some improvement on this topic…
Edit: in beta I did similar things with a simple setpatch…
Also very much interested in a solution for this, or a replacement for setPatch. My use case as described in the linked thread is live performance, where I want to load animations, in some cases edit them live, and unload them after I’m done with them…
Additionally I would need to be able to maintain some kind of library, which is easy to manage, ie like in beta, where I’ve used a folder of v4p files which I would load as needed using setPatch…adding new files or removing unnecessary ones could then be done in explorer without starting the main show and navigating to some subpatch, etc. (explained in detail in the linked thread)…
In vvvv gamma you can have in theory thousands of patches open at the same time. Just make sure you load/unload instances of the patch class properly with CreateInstance/Dispose and remove all references when done.
Like a particule system, but with an interface that gets data from the surrounding patch and a common output that you can use in the surrounding patch.
At runtime you can get a list of all classes implementing this interface to manage your library. Have a look at “Reflection” in vvvv and the .NET documentation.
this sounds promising for my usecase, just have to find out how this works :D
If I’ve understood my thread on the topic correctly these classes would all have to be either in the same main vl file or compiled and loaded as dll? There’s also a solution suggested by @Elias to run a vl compiler over my folder of vl files, but that’s nothing I can come up with I suppose…? Also I guess this would not give me live editing of patches, as they would still be loaded as dlls?
@tonfilm this is what I came up with as a basic example:
I have an interface with 1 method, 1 input, time, and 1 output, stride entity. The interface I have declared in a separate vl file and referenced in my patch. I then get all registered types from the AppHost, look for the ones which implement my interface, select one, create an instance and call my method (“Render”). One animation is in this vl file, another one I’m loading from another vl file, which also references the interface:
This works as in it does load my selected animation properly. I’m not sure how I should call dispose though? Is this at all close to what you had in mind?
Be careful, it looks like you create one instance per frame, it needs a cache region that is triggered on index change. You can then enable the “Dispose Cached Outputs” which will dispose the old instance before setting the new one to the output of the cache region. Generally, if you want to dispose something, use the TryDispose node, it will check if the instance is disposable and then dispose it.
Finding the classes can also be cached, of course. Otherwise, looks good!
i was really impressed by the fact, that one could change the instances while they are running. Without saving and even in the “MyThirdAnimation”.
When surrounding the Render Node with a Try region, exceptions are swallowed, so a small nullexceptions doesn’t kill your whole patch. might be handy for live patching.
me too. this is a pretty simple system, but I can see this becoming very powerful (not only) in live scenarios.
I can share the auto-UI part, I have not finished implementing the attributes part since I’ll wait a bit until this feature is released, but you can see from gregsn’s patch in the chat how to add it from IVLPropertyInfo, which I also use to create the UI.
It’s beautifully simple thanks to channels really…
I’ve been kind of lucky to guess the right nodes with all of this, as I was ready to embark on a days long journey into reflection…i could already see the patch monster coming my way :D so use with caution, pretty much all of this is new territory for me - I guess before we take this as a blueprint it’d make sense if @tonfilm/devs had another closer look at this, hehe…
edit: I’m just seeing now that I have a warning on the select node for unused UI elements, not sure yet why, since it’s an if region which isn’t called…but everything seems to work.
edit 2: only the “AFloat” property is actually connected to something in the animation, so play with it to see it working, ie changing the x position of the model…
