Updated the download links again to RC3 - middle click on DX11 renderer input should also create a connected group node (like in DX9).

New release candidate RC4 is up. There won't be a fifth, so if you have any troubles with it better report them now ;)

@tmp thx, should be fixed in RC4.

Got a nasty one. Three of my plugins in vvvv-Message turn red (and only them), but neither exception nor tty hints to why. From my understanding, this cannot be blamed on my code, because my code cannot fault without the full escalated response from the host, i.e. red colored nodes, tty spam and exceptions.

This is happening to HoldKeep and SafeKeep (and therefore somewhat essential for the pack).

I made a downloadable pre-release for demonstration purposes.
Copy the contents of the vvvv-Message.zip into \packs\vvvv-Message.
Start a fresh patch, enable exceptions and add a tty renderer, and then create HoldKeep.

Don't know what to do, because debugging them shows no error whatsoever. They initialize and evaluate the way they are supposed to. But just creating them from blank shows them red.
If it would help I could try to compile them against rc5, would you mind publishing a valid nuget so I can update?

edit:
reproduces either without dx11 pack, or with the newest 0.1.44
tested with x64

Thanks @gregsn, adding an arbitrary EnumName in the pin's attribute fixed it.

If you actually consider this a mistake on the plugininterface's user side (fair enough), then please also escalate an error message if you detect a missing EnumName.

Something you might like to hear: The alpha thingy I tried to show you the other night (with the enum ioboxes displaying wrong data) seems to have vanished.

So from my perspective, there is only the problem with enums flashing red (especially in inspector) for one frame. Don't know if this will cause issues, but my packs seem alright (but then again, I regularily check against null and nil for most pins).