Skia nodes does not work when installing mp.dx with VPM

Hello there !

I have noticed a strange behavior with VL in vvvv beta 39 (x64).

My dependencies

Here are the packs I am using : AutomataUI, dx11, VVVV.Audio, vvvv-time and here is the one I want to use but which gives me troubles : mp.dx.


I have a vvvv patch which is using a VL patch to display a sensor monitoring in a renderer. VL patch was made using Template node in vvvv beta. So, the patch is using VL.Skia to display a monitoring, and use primitive elements such as Rectangle, Line, Text, Group, etc.

When only using AutomataUI, dx11 (from the Contribution Manager), VVVV.Audio (from the Contribution Manager) and vvvv-time, everything is working just fine. AutomataUI and vvvv-Time were added manually to the packs folder in vvvv installation folder.

For now, I need to use microdee’s mp.dx pack. So, I install VPM as instructed. Then I go to VPDB to get mp.dx vpack and install it automatically with VPM. No error messages, everything looks great, and I can see it in my packs folder with all the dependencies it requires. But, for now on, every VL.Skia nodes are having troubles, except Group and Group Spectral.

My previous vvvv patch now shows my VL node with a red border but with no error message when hovering it. When I open VL, all Skia nodes are red too, except the two group nodes. I cannot see any values from the input or output pins but just a black rectangle, and this also for all non-Skia nodes.

I tried to disable and enable VL.Skia in the dependencies but it does not work (and I do not have any error in my dependencies, no red ones or missing ones). Also tried to disable and enable all dependencies : same result. I also tried to create a new VL node from Template in my vvvv patch but the problem persists. Moreover, the only way I have found to go back before this problem is to completely uninstall and reinstall vvvv beta and all the packs.

1 Like

thanks for the detailed description.
it could be that some pack comes with an older dependency which then get’s loaded before skia is loaded. but that’s just a guess.

i’ve added an issue…

in the meantime you can try to move the packs one-by-one into a clean vvvv installation and see after which one skia breaks. if you find one, please let us know.

Thanks for your response tonfilm and for adding an issue on this !

So far, I tried to install mp.dx and its dependencies manually without using VPM. I had to reinstall those before with VPM in order to know which ones I had to look for. Every latest releases for each pack was downloaded directly from microdee’s github.

By doing this, I am able to keep Skia working in my vvvv patch BUT my problem is still not solved as I can not use the node I want from mp.dx. It tells me that a dll from a dependency is missing but it is there in my folder. Also, I tried to drag and drop it in my patch, does not work. I guess manual installation is not efficient with microdee’s contributions…

After that, I tried to install mp.dx with vpm again. And guess what ? No missing dll compare to a manually installation : node from mp.dx is working but Skia does not anymore !

So for the moment, it is either having Skia working perfectly and not using mp.dx pack, or having mp.dx working through vpm install but without Skia in VL. The first one is for me the best option right now !

Also, my next test will be to proceed to a new installation of mp.dx with vpm. And, as told by tonfilm, to move every packs one by one into a other vvvv beta installation folder clean of any packs. Hope it will bring some lights on this issue !

Keep you in touch !

So the symptom is: all Skia VL nodes are red when mp.dx is also installed, however they don’t yield an exception when hovering them.

as tonfilm said, best bet will be, an old dll shipped with mp.dx or one of its dependencies, now that’s many potential dll’s…
Does VL has a log output such as vvvv tty, std out or to a file? Maybe it will tell us which one it has problems with.

Sorry for the delay, I could not take a look at it yesterday.

This is a screenshot I took to show you. You can’t see my mouse pointer but it is hovering Rectangle. As you see, just a black rectangle is shown, and this for every nodes, even those unrelated to Skia like Vector or ToString (Conversion).

Yeah that is a lot a dll to check on…

About log output in VL, I do not know if there is something of this kind. Would be great though.

Nevertheless, I did some digging into this issue, and I am experimenting something really strange but interesting in the same time. I explain myself :

As I told you, I can’t use Skia nodes with mp.dx on my patch BUT I have noticed that if I open an empty vvvv beta patch and create a VL template in it, there I can use Skia Nodes with mp.dx installed ! Moreover, if I open this empty patch before my patch, then my patch works correctly, no error from Skia nodes, and mp.dx is working create too. But if I close all, and try to open only my patch, then Skia does not work anymore.
I also tried with a new full blank patch and then run my patch and guess what, it also works great : no problem detected, neither from Skia nor from mp.dx !

So my guess is that something happen when I run my patch, and that by creating an empy patch before, things are correctly loaded. I run my patch using a batch file to parse value with Args node, if that might help.

Will try to go deeper in that direction, as it seems to me that the problem comes from here. If you have any suggestion, let me know !

Keep you in touch !

can you show us what’s in the batch file and what you do with the args?

Sure !
Here is what’s in my batch file :

start C:\vvvv\vvvv_beta_39_x64\vvvv.exe /o "%~dp0\root.v4p" /sessiontime 60 /remoteip "" /gameport 2000 /remoteport 5000 /portCard01 4001 /portCard02 4002 /portCard03 4003 /portCard04 4004 /portCard05 4005 /portCard06 4006

Just a command lline to open vvvv beta with the root.v4p patch which is in the same folder as the batch file. Then arguments with their corresponding values.

In my root patch I have a Globals subpatch which contains Args node and ArgsParser subpatch.
Here is Globals :


And here is ArgsParser :

For now on, I am no longer quite sure it has something to do with my batch file, as I tried to open my patch by double-clicking it, and with an empty patch opened before it works great too. Without an empty patch opened before, same error appears again with VL.Skia…
Really can’t figured this out, as it is really a strange behavior.

this opens a default root.v4p plus your root.v4p… better use the /r (open as root) command if your root.v4p already contains all the necessary nodelist setup. like this:


if your custom root.v4p doesn’t contain this setup, give your startup patch another name and let vvvv load the default root patch.
this avoids the confusion of which root.v4p you want to be the actual root patch.

1 Like

You are right, my custom root.v4p does not contain this setup.So, I give a new name to my patch, but the issue is still there.
I even tried to create a whole new vvvv patch and copy my code into it, in case my previous root.v4p patch was corrupted because of the naming conflict, but it does not change anything at all.

Anyway, thanks for this advice, did not know about this ! I will not be using root.v4p as a name for my future patches now !

does VL log into TTY when inside vvvv?

VL has a log where you can write to if you want. Also when code does Console.WriteLine it ends up there. Beside this nothing is logged anywhere for the user. But this is fine because VL is absolutely bug free and super stable at all times.


@maximesouvestre we are trying to figure out what happened there. can you give us a patch that uses mp.dx and has this problem? and a way to start it up so it breaks.

hey there, steppin’ in, I was working on this project with @maximesouvestre when that happened :)

managed to repro here with b39, here are the steps :

  • downloaded a fresh b39
  • via VPM, installed mp.dx
  • created a blank .v4p, cloned a VL template in it
  • referenced skia, created some rectangles in a loop and displayed the in a renderer. at this stage, all is fine, no red nodes, the tooltips are there and all
  • saved the v4p and closed vvvv
  • re-opened the patch by double-clicking the v4p : the vl node is red and some skia nodes inside are red as described by maxime, and tooltips are black.


  • as maxime said, opening vvvv by double-clicking vvvv.exe and then opening said patch via CTRL+O : no problem.

then i tried to delete packs one by one to see if one could be the issue. I ended up deleting the whole packs folder and the problem still occurs, even with a new patch (created after I deleted all the packs).

here’s an archive with the two V4P I just created

max_bug_skia_mpdx.7z (4.6 KB)

edit : uninstalled and re-installed b39 without installing any packs : the problem does not occur, i can safely open a V4P that uses Skia.


ok, so the question goes to @microdee: what is the VPM installation doing to the vvvv folder when installing mp.dx?

seems clean.

there is this transient dependency doing something to vvvv.config though

it adds, next to lib/core, packs/md.core to the dependency probing folder in vvvv.exe.config and that’s all, for md.stdl, mp.pddn, Notui and their referenced dll’s which are not shipped with vvvv (to my knowledge at least) or doesn’t work when they’re not next to their dependee. Probably one of those dll’s is an older version of what is being used somewhere related to VL.Skia, and .NET refuses to load that stuff, because the older version has been loaded first somehow. Now that there’s an example I might be able to catch which one is the offender with visual studio.

but I already said this, albeit shorter, and I will ask the 3rd time as well: does VL generate logs to somewhere about these exceptions? because there you would see it complaining about multiple versions of the same dll are not allowed to be loaded unless explicitly specified or something.

when going inside a red Skia node, the dependencies menu shows these issues:


but when opening a blank patch and then loading the v4p:


I’m afraid there’s no built-in option to generate a log file, but those assembly load issues can easily be tracked by just attaching visual studio to vvvv.exe - one can then also look at the set of loaded assemblies by opening the modules tab.

i’ve debugged it and libEGL.dll cannot be found/loaded when the error occurs… but i haven’t found the reason for it yet.

@microdee you add this folder to the assembly probing paths, but you shouldn’t put dlls there that come from the .NET framework:

i’m pretty sure one of them is an older version…

EDIT: doesn’t seem to be the problem… I’ve deleted everything in the folder and it still doesn’t work.
However, if I revert the changes to vvvv.exe.config everything works… can you try to release a version that doesn’t need that change? which problem does it solve for you?