beta37 is done - as far as we know. Now, please help us to find out!
Try the release candidate - link at the bottom - by opening the project you're currently working on and see if it opens timely, patching is responsive and everything works correctly. If not, please let us know in the forum using the alpha tag.
This one can be understood as a late spring cleaning.
To get the desired appearance in the node browser we at times needed to resort, rename and polish nodes and types without changing much in terms of functionality. There were other examples though where we refined some major bits in the basic node set - e.g. file IO and serialization nodes got a complete rework and just got so much easier to use. And we made sure that the core library feels more explorable just by making basic nodes more visible than others. Advanced, experimental or obsolete nodes now don't hide in different packages but can be opted into the list of nodes, while browsing the library. Within that process, we also polished the node browser quite a bit.
But this release also comes with features for you to clean up. Frames help to structure patches in a visual way, groups, and categories in a structural way. You even can tweak the visibility of your nodes in the node browser and by that distinguish rather advanced or still experimental nodes from the daily node set. Library developers will also love the feature to make certain helper nodes internal so that they are free to change or delete them at any time in the future.
Startup speed got improved. Also, there are less VL documents open making the navigation menu more meaningful. Let me not begin with the much lighter ".Net Packages" menu or the much lighter download size. Process nodes now opt for mutation which makes them lighter in terms of memory allocation.
Together these features allow this workflow:
In essence, this allows to do example patches, tutorials or help patches - an essential feature that will make future libraries so much easier to learn. To have a patch start on document load, create a non-generic process called "Root" in the document patch. So again from the end user perspective: no need to create a node in vvvv to see the patch running.
Ctrl-W now behaves like in an internet browser: It just closes the tab - closing the last tab closes the VL window. Ctrl-W doesn't ask you to save the document though. Closing a tab doesn't close the document, it just closes the view onto the specific patch within the document.
If you now managed to hide the VL window use the "Show VL" command in the vvvv main menu to get back into VL.
Debugging should feel much more intuitive, as it now allows to inspect the exact state of the patches for the moment when something went wrong.
Some notes on the debugging settings:
You can switch the settings via Quad menu -> Settings -> Open in editor.
Actually we never really told you about how amazing the Cache region is. If you have any node that you want to perform better, ask yourself if it wouldn't be enough to only compute it when the input changes and then cache the computed results. The cache region allows expressing this easily. The cache region actually got added with beta36, but now the interplay with other constructs works better.
Loops for example now output their spreads in a way that the changed-detection of a downstream connected Changed node or Cache region only triggers if the slices actually changed from frame to frame.
Some of this stuff may for sure sound pretty special interest, but we have the feeling that these details matter in the end for having an expressive but playful language.
All in all this release makes VL easier to learn, use and develop for.
for an in-depth list of changes have a look at the changelog.
Release Candidate 6
Beware: Make sure you secure your data. Patches saved with an alpha might lead to not being able to open them with the former beta.
you forgot to mention that the associated v4p file icons turned orange :P
haha! well, I guess golden quads shouldn't get mass ware, otherwise they lose their value. so how about: v4p files stay concrete colored, whereas vl files may turn golden? noted the issue, thanks!
haha @microdee, nice one. so icon selection seems quite random or maybe alphabetic? vvvv.exe has a few icons embedded as resource, why suddenly take another one? investigating...
ha yeah golden quads, vvvv became exquisite and fancy :D
phew nice it's only a bug then
the new splash compilation overlay is sometimes detached from the splash quad, and will reside on a different monitor than the splash
edit: tracked, and fixed accoring to tonfilm
when starting the alpha, and doubleclicking a v4p, the v4p will not be openened with the (already open) vvvv instance, but will instead start with the registered vvvv.exe.
makes it look like it is defaulting allowmultiple to true?
edit: my default installation of beta36 had an args.txt, flagging /allowmultipe
so the doubleclick on a v4p is directed to said default installation. this explains the unexpected behaviour
@velcrome : isn't it the JumpToError thingy ?
you mean #2? the locking thing?
calling this behaviour a "Jump To Error"-feature seems simply wrong, if a patching bug (that wasn't even there in beta36, patch is running ok there, just accepting blame preemptively here) is gravely elevated so it cannot be investigated, mitigated, or fixed.
I am sure there must be something wrong here with the RC, no matter whats wrong with the patch itself. it should still allow me to look around my patches, no?
@velcrome yes, you discovered a bug, latest alpha doesn't jump to error if PauseOnError is off. compile splash will also be on primary screen now. we could not reproduce your third issue, make sure you don't have any args.txt besides your vvvv.exe that has /allowmultiple set.
we still have a few minor things, but new RC should be up soon. thanks a lot for testing!
Thanks for looking into them. Always glad to help, even if it means scrolling bad news sometimes. But bad news early, well processed, will turn into good news later, no?
I put an edit on each one of them, so it is easier to track bugs presented in that shorthand manner
perfect, rc4 on the roll!
RC4 and RC3 earlier, I have the famous "helo, sorry I cannot start. please run setup.exe to see what my problem is" error.
I fixed it by unchecking and rechecking the "Disable Win10 Fullscreen optimizations"
Log from /logstartup prior to that:
Disabling "Show Editor" on VL IOBox Configure-Contextmenu won't let me re-enable it.
Toggle turns true, but Editor won't show again.
@readme: thanks, tracked for next release
@sunep: the log says: "Addflow5.ocx not registered. Run setup.exe!" so this was the reason for vvvv not starting, not the "Win10 Fullscreen optimization". anyway i improved the error message to include the information also, so we not only have it in the log.
everything was green, including the addflow checkmark
@sunep, most likely because as you started setup.exe (as you were told), it simply registered addflow and thus showed all green. so we're assuming no bug there unless proven otherwise.
fast light :)
osc, boygroup, arduino, old projects perfect works....!!!
I consistently get the error "Addflow5.ocx not registered. Run setup.exe!" on fresh installs
@sunep, which is correct. before running a new vvvv.exe you have to run setup.exe once.
I do this:
1. run setup.exe and install everything until everything is green
2. run vvvv.exe, I get the error message
3. I run Setup.exe again, uncheck the disable fullscreen... pin
4. quit setup.exe
5. start setup.exe
6. recheck disable fullscreenn...
7. run vvvv.exe and now it will run
EDIT: I think that is a couple of too many times to run setup.exe and know that you need to uncheck and recheck the fullscreen stuff
latest rc6 fixes the problem with setup.exe as reported by sunep, thanks for insisting!
@velcrome Throw is under experimental, you need to enable that filter in the nodebrowser:
Oh, I only checked in Advanced.
anonymous user login