On and off there have been some discussion about using OKLAB color space.
This is a wrapping of NuGet Gallery | Wacton.Unicolour 2.3.0

It currently lives here: GitHub - sunep/VL.Unicolour: making a VL version of Unicolour
Currently it requires that you install and reference Wacton.Unicolour.dll from NuGet Gallery | Wacton.Unicolour 2.3.0

I am sure someone can tell me how to do that.

I would like to turn this into a nuget, I will look into that, pointers are much appreciated.

Add comments as issues here Issues · sunep/VL.Unicolour · GitHub


Nice one :)

Does this help?


yes it helps. I have already been looking at VL.IO.OSC, also for where to put help files.

Or this:


The post by @tobyk looks very straight forward.

Looking at the screenshot now I think the naming of the To-nodes might be better the other way round: FromRGBA and ToRGBA.

1 Like

@bjoern good idea, done

These two appear to be process nodes. Do they hold a state, like pads or a cache region? If not, they are better suited to be a util operation.

no they don’t, I just did what I know. Will update

They are called static operations:

Their application nodes do not have a dark bar, indicating that the operation doesn’t hold state.

@tonfilm they are now operations

not quite, FromRGBA broke

EDIT: No it didn’t I just didn’t remove all the references to the old process nodes

Repo updated

1 Like

Get it here NuGet Gallery | VL.Unicolour 0.0.5-alpha


That’s fast progress, congrats!

As a hint for versions. The third number is usually used for hotfixes, the second one is for minor releases that don’t break anything, and the first number is for major releases that potentially break older patches.

When making the first stable package, I personally prefer avoiding version understatement. In my view, the initial version should be labeled as 1.0.0, and subsequent versions can increment from there. The many version numbers like 0.1.3 for most packages in VL can communicate an unfinished quality of the vvvv ecosystem to potential new users.


I was because I needed to figure out how the build script worked and syntax in main.yml.

Is there a way to test the script without making a bazillion commits?

I think you can disable the last step of pushing the nuget in the yaml. but now worries, it is fine to do a few test packages, Microsoft doesn’t mind.

Cool, I also think that the versioning is more to your liking now.

1 Like