Blog
Blog-posts are sorted by the tags you see below. You can filter the listing by checking/unchecking individual tags. Doubleclick or Shift-click a tag to see only its entries. For more informations see: About the Blog.
Hello everyone,
Introduction
I'd like to give you an update on the toolkit front, that vvvv has always been. While vvvv beta can be described as a dynamic system, mutating while you mold your patches, vvvv gamma and its workhorse VL are of a different kind. With VL we embraced features like
- static typing with its ability to detect errors early,
- .Net DLL import opening a universe of possibilities,
- user-defined data types that interplay with those defined by others,
- compilation with its ability to export an app as an executable...
In short, we embraced robust software developing strategies that at first seem to contradict the idea of a playful development toolkit that allows you to mold your app. We went for compiled patches, running, and hot-swapping them while you are building them.
But we envisioned vvvv to be both
- the playful toolkit you fell in love with
- combined with the promises of a compiled language
While my last blog post was about the language, let's focus on the toolkit this time.
Toolkit
Let's have a look at some features that allow you to interact with the VL runtime, the system that runs your patch while it allows you to edit it. The features here empower you to enrich the patching experience. We understand that these improvements need to "trickle up" into the libraries and only thereafter will have an effect for all users.
So the following is probably mostly interesting for advanced user and library developers.
Tracking Selection within the Patch Editor
You now can react to a selection within the patch editor. The more libraries do this the more playful the environment gets. We still have to figure out all the use cases, but here is a list of what's possible already
- separate the core functionality from its Editor UI. Imagine a TimeLine node that is decoupled from the timeline editor.
- an Inspector for nodes or pads
- a Preview like this:
- even the help browser itself uses the feature to provide help for the selected node.
And there is more:
You can get a Live Element for a certain Pin or Pad.
- Copy the permanent identity of the element into the clipboard by CTRL-SHIFT-I (I stands for Identity).
- GetLiveDataHubForSerializedID hands you the pin or pad.
useful for the cases where you want to always inspect a specific pin or pad of some patch. This can be helpful for debugging.
Let the Patch Editor navigate to a Patch
When a Skia Renderer is your active window, Ctrl-^ let's you jump to the patch in which it is used. This is handy when you opened a bunch of help patches and you want to see the help patch that is responsible for the output.
You can use the node ShowPatchOfNode to do the same trick.
Tooltips for your own data type
Here you can see a custom tooltip for a user patched type "Person".
You now can patch your own tooltip with RegisterViewer. This way the patching experience will be so much more fun. We're in the process of adding more and more viewers for our types.
Runtime Warnings
Up to now, we had
- Red elements: Static errors. (E.g. a node that can't be found) These errors make the compiler ignore certain parts in your program as they are currently in development. The rest still runs. (Something what C# and others just can't)
- Orange socks on links: Static warnings, potential problems. Something to look at when searching for a bug.
- Pink nodes: Runtime Errors. A problem that only got detected during runtime and which is such a big problem suddenly that the system can't work as planned. Some patches don't run as planned. There are different ways how to handle these, pointing you at problems at runtime, but they can be painful.
And now we introduce to you:
- Orange nodes, Runtime Warnings: They show you a problem at runtime. But it doesn't harm your system as pink nodes do. Orange nodes are runtime warnings. Library developers can put warnings on their nodes in order to communicate to the user that something is slightly off.
You can try it yourself by using the Warn or the Warn (Reactive) node.
The warning will not only show up on the Warn node, but also on the applications of your patch.
S&R nodes
Sometimes it's just convenient to be able to send data from one patch to another without the need of feeding the data via pins. We now have send and receive nodes, like known from beta.
Features:
- The channel can be anything. It doesn't have to be a string.
- They have several warnings. E.g. for when none or many senders are on a channel that a receiver is listening to.
Descriptive Tree patching
Some libraries focus on a simple idea:
Let the user build an object graph that describes what he wants in a declarative manner and the library will do the hard work to follow that description.
Examples for this approach are
- VL.Stride
- VL.Elementa
- to some extend VL.Skia
VL.Stride and VL.Elementa have in common that they focus on a very certain type of object graph: A tree made out of entities and components.
Libraries like these can now talk to the user and enforce the user to not build any kind of graph, but a tree-shaped graph (where one child doesn't have many parents).
VL.Stride uses TreeNodeParentManagers, Warn nodes and S&R nodes internally to the deliver this feature:
You'll very soon be able to inspect those patches.
Help patches to all those topics will show up in the CoreLib API section (at the bottom of the listing).
We hope you'll enjoy these ways of integrating with the development env.
Thank you and we'll see you soon!
yours devvvvs
Did you ever wonder what the first things were, that the cool kids in the VL.Stride EarlyAccess program created with the new 3d rendering engine for vvvv gamma?
It's been only a few weeks, but stunning pixel combinations got posted into our early access chat room.
And we collected them in a gallery for you:
A big THANK YOU to everyone involved!
We can't wait to see what you will create with it. And don't miss the workshops at NODE20 if you want to learn how to use it.
We are looking forward to the public release as much as you do,
yours devvvvs
In a quest to get more basic things working out of the box with VL (ie. using vvvv beta>=40 or the all-new vvvv gamma), we took on to support your favorite depth cameras. Most of the cameras and their APIs share basically the same features as a baseline and then some of them have a few extra features. This means that using them in vvvv works mostly the same for all of them.
You have the main device node that you connect ColorImage, DepthImage, PointCloud, Skeleton,... nodes to, to get the desired info out of them. See the help patches coming with the packs for details.
Here is a list and comparison of all available depth cameras with links to the respective packs on nuget.org. To learn how to use nuget packs with vvvv please watch HowTo use Nugets.
Kinect
The original Microsoft Kinect or the XBOX 360 that was released a bit later.
Get the VL pack on nuget.org.
Created with support by chaupow.
Pros
|
Cons
|
Kinect v2
The second version of the Microsoft Kinect.
Get the VL pack on nuget.org.
Created with support by ravazquez.
Pros
|
Cons
|
Azure Kinect
The third version. AzureKinect.
Get the VL pack on nuget.org.
Get the VL pack for skeleton tracking on nuget.org.
Pros
|
Cons
|
Orbbec Astra
Orbbec Astra.
Get the VL pack on nuget.org.
Pros
|
Cons
|
Intel RealSense
Intel RealSense.
Get the VL pack on nuget.org.
Pros
|
Cons
|
Nuitrack API
Nuitrack is a piece software that works with all of the above cameras and provides skeleton, hand and face tracking.
Get the VL pack on nuget.org.
Created with support by ravazquez.
Pros
|
Cons
|
Leap Motion Controller
The Leap Motion Controller device provides hand and finger tracking.
Get the VL pack on nuget.org.
Pros
|
Cons |
Please help us improve this list of pros and cons. Know any other or disagree with some mentioned, please add them in the comments! This could eventually grow into a page of the gray book.
Evvvveryone,
is happy, that we're finally looking at a candidate for beta40, which will ship with the latest and may i say greatest integration of VL to date that is 2020.1.4!
For the latest changes in VL, please consult the vvvv gamma series 2020.1.X changelog.
Most notably this gives you access to all the latest goodies that are popping up as .NET nugets lately. Yes, we're still missing a convenient overview of those, but meanwhile a search for VL on .nuget.org gives you an idea. Still wondering how to use those? Watch this tutorial on How to use Nugets to find out.
So please test this against your current projects. Make sure that everything is running as expected. If not, please leave a comment below or let us know in the forum.
Download
vvvv beta40 x64 RC2
vvvv beta40 x86 RC2
Changelog for Candidates
RC2
- now using latest RCPSharp, allowing the Rabbit again to listen on 0.0.0.0
Hello everyone!
We are pleased to announce that from now on VL language design ideas will be specified in public.
This allows you to see
- which areas we identified to work on (quests)
- what ideas we came up with to fix those issues (proposals)
- which proposals got favored over other proposals (decisions)
- which proposals got moved onto which milestone
But it also allows you to join forces with us. Since in the end, it's all about your patches, we appreciate your feedback.
We decided to start clean: For now, we didn't throw all our language ideas into this repository. In its current state, we only see issues that came up in the last days, so the selection of issues is quite incomplete. Other ideas that might be more important and didn't come up in these days will eventually make it there as soon as they come up again.
We'll address quests by you or us with proposals that might be fresh or have been around for some time. We'll try to communicate different approaches and the pros and cons. And we'll try to single out very few issues that are just too promising to not having a shot at. Changing the language is quite hard, so expect an insane ratio of proposalsThatSoundNice / featuresComingSoon.
We were quite impressed by how this was handled by the C# Language Design Team. So we copied the approach.
Sometimes it's hard to distinguish between the language and ways of expression within the language. You just search for a way to address a certain problem. How would I structure my patches? We'll allow these so-called design patterns to be discussed in this repository as we want the language to be able to follow well-established ideas on how to solve certain types of problems. Here is an example.
But for now: Welcome to the club! \o/
helo evvvveryone,
we're preparing for a vvvv beta39.1 release and here is a first release candidate. As you'll see in the change-log it is a rather minor update with only fixes. It does not yet include the anticipated update to latest VL, which we save for upcoming beta40. We just want to get another stable version out before such a bigger update that including latest VL will mean.
Remember that via VL you have access to many more goodies. Here is a convenient list of VL nugets that work with this release. To learn how to install nugets please consult this documentation and then use these commands to install them:
(To use the latest version of these nugets you'll have to wait for upcoming beta40 or use gamma2020.1)
nuget install VL.OpenCV -Version 0.2.141-alpha nuget install VL.Devices.Kinect2 -Version 0.1.45-alpha nuget install VL.Devices.Realsense -Version 0.1.7-alpha nuget install VL.GStreamer -Version 1.0.18-gadcd7f95e5
nuget install VL.Audio -pre nuget install VL.IO.M2MQTT -pre nuget install VL.IO.NetMQ -pre nuget install VL.2D.DollarQ -pre nuget install VL.2D.Voronoi -pre
If you have other public nugets that you tested to work with this release, please post them in the comments so we can all mention them in the upcoming release notes!
Download
vvvv beta39.1 x64 RC1
vvvv beta39.1 x86 RC1
And as always, please test and report your findings!
This is my talk at Ircam earlier this year, where I tried to introduce vvvv gamma to an audience not necessarily familiar with vvvv but most likely already with the idea of visual programming. Given the fact that Ircam was the birthplace of Max and PD which are still both in heavy use there.
In 25 minutes I tried to give a glimpse at vvvv by focusing on four things that I believe make it shine:
- Loops
- Multithreading
- Object Oriented Patching
- Extensibility
Also I pretended that it is completely normal to already have a 3d engine with it...
For talk description and recording of other talks see: https://medias.ircam.fr/xcc0abe
And here we go!
Only about a year after the first public preview of vvvv gamma we hereby announce what will be the final round of previews:
The vvvv gamma 2020.1 series.
We have a code-freeze. This is essentially what will be in the final release. We'll only be adding to documentation and fix showstopper bugs, should they come up. Of course we're aware of many more issues but we hope at this point to have squashed all the biggest buggers and are confident to release a first stable version within the next weeks.
What's new compared to the vvvv beta series
LanguageBesides staying true to its nature of being a an easy to use and quick prototyping environment, vvvv is also a proper programming language with modern features, combining concepts of dataflow and object oriented programming:
|
Node LibraryWhile for now the number of libraries we ship is limited, the fact that you can essentially use any .NET libary directly mitigates this problem at least a bit. Besides there is already quite some user contributions available in the wip forum and here is what we ship:
|
Learning
The integrated help-browser comes with a lot of examples and howto-patches and a growing number of video tutorials is available on youtube.
Pricing
We've announced the pricing model of vvvv gamma in a separate post. Until further notice, the previews of vvvv gamma are free of charge but due to its preview-nature we don't recommend using it in commercial scenarios yet.
Download
Here you go: vvvv gamma 2020.1 preview 0040
Changelog:
Upcoming
0040 27 03 20
- Re-enabled very rough and highly experimental support for attributes in roslyn backend - Elementa inspector patch working again
- Fixed a crash related to recursive type rendering
0032 24 03 20
- Fixed null pointer when opening patches making use of pin exposure
- Fixed a few regressions introduced with one commit in previous version which caused issues like https://discourse.vvvv.org/t/2020-1-elementa-bang-broken/18354/3
- Fixed Args node outputs
- Added base64, url and html encoding nodes
- Added more HowTos
Compared to the 2019.2 series
- Args node now handles options without parameters
- Added a bunch of new simple howto patches
- Added clock to display call frequency of runtime value in tooltip
- Added ToImage [IReadOnlyList]
- Removed culture specific resource assemblies and disabled pdb files in release build
- Fixed a sync issue in UI when disabling manual signature and fixed pin synchronization when using "Connect to signature"
- Visualize model synchronization step in progress bar
- Using Memory<byte> instead of unsafe IntPtr in IImageData
- Fixed deserialization of collection of characters
- Fixed assignments to pads sometimes having a side-effect on other pads with that same name
Ideally this will be the last preview, realistically we'll have to release some more. So please check back often and report your findings in the chat, forum or a comment below!
Yours truely,
devvvvs.
As we near the official release of vvvv gamma, let's take a minute and look back on what happened so far.
Here's a compilation of every vvvv gamma and VL related blog post.
We hope it serves as both, an overview of historic developments and a helpful learning source for VL users that might have forgotten some along the way:
2020
Announcement for stable release of vvvv gamma 2020.1: vvvv-gamma-2020.1-release
Download and changelog of vvvv gamma 2020.1 preview: vvvv-gamma-2020.1-preview
Download and changelog of vvvv gamma 2019.2 preview: vvvv-gamma-2019.2-preview
Introducing help patches per node: vl-help-patches
A roundup of the latest features of the VL.Xenko 3d rendering engine: vl-xenko-3d-engine-update-3
2019
Reworked licensing model: vvvv-gamma-licensing-2
New web presence for vvvv gamma: visualprogramming.net
Introducing the HelpBrowser for easy in-app learning: vl-getting-you-started
Big feature, export executables: vl-exporting-an-application
Announcing our cooperation between Xenko and vvvv: vvvv-meets-xenko
Background information on the VL compiler overhaul: vl-new-roslyn-based-backend
Public VL presentation on a .NET developer conference: vvvv-at-dotnextconf-moscow-video
Download and changelog of vvvv gamma 2019.1 preview: vvvv-gamma-2019.1-preview
First draft of the new licensing model: vvvv-gamma-licensing
Switching all VL libraries to Xenko vector types: vl-switch-to-xenko-math
Tooltips and runtime value inspection are pretty and can be patched: vl-tooltips
IOBoxes are now feature rich and can handle collections: vl-the-big-iobox-update
Big progress on computer vision: vl.opencv-release-candidate
Dynamic input/output pins are here: vl-input-and-output-pin-groups
Understanding the difference between definition and application: vl-the-application-side-of-things
Added regular expression nodes: vl-regular-expressions
2018
Public vvvv gamma and roadmap announcement: the-road-to-gamma
Progress report on the VL.Xenko 3d rendering engine: vl-xenko-3d-engine-update-2
Improvements on the VL.Skia 2d rendering engine: vl-skia-update
Initial progress report on the VL.Xenko 3d rendering engine: vl-xenko-3d-engine-update-1
Announcing the VL.Xenko 3d rendering engine: vl-threedee
Announcement and insight into the VL.Skia 2d rendering engine: vl.skia
Reading and writing VL data types to disk: vl-serialization
Explaining the structural elements of VL documents: vl-groups-and-categories
Beatify and organize your patches with frames: vl-frame-your-patches
Update on file read/write: vl-improved-file-io
Big cleanup of the VL.CoreLib: vl-corelib-cleanup
Working with different threads and main loops: vl-patch-your-own-mainloops
Announcement of computer vision for VL: vl-opencv-is-in-da-house
The fundamental building block for timelines and searches in sorted collections: binary-search-for-your-keyframes
How to connect image data types of different libraries with each other: vl-image-exchange-interface
Prepare GPU data directly on VL to use it with dx11 rendering: dynamic-dx11-buffers-in-vl
2017
Better debug features: vl-one-frame-at-a-time
Maintenence release for Arduino/Firmata: firmata-updates-and-fixes
Import any .NET library (!) into VL: vl-using-.net-libraries-and-writing-custom-nodes
Parser for serial data and other byte streams: new-tokenizer-nodes
Announcing reactive/async programming with observables: vl-reactive-programming
Nodes for working properly with MIDI: vl-event-based-midi
Parse, modify and write XML and JSON: vl-xml-and-json-nodes
Update on 2D and 3D editing: editing-framework-update
Nodes to work with network sockets: vl-networking-and-async
2016
Nodes for Arduino/Firmata: firmata-second-service
Nodes to work with input gestures: zoom-pan-rotate-touchgestures
Cummulative VL update (performance, clock and time, high DPI): vl-progress-report-4
Nodes for working with the file system: vl-many-paths-lead-to-rome
Initial file handling nodes: let-me-present-to-you-file-io
Cummulative VL update (UI improvements): vl-progress-report-3
Cummulative VL update (UX improvements): vl-progress-report-2
Cummulative VL update (new UI elements): vl-progress-report-1
Huge update overall and new downloads: vl-midsummer-nights-dream
VL progress report (pads, fields, properties, operation signature): vl-spring-update
VL progress report (patch structure, categories, library): vl-winter-update
Learn about the fundamental data types of VL: integer-and-primitive-types-in-vl
Nodes for 2D and 3D editing: introducing-the-editing-framework
2015
VL progress report (new devices, library, nuget, UI): vl-autumn-update
Working with value ranges: mapping-and-ranges-in-vl
Understanding spherical and cartesian space: polar-spherical-and-geographic-coordinates
VL progress report (library, eye tracker, UI, loops): vl-summer-update
Add type annotations to properties: vl-type-browser-now-in-alpha-builds
Community feature voting: vl-feature-voting
First official download of VL: vvvv50-vl-pack-alpha
Preparing for the first launch: 50-pre-release-roundup
Understanding data type patches: 50-custom-datatypes
Understanding generics: 50-generics
2014
Understanding properties aka. fields: 50-properties
Understanding operations aka. methods: 50-colors
Initial thoughs: 50-that-next-big-thing.-an-overview.
Object oriented patching for the masses: 50-vl-features-i-a-patch-is-now-a-class
The very first applications built with VL: 50-the-humble-quad-bundle
Anything to add? Let us know in the comments.
yours,
devvvvs
Moments later,...
...we're announcing the immediate availability of the vvvv gamma 2019.2 series of previews, finally including one of the more anticipated features in vvvv history: Executable Export.
This means we are now in the final stage of the preview leading up to a proper initial release after the waves introduced by the new features in this series have been smoothed out.
What's new compared to the vvvv beta series
LanguageBesides staying true to its nature of being a an easy to use and quick prototyping environment, vvvv is also a proper programming language with modern features, combining concepts of dataflow and object oriented programming:
|
Node LibraryWhile for now the number of libraries we ship is limited, the fact that you can essentially use any .NET libary directly mitigates this problem at least a bit. Besides there is already quite some user contributions available in the wip forum and here is what we ship:
|
Tutorials and HowTos
A growing number of video tutorials is available on youtube.
Pricing
We've announced the pricing model of vvvv gamma in a separate post. Until further notice, the previews of vvvv gamma are free of charge but due to its preview-nature we don't recommend using it in commercial scenarios yet.
Download
Here you go: vvvv gamma 2019.2 preview 321
Changelog:
Upcoming
321 04 03 20
- Fixed copy-paste of output pins not merging correctly into target patch
- Fixed patch pins not always being synced to nodes with the "Connect to Signature" flag
- Do not create empty regions (nodes without a patch) when syncing to a node definition which lost its delegate input
- Should an incremental compilation of a project fail, try from scratch before giving up.
- Fixed implicitly inserted CreateDefault node not being tracked in dependency graph - fixes backend crash when modifying it
- Fixed assembly initializers being called far too often leading to long hotswap times in bigger projects
- Fixed regression that enums don't have System.Enum as super type anymore (was for example breaking VL.Devices.Kinect2)
- Fixed vvvv.exe becoming a ghost process when crashing on startup
- Fixed disposable interface being added twice when VL.CoreLib was missing - caused subsequent emit crash
- Only load project assembly from cache if all its dependencies have also been loaded from cache - fixes emit error when dependent project was modified
- Backend will now unload not needed project states
- Faster RGBA to RGB conversion (IImage to SKImage)
- Fixed cast exception triggered by node browser when browsing through nodes from assemblies
- Fixed various crashes when opening a completely broken document structure (missing assemblies, missing documents etc.)
- Fixed file/string readers not eliminating BOM
- New nodes Loop [Observable], Subscribe (Provider) [Observable], Using (Provider) [Observable] and moved PollData, PollResource from Resources to Observable category
- New region Loop [Observable] managing internal state as well as giving access to cancellation and observer to optionally push data
- Subscribe [Observable] returning a provider which manages the lifetime of the upstream observable sequence
- PollData and PollResource now stateful internally thanks to making use of new Loop
- Removed recently introduced TryOpen/Retry/RunOn [Resources] nodes as they turned out as hard to use (deadlock) and not necessary
- Added new struct ArrayBuilder used by two new nodes:
- StoreSequence [Collections.MutableArray] to efficiently either grab an upstream array from a sequence or copy its content into an internal array which will then get exposed.
- HoldLatestCopy [Collections] to efficiently copy data pushed from a background thread into the main thread
- Bunch of minor performance improvements to VL.Skia by making use of methods provided by the System.Runtime.CompilerServices.Unsafe class and calling SKCanvas.SetMatrix in Transform nodes, not rendering nodes
- Fixed allocation issues of Points [Skia.Layers] by exposing internally used DrawPoints via ReadOnlySpan
- Fixed assignment of higher order regions not being carried over to expanded patch
- Ensure names of emitted assemblies are unique even after reloading a document
- Type Unification got even more robust and versatile. Better type renderings and type error messages.
- generic node applications with generic pins (like "a Asset") previously just lead to type "Asset" for the generic pin for as long as the pin was still unconnected. This way you often had to force connections. Now these type parameters stick around leading to not calling the node until to the point where you actually connect to something.
- types can look like this: "a Asset". This is a short rendering for a constrained type parameter "T1 where T1: Asset". F# also has an abbreviation for types like this. They call it flexible types.
- types can look like this: "Sequence (Ungeneric) & IReadOnlyList<T>" which is a beautified rendering for "T1 where T1: IEnumerable, IReadOnlyList<T>"
- if necessary (like on recursive types) the type parameter will not get hidden. "T1: IReadOnlyTree<T1>" is not hiding the T1 behind an "a IReadOnlyTree<T1>" in order to make clear that it references itself.
- invalid type annotations (those where the type arguments of the user break the constraints of the type parameters) lead to proper error messages.
- quite less emit problems due to more robust type unification
- Added RemoveAll for Spread and SpreadBuilder
- Fixed Random node not being thread safe
- Fixed ForEachParallel crashing with input count of zero and modified it so it returns a spread builder instead of a spread to avoid allocations
236 18 02 20
- added ShowOrigin setting
- More type inference fixes
- Fixed primitive types not having any super types like IComparable (was reported in chat by sebl)
- Fixed type constraints on higher order region with one single patch not properly generated should the name of the inner patch have changed
- Fixed "auto connect to signature" of patches like CreateDefault which have a fixed set of pins
- Fixed output pin groups of type Dictionary<string, obj> not working anymore when pin on application side was annotated
- Fixed compiler crash when having a generic type annotation in a patch
- Fixed CLR array types not being mapped to type symbols
- Removed Spread.Pin/Unpin - same functionality is available through much safer TryGetMemory/Pin -> MemoryHandle.Dispose path
- Fixed pixel format being swapped from R8G8B8 to B8G8R8A by SKImage.FromImage node
- Fixed null pointer when trying to navigate into patches of completely broken documents
- Fixed higher order regions not working when definition added an inner pin
- Added a few convenience nodes for resource providers useful when opening and polling devices. Even though not yet released they already look promising for devices like Kinect or Astra.
- Fixed minimal changes on solution made by compiler getting discarded (pin order somtimes not updating on application side)
- Fixed pin group builder (ModifyPinGroup) changing the model when it shouldn't
- Fixed repeat loop not working on inputs of type T where T : IReadOnlyList
211 07 02 20
- Don't use BOM in UTF8Encoding
- Backend generates new lines on its own without having to rely on super heavy NormalizeWhitespace function. This should get rid of very long compile times when traversing deeper into a library. Debugging the generated C# code with Visual Studio will only work properly when running with -debug and -nocache flags
- improved type unification cleverness and stability
- Helpbrowser: chat language buttons added
- AppExporter "Export" button gives immediate feeedback
0193 31 01 20
- fixed pin-reordering in signatures as reported here: https://discourse.vvvv.org/t/2019-2-0081-pin-reordering-buggy-behavior/18132
- Removed private flags between our package dependencies as it caused msbuild to skip copying certain assemblies coming from VL.CoreLib as well as making our packages smaller.
- Fixed parts of patches being grayed out and when traversing inside becoming all good - compiler was missing one iteration in recursive blobs -https://discourse.vvvv.org/t/lazy-type-inference/18066
- improved support for helppatches
- Reworked error handling of CreateDefault and RegisterServices operations
- Extended the general renaming code path to handle all cases and removed obsolete rename commands
- The Micorsoft Build Tools 2019 are now optional. If not installed the Export menu entry will be disabled
- Removed the .vl suffix on generated executable and fixed Run button
0169 22 01 20
- Couple of fixes in type unification algorithm - fixes for example VL.Devices.RealSense
- Exporter uses nuget restore to figure out what assemblies are already referenced by packages. Fixes export of VL.OpenCV as well as reported issues like https://discourse.vvvv.org/t/export-application-problem-superfluous-system-reactive-reference-2019-2-0125/18145 https://discourse.vvvv.org/t/app-export-failure/18107
- Fixed pins not highlighting in valid cyclic connection attempts like FrameDelay
- Fixed wrong VL factory being used in exported apps - type names used by serializer were different
- Fixed target code when not implementing an interface yet - https://discourse.vvvv.org/t/exception-when-implementing-an-interface-2019-2/18122
- Do not try to restore packages without a version on export - fixes export of VL.DBSCAN which has buggy reference to non-existing VL.CoreLib.VVVV
- Fixed missing or wrong assembly references in exported projects.
- Fixed default value of delegates in generic patches. CreateDefault operations will be auto-generated for all delegate types.
0140 09 01 20
- Fixed ToObservable (Switch Factory) - used by many reactive nodes - not calling the factory after the element type changed due to a hotswap
- Added HighDPI awareness to App.config for exported apps
- Fixed stack overflow when patching a CreateDefault - system will now generate an error as long as the output is not connected
- The default value of a record will again be cached in a static field
- Fixed serializer serializing auto-generated fields
- OSCMessage (Split) now returns timetag
- CTRL+Shift+F now also finds interfaces
- updated VL.OpenCV to 0.2.133
- fixed problem with pin-editor for serializable types like Rectangle
- Splash screen shows up in taskbar and has proper icon
- Counter Clamp/Wrap/Mirror reset under/overflow correctly
- NodeBrowser now has a TextBox that can select/copy/paste
- Fixed regression that bang and press IO boxes would sometimes stick to true
0081 16 12 19
- Fancied up the helpbrowser
- Fixed problem scrolling in menu dropdowns: https://discourse.vvvv.org/t/main-menu-ui-scroll-with-mousewheel-within-dropdownmenu-lists/18083
- Fixed a crash in UI when creating a frame https://discourse.vvvv.org/t/creating-frames-throws-exception/18067
- Fixed crash in UI when trying to retrieve the default value of an imported generic typehttps://discourse.vvvv.org/t/2019-2-0026-cannot-create-iobox-tuple-t-t/18061
- Fixed apply node lifting being applied to nodes which already had an apply pin (like Console.WriteLine)
- Fixed crash when referencing an assembly like Bridge which tries to replace the whole mscorlibhttps://discourse.vvvv.org/t/gamma-x-2-nuget-import-error/18038
- Fixed regression that the "valid pins are ..." warning wouldn't show up when implementing an interface
- Type annotations on pads which point to a field will now truly be ignored and also cleared - was reported in chat by björn
- The version of the currently used package will now be written to disk. Allows to introduce converters for libraries at a later stage.
- Fixed regression that the Serializable attribute wasn't set on emitted classeshttps://discourse.vvvv.org/t/issue-with-serialization/18064
- Fixed regression that source packages (provided through command line arg --package-repositories) wouldn't get higher priority than installed oneshttps://discourse.vvvv.org/t/2019-2-0026-weird-behavior-of-package-repositories-arg/18077
0026 10 12 19
- Fixed loading of VL.Devices.RealSense
- Fixed empty error message on faulty type annotations
- When generating a C# project, local source packages without a nuspec will not get includedhttps://discourse.vvvv.org/t/exporting-fails-to-build-due-to-dependency-it-isnt-using/18043
- Fixed regression that nodes on auto-connect would show warning as well as their pins of unused fragments wouldn't connect to the default patch anymorehttps://discourse.vvvv.org/t/gamma-2019-2-connect-to-signature-does-not-work-in-this-region-even-outside-a-region/18048
0015 06 12 19
- Patch drawing is antialiased and icons are showing again
- Fix for drawing transparent PNGs
- Fixed regression that delegate regions wouldn't create their pins anymore
- Emit exception will show first error now as it's message
- Fixed specialized operations not being marked as unused if there containing type was - seehttps://discourse.vvvv.org/t/gamma-x-2-breaking-not-opening-old-patches/18036
Compared to the 2019.1 series
Features
- Export to executable
- Faster startup and less memory consumption due to precompiled libs
- Recursive operations and datatypes
- Runtime errors: marked node is now always correct
- Generated C# code can be debugged using Visual Studio
- Help patches (where available) open when pressing F1 on a selected node
Breaking Changes
Unfortunately this preview introduces some breaking changes. This means that projects that were working fine with 2019.1 previews may no longer work correctly with 2019.2 previews! If you encounter such a situation and cannot resolve it on your own, please get in touch via forum or chat! Here is a list of possible problems you may encounter:
- Existing patches may need additional type annotations due to changes in the type unification
- Execution order of nodes may be different if it wasn't explicitly expressed before
- Generic type parameters in an interface patch will now always belong to that defined interface (and not any of its operations)
- Not really breaking, still a change: Runtime errors: no values in tooltips when in pause state
For technical details please see the blog post about the New Roslyn based backend.
We'll update this blogpost with new preview-releases regularly. Please check back often and report your findings in the chat, forum or a comment below!
Yours truely,
devvvvs.
anonymous user login
Shoutbox
~2d ago
~2d ago
~3d ago
~3d ago
~5d ago
~7d ago
~8d ago
~9d ago
~10d ago
~12d ago