Directory content to Enum, better Filetexture node

hi guys!

if you want to change your texture file in the FileTexture node, vvvv freezes. I want to avoid that, so I created a module which reads the location of my texture folder from a file, and creates an Enum with the files in it.
The advantage is that now you can select new textures from an Enum pulldown which does not freeze vvvv. The module works fine with one exception: You cannot have more than one piece of it because then you create an Enum twice which kinda destroys/bugs everything. File: bbFileTextureV1

So, I created two modules: One which creates two Enums with the full paths resp. filenames of said directory (bbDir2Enum) and another one which should use these Enums to provide the above outlined functionality (bbFileTextureV2)

Advantage: more instances should be possible because the Enum is created in a separate node.

Disadvantage: Kalles Enum2String, which I use to get the full path back out of the Enum, does only accept IOBox(Enum) as an input, but I find no way to feed the selected path to this IOBox because it does not forward its input to its output!! is this desired behaviour?

Request:
Any way to do this?
any better way i don’t know about? sebl mentioned getpatch/setpatch but i don’t know how to handle those.
any performance optimizations? especially since the directory never changes, so I could maybe somehow send the Dir2Enum to sleep once it created the Enums? Also, the bbFileTextureV2 node almost never changes (at least in vvvv’s frame-by-frame world ;-))

FileTextures.zip (4.1 kB)

Why use Enums? File names are only TextStrings.

VVVV freezes beacause it only does one thing at a time, so if you open a standard file-selection dialog box, the rest off the patch freezes, until you close that dialog.

For live useage, it is recommended to make your own little GUI, and there you can make a file selector that doesn’t freeze vvvv. (because you are not going to use vvvv/window like dialog boxes).

if you got performance issues, and you realy want to stick with you patching screen during a live show (wich is always a bit risky) I got an example somewhere…

edit: found it, I made this as back end for my own GUI.

Slectorr.v4p (13.8 kB)

Never mind my previous post, was not helpful for your problem :(

Okay, I updated the Enum2String, bacuase now we have the great option that every node has a fixed ID, and if not, it at least has an ID pin.

Enum2String2 (Enumerations).v4p (7.4 kB)

thanks for your work. i looked into it, and i think i understand now.
unfortunately, as far as i can see, i think your update broke things. while kalles version detected the id of the iobox which is connected to the enum2string, and reads its input value from the xml data (this is why you can only connect iobox(enum)), your version detects the id of this iobox in the enum2string2 module (say “5”), but then parses the contents of the node nr 5 in the parent patch.

i understand now that the iobox which i connect to kalles enum2string does not need to forward the correct value, it only has to be on its input. so you just have to connect it in my patch.

unfortunately, (as far as i can tell, my understanding is still quite shaky), the values which are assigned are not showing in the xml file of the patch, so they cannot be parsed. in kalles helppatch this works because the “values” field in the xml file of the helppatch actually exists and is filled with data…

in general i would avoid to make use of all “CreateEnum” features.
its behaviour may cause very strange bugs.

i think your “freeze” problem is mostly related in performance needs of vvvv’s GUIupdate. so west’s ssssllllccctttrr is a good approach to your problem.

another really simple approach is attached.
you know: the simpler, the better…

buchi.v4p (9.3 kB)

good old send/receive nodes solve the problem of shipping texture filenames (&pathes) from module to module.

finally we have our librarytextures back! thx buchi!

FileTextures.rar (3.5 kB)

vvvvery nice! i didn’t think of the send node xD…much love, it works now.

I modified this into two nodes/modules which are a bit more general in usage, Dir2Enum and Enum2Filepath. Also, a helppatch for Enum2Filepath. Creating a helppatch for a node which is only allowed to exist once is kinda tricky (i don’t know how), so I don’t have one for Dir2Enum.
For now I think everything runs quite fine but I would like to hear if it also runs smoothly on your machines, and any suggestions/rework you have in mind.

I’m off for a couple days, back next week, that’s why i rushed it a bit…

Dir2Enum, Enum2Filepath.zip (5.4 kB)

  • i had to adjust the receive channel (as always, sorry for that…). can you commit that you only adjusted that once and didn’t
    ** restart vvvv
    ** open the help patch
    ** readjusted it by yourself
    ?

  • just a feeling about the naming: i would like better:
    ** Dir2Enum
    ** Enum2File

or

** CreateGlobalDirEnum (once instances, name can be long)
** ChooseFile (multiple copies everywhere, needs to be short)

i don’t fully understand… i only changed the name of the enum, send_string and receive_string (“bb” in it only will confuse people)…this was not carried over?

@naming: I also thought about Enum2File but concluded that it would be confusing, the node does not put out a file, but a filename/path, Enum2File would imply that it e.g. writes the contents of an enum to a file…

edit: I published my patches so far in my patches. Not as modules, I decided it’s not stable enough…thanks everyone involved for the help!