I have to update an old project in which I used a lot of Enums, mainly to set textures on button or background subpatches. now I opened it and it seems that all of the enums are broken. Its the same VVVV version, and all images are in the correct folders.
The DIR nodes get all nescessary texture strings and send it to create enum, but enums give me NIL… so any idea how to approach this?
a lot of subpatches containing these enums are switched on and off… should this be avoided?
worked well until now
vvvv_45beta34.2_x64 - that’s the version I patched it with and that runs at our client.
sry I can’t provide you with a reproduceable error. if I copy the affected nodes into a new patch it works as expected - In 34.2 and the latest v4.
behaviour is strange within my patch: when the patch opens all subpatches get evaluated. then -after everyhing has loaded- patches are turned off except for the current layout. now I have that enum error. I have to cycle through different layouts until everything is working. so it’s working now but it almost gave me a heart attack :) the patch never behaved in that way.
would you recommend patching with a lot of these enums?
had a strange feeling when I started working with them and no clue, how v4 would internally take care of multiple instances of the same subpatch with enums.
so you’re saying behavior changed between b34.2 and b35.8? what about b35 and b35.5? if you could try those so we can get a better idea of what might have changed this.
also please try to use more words in describing your actual situation, it still sounds rather vague… so you have a patch that has a CreateEnum inside and of this patch you’re running several instances? what would you expect to happen?
my vvvv application is a front end, controlled by the hierachy of the backend’s json file. my subpatches are different layouts, that get evaluated and displayed if the user navigates to the according application level. now within those layouts I have a lot of elements with recurring functionality. Animated buttons, for example, that can control the user position within the json.
To save time I patched them to be able to set thier properties like textures or jump points from the outside via enum dropdown menus. Now I have 15 layouts, each of them with multiple subpatches (buttons, background etc…) whose properties are set by enums.
I open my patch (with the v4 I patched it with). When started all layouts get evaluated, after everthing has loaded all layouts stop evaluating - except for the layout of the current level. Now I get the enum NIL error. All buttons and backgrounds in the current layout are not working. I manually switch to layout Nr.2 - same. Now Layout nr.3 - Now its working. And now back to 1 and 2 - Now they are working too.
so you’re seeing the problem already with b34.2 (the one you created the patch with)? but first you said the problem only occurs with b35.8? and still what about b35 and b35.2 and b35.5? how do they compare? please run the same with each version so we can understand when exactly the problem starts to occur.
still, regarding your explanations. please understand that so far they don’t help. you cannot use terms like “layout”, “jump points”, “position in json” and assume they help in any way. we need to hear things like names of nodes that you use (e.g. CreateEnum) and the structure/hierarchy of patches/subpatches if you cannot provide a demo (which would still be the best obvioulsy, because otherwise it will always be just guessing). hope that makes sense.
I am experiencing the same issue in the latest RC 11. I have an Enum to select a Midi Device. When the midi device is disconnected before opening the patch, the enumeration goes red (as expected), but when I open the dropdown I see a huge list of options, but not the midi devices.
@seltzdesign same goes for you: please give us a chance to help by providing more info! please run the same with different versions of vvvv and tell us exactly in which version it was still working as expected and which is the first one it fails for you.
what enum is this exactly? one of the built-ins or are you creating it yourself? if so, how? to which node is the iobox we see connected to?
if you cannot provide a demo-patch, can you at least provide the same screenshot of the iobox in a state where it is working as expected so we can see the difference?
@joreg Sorry, for the lack of information. Actually I cannot recreate the bug when I do the same in a fresh patch. It was an Enumeration that was connected to MidiOut(DShow9). I will report back if I come across it again.
I reported this earlier on the matrix channel, enum info is pushed to IOBoxes after a connection is made … this erratic behaviour has been introduced since it’s allowed to connect enum pins to virtually any other enum pin.
Yes indeed, the connect any enum to any enum just makes no sense, really error prone on user side (no more visual cue that those two pins are actually incompatible) and means any enum node now has to handle fact that you can send junk to it… (like render states, texture formats, devices…).
@readme, @vux: this behavior got introduced with the last beta by accident. I wanted to get rid of that behavior for the coming beta, but I got feedback from readme that now some connections are not allowed anymore - connections that were ok with the last beta.
Like in this example:
(text enum for dx9 and dx11 aren’t compatible)
referring to February 13th riot discussion.
maybe I was too fast to give up in this regard, but I took it as an argument for sticking with the behavior that got introduced with the last beta.
On the other hand, this combination of enum2string & string2enum might be just the right way of handling these rather special cases, no? So i would again favor not allowing links to different enums.
In the screenshot above: enums for fonts are different between dx9 and dx11, so technically they should not allow connection .
dx9 = gdi font name
dx11 = directwrite font family
which are different things.
string2enum can easily solve the 0.5% cases where this behaviour is required, while avoiding the other 99.5% that can break things (plus red links should allow to pick issue rather easily for those rare cases that happened in between)
@schlonzo: it sounds like your case is very complex. is there a way for simplification?
have “CreateEnum” nodes in patches that get evaluated. And if this not possible: what is the desired behavior here? Currently i would assume a disabled patch would lead to not evaluate the CreateEnum, which sounds like the correct behavior?
have as few “CreateEnum” nodes as possible. Would it make sense to have only one enum for all the layout subptaches? Or do they need to be different?
@joreg
sry right now I don’t have time to create a simple patch that is able to reproduce the error.
@gregsn
correct, but after the initial startup the nil error is present in all evaluated patches. After switching between different layouts it suddenly works.
Hi! I am able reproduce this error with 45beta34.2_x64 and 50beta35.8_x64
Please have a look at the attatched patch. When the timer flop gets true, pause the lfo.
The same behaviour, except the textures get displayed correctly in this example patch.
so here is why your patch is a bit problematic: you create a new enum in each “bg” subpatch instance. So basically for vvvv, there are 4 CreateEnum nodes, some of them get evaluated, others not, and at some other point in your patch you select the enum from a global list by referring to it by name. The big question would be: which one does vvvv pick?
It looks like in this example you didn’t get lucky and it picked an enum that didn’t get evaluated yet (as the surrounding patch didn’t get evaluated).
So this is a pretty special case, but I can imagine 2 solutions:
One Enum: In your case the enums all come with the same entries. They all refer to the same directory. So, in this case, you could create just one enum and refer to that. In the attached zip open root_1Enum to have a look at that approach.
Private Enum: The other solution would be to actually create an enum for each subptach instance, but somehow not refer to the enum by name. In the example, the enum io box now is connected directly to the CreateEnum node to make sure that it’s about this enum type instance (and not another one that goes by the same name). In attached zip open root_privateEnum.
THIS IS ONLY WORKING WITH NEWEST RELEASE CANDIDATE:
