Plugins aside vvvv-folder

i wish v4 could load dlls with multiple plugins even if the file is not placed inside the plugin-folder

xml-style i mean this:

works now:

i wish i’d work:

i agree.
and the same for modules/shader/freeframe/vst.

for all externals like vux already stated somewhere around here.

and a subfolderstructure should be provided.
each external should have it’s own subfolder because some of the externals make use of external files themself. e.g. detectobject and its trainingfiles.

actually this already works for plugins if you edit the .xml code of a patch like you suggest. only vvvvs gui doesn’t yet show you a pulldown to choose from the available classes when you drop a .dll onto a patch.

@kalle: i don’t see how other addons have that same problem?! accessing them via an absolut path has always worked, hasn’t it?

@joreg: for migration issues.

each new beta release the same issue:
going inside vvvv’s mainfolder and picking all the custom files.
and you know: sometimes a new beta is faster released than a file is copied.

i keep a sorted collection of modules/shaders/plugins which is almost complete: means that this collection contains almost EVERY external which was ever published around here and in the previous vvvvorums. beginning with beta1…

i reworked and optimized lots of the shaders/modules of other users to my personal flavour.

furthermore there are my own modules and shaders which is quite a lot. it’s way more than what i have published here; my modules folder is around 100 MB!!!

but while thinking about this i have to admit that an external referenced folder perhaps is suboptimal.

on a new betarelease i usually copy all the externals to the new beta’s folder. this way i can fallback to a well-proven beta anytime.

in vvvv’s history have been changes which didn’t allow a patch to open in a previous beta if this patch had been saved with the current beta once. and you now that some betarelases have been quite buggy…

regarding plugins:
sadly i don’t know much about plugins.
they will stay on my “still to learn” list for a while.

but i know that a plugin can contain more than one node.
those plugins must be in the :PLUGINS: location, otherwise their nodes cannot be accessed at all.

and when you put all released plugins from plugking @vux into this folder it gets QUITE messy and complicates the migration to another beta in an unnecessary way.

some of the plugins by @vux have quite a lot external files. i’d prefer having a subfolder containing every thing necessary e.g. for the Bass things.

then again porting projects to other users is quite difficult because of the absolute type behaviour of vvvv’s external referencing.

if i want to send a project containing e.g. Bass i have to tell the other user to place this file here and that file there.
either he has to download those files somewhere else or i have to pick single files from the mess of my folders. and some of the plugins i use have not been published at all.

maybe this is not your issue but an issue of vux not using subfolders. i don’t know. but IMHO a basic subfolder organization should be provided by the devvvvs to prevent the mess in the beginning.

same for shaders. remember catweasel’s issue with the missing .fxh file few days ago.

click images to display fullsize

my effectsfolder:

you see that the only files in the main folder are the ones released with vvvv.

my pluginsfolder: what a mess.


If you put a plugin in a sulfolder of :PLUGINS:, it wont appear on the list, vvvv doesn’t scan this folder recursively.

I give a +1 to that, for the first build scripts, there wasn’t so many nodes, now it’s very different indeed.

  • If you put a plugin in a sulfolder of :PLUGINS:, it wont appear on the list, vvvv doesn’t scan this folder recursively.
    fixed for beta>21. note though, that this is not related to woeis initial request. as i understands he wants a gui to select plugins from an assembly.

anyway the \plugin directory is a mess by design. it is not supposed to be human readable. that is where the addonpack kicks in for now. one day we’ll have a gui to add/update/remove addons.

meanwhile you’ll at least be able to sort plugins, not yet in the addonpack in subdirectories with beta>21. but beware that once the plugins go in the pack homegrown duplicates void the vvvvarranty.

@joreg: yes kinda my wish, but more urgent might be, that the xml editing works with relative paths also.

for now i can replace :PLUGINS:\foo.dll|

but not to root\foo.dll|

ouright. relative paths with classnames now working in beta>21

maybe relative paths are working now
but after adding the addonpack the plugins folder still is a total mess.

i suggest creating subfolders for

*the known categories
and furthermore for
*2d gui

perhaps there even should be subfolders like

for plugins with only one node like Lindenmayer etc. i also would create an own Subfolder within the categories subfolder.

i practice this with my modules some time now. on creation of a module this is no effort at all.

this way i can easily zip a single module and it’s helpatch (and other externals)

i beg you to take care of this as soon as possible.
the plugins-collection is already large and it is fast growing.
doing this will get harder almost every day.

helo kalle,
as mentioned above:

  • the \plugin directory is a mess by design. it is not supposed to be human readable. that is where the addonpack kicks in for now. one day we’ll have a gui to add/update/remove addons.

of course we’ve been thinking about that dilemma from the beginning and considering all possible troubles with shared resources we’re still preferring the mess for now. the end-user is not supposed to need to look into the \plugin directory and advanced users should know how to deal with the mess. for all plugins not in the pack create one \plugins\experimental subdirectory which you can sort as you please.

we are aware the situation is not optimal but we’ll not introduce a halfbaked change until we completely unterstand all its dynamics…please bear with us.

thank you for the explanation.

regarding the :EFFECTS: folder i just created a subfolder-structure and extended the difff.xml

seems to work fine.

would be nice if this could make it into the next release/ addon release

see attachment (72.0 kB)