Dynamic Enums have been a thing in VL for some time (albeit exotic), for example here.
For a current project, a similar mechanism was used to handle groupings of items: multiple Items can be grouped, this grouping is saved to disc, and from this listing, a number of enums is generated so all groups can easily be accessed while patching behaviours around them grouped items.
Now this all works swell, but on restart all nodes that contain an enum iobox of said Grouping Enum turn red, almost as if the enums have not been loaded yet, so the vl compiler does not know what to do with an actual mention of such an enum, and consequently colors the containing node red (and ofc all parent nodes, up to the vvvv plugin entry point).
As soon as you actually look at the bottommost nodes with the error, the enum will recover instantly: since the groups are loaded, it will now solidly compile, and the node turns grey.
I tried different things, such as moving the groupfile loading to Create, but nothing helped. So my guess is, that enum selection in vl, as soon as dynamic enums are involved, is a little broken.
Enums that have not yet a valid entry will never recover from fault (at least visually) until the containing patch is actually opened in the editor.
So please improve the auto-healing of faulty enum ioboxes.
In the meantime, is there a way to do a work around, like loading the enums somehow before anything else in the patch is executed?
it sounds like a bug in our error reporting code… will make an issue.
do you have a little patch that can demonstrate this behavior? like loading a list of dynamic enum entries from a text file with a bit of delay and showing that the patches don’t recover from the initial error of unavailable enum entries.
one workaround i found that works well while developing is, right click in the topmost patch and select “Recompile” in the context menu. this will trigger the missing error reporting update until we fix that.
edit: it turned out it didn’t help as much, because it recompiles other vl files as well. so all vl plugins in my project will need to reinitialize, but some can’t (because I tend to de-evaluate modules with vl plugins configuring the project except on OnOpen, because they can be quite costly in terms of performance).
so hitting Recompile during runtime will spawn a crazy amount of Nil in my case, which brings the project to a halt.
just saw that this thread got marked as fixed. could you please elaborate which part was touched, as I think the discussion derailed a little after you proposed the work around, but I am unsure.
should the reported use case now work, even without a manual Recompile?
yes, patches will now update the error when the dynamic enum changes and the selected entries become available, even if the patch is not open. that should solve the issue, can you confirm that?
yes, as far as I can tell. my report patch now shows up without red nodes (they turn grey in the second frame i believe).
there now seems to be compiling going on when updating the groups? at least I can see grey and orange and green bars just below the main quad, and I suspect they indicate something regarding compilation?
also, updating the dynamic enum results in quite dramatic framedrops, as can be expected if it really is causing a recompilation of the patch. not entirely sure why this is, as the solution for that problem you had in the vvvv plugininterface did not seem to require any of that, and seemed to rely on continuous validation of enum ioboxes alone
yes, in vvvv dynamic enums check their state every frame at runtime, but we don’t really want that in VL. the value in the IOBox is either correct or not and we now have a solution that the compiler can know that. this moves the code and validation checks out of the user domain and doesn’t end up in the executable wasting CPU cycles every frame.
whenever you can solve a problem at compile time, it is a big advantage because it happens only once at change and won’t end up in the executable. those little CPU spikes for recompilation will happen all the time while patching, so i think it’s not a big deal really. it’s the normal system behavior.
however, if that really gives such a bad user experience as you put it, we have to come up with another solution, or a second option to move all of that from compile time to run time.
