Beta 35.7 Release CanditateJune 17, 2017 posted by: Elias
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
- All Editors from the editing framework have a Gizmo manipulator.
- Links will be drawn red when the pins don’t match anymore. Invalid links are stored in patches so that they can be reestablished when they match again. This should be helpful for dynamic plugin and VL development.
- More love for enums: enum spread shuffling nodes finally behave as wanted, GetSlice added, simplified internal encoding. s/r nodes performance restored VL
- You can search inside patches (Ctrl+F) or across all the currently opened VL documents (Ctrl+Shift+F)
- The whole document structure can be browsed with the new solution explorer (Ctrl+J)
- The default patch type “Patch” is now called “Process” and all patches types in the category VVVV are now picked up as nodes inside vvvv (previously only “Class” used to work)
- Unified user interaction - double click always opens node browser, right click always opens context menu
- Links will now snap to pins
For an in depth list of changes have a look at the changelog.
64-bit vvvv (35.7_rc5) addons (35.7_rc5) 32-bit vvvv (35.7_rc5) addons (35.7_rc5)
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.
Comments are no longer accepted for this post.
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 velcrome! 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 :