Im using an ord2enum to switch techniques but when I reopen the patch, the contections are made the ord2enum outputs the name but the technique doesnt swith, if I delete the ord2enum and then recreate it, it all works until saving and reopening.
I’ve got 3 techniques, is that a problem?
The problem doesnt seem to be in the ord2enum, the ouput switches correctly, the shader seems to be at fault, the technique will only change when switched directly without the attached node, is there a workaround of any sort, or do I have to recode the shader?
I am having the same problem, I use dozens of shaders in my patch, many of them requiring enums to change the state of the shader, my patch is sweet except for the damn enums blocking things up. I get the following repeating in my tty:
00:01:45 * : [validatevalue: error occured in ](validatevalue: error occured in ): Zugriffsverletzung bei Adresse 0052E6FC in Modul ‘vvvv.exe’. Lesen von Adresse 00000030
I have tried putting a frac in front, with and without IOBOX(enum), I don’t feed any of my enums decimals, so the frac doesn’t really do much. This seems to be a definate bug as sometimes it’s fine, other times it’s not. When I have debug mode on you can see the problems right away! At the moment I can’t seem to load the patch at all without it bugging out on me…
Are you using xfiles for the meshes or grids etc? I had problems with xifles not loading correctly and outputing a null which daisychanged down the the shader knocking that out.
If you hover your mouse above the dot where the wire joins the shader you should get a type (transform etc) popup appearing, if theres a null upstream it doesnt show up, which can help tracking down your problem parts.
Ahh just looked at the jpg, yup thats the error I was getting too!
Heres another thing I did, disconnect the enum, save the shader as a new name save the patch, reload ( you might have to quit and restart vvvv) if your lucky the patch will load without all those errors, then you can try and reconnect the enum, I’ve had it so that you have to recoonnect each time you open the patch (maybe real switch could be used to automate that ?) but currently without the xfile problem mines ok at the moment.
Hope this ramble helps some, good luck!
Ya, well, it seems to be a problem that is only effecting some shaders, not 100% sure if it’s because multiple instances of the same shader are active… I’ve detached ord2enums on all of the shaders that default to what I want (and then just alter the others so that their default is what I want). Seems to have worked… so far
Had to work with a fairly basic patch (by my standards) live this last weekend, the mixeffect.fx shaders kept going to null, it’s so strange, even where there is nothing attached to the enum it will still fault.
On the particular patch I had 8 mixereffects for multiple layers of wipes. Some of the shaders would lose their enums, others wouldn’t. I could drag in an identicle shader, attach all the nodes to the new one, and the new one would work. Save the patch reload, fine, then at some point it would lose it again.
I am begining to think there is a problem with direct x, does anyone know if there is a particular direct x version that doesn’t lose it’s enums?
How many others have encountered this problem and what were your possible contributing factors?
had this problem sometimes, now i use only one technique per shader, so i am sure no other one is selected. dirty … and sanch thinks about to switch back to last beta because he needs to switch techniques with Ord2Enum…
Just to say Im still getting this bug, but in this beta I’ve noticed, that if it has occoured the offending subpatch is coloured orange if you ctl+f9, which goes away once you navigate into the patch, the enum also has the stripe until you mouseover the ins/outs
i have the feeling it has something to do with enumerations in general, not just on shaders. i am using R(node) to switch between textures produced by subpatches. using the mouse everything is fine, when i use my midi controller, the textures wont change unless i place the mouse cursor over the R nodes’ receive string input until the selected string is displayed.
ugly but effective workaround: create an inspector for each node that requires an enum input, attach it to the node (attach to selection button). that way, it seems the input string is constantly updated and ord2enum has an immediate effect. should work with the shader also, catweasel, let us know :)