My dear vvvv users,
we've scheduled beta 35.7 for release at the end of the week. To make it as polished as possible here comes a release candidate for you to tamper with. Download it, try it and report any findings in our forums.
Also note that this release will be the last one before NODE17. So workshop hosts especially should have a look at it whether or not everything they need is in there and working.
The noteworthy changes are
For an in depth list of changes have a look at the changelog.
This release is intended to be the last one of the beta 35 series. We changed plans a bit and deliberately kept the rather big internal feature branch (which allows you to drag'n drop .NET assemblies onto the patch) out of this release as it will need a longer testing period in the alpha build channels.
Just updated the download links to RC2 which fixes a few high DPI issues.
Updated the download links again to RC3 - middle click on DX11 renderer input should also create a connected group node (like in DX9).
changing linkstyle unhides hidden links again.
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.
since you didn't find any troubles with RC4, we tested it and found our own :)
so here is RC5, aka final_final_now_really.
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?
reproduces either without dx11 pack, or with the newest 0.1.44
tested with x64
it is the hidden "Formular" pin that is not used at all, which comes with the problems.
it gets created but not used. no enum type assigned... sooo. either you set a proper enum type, or you just delete the pin or argue that it is us to blame.
for the latter strategy i am now again considering it no programmers fault of creating an enum without assigning an enum type.
thanks for the report
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).
Yet another one :
anonymous user login