Clarity — ports and cables coloured by signal type, with click-to-connect patching

Clarity makes a patch easier to read and quicker to build. It does not process audio and does not alter the patch. Here is a short video of it in use:

What it changes about how the rack looks. Ports are colour-coded by signal family — audio, control voltage, gates and triggers, and pitch — with the ring position showing whether a port is an input or an output. Cables take the colour of what they feed, so the colour tells you what a cable is being used for, and animated dashes along a cable show which way the signal is travelling. Knobs are drawn consistently, with enhanced contrast, across every installed plugin.

The colours and the families are yours to set. A colour picker sets the four families, and you can change which family a port belongs to — by a rule that matches on the port’s name, or one port at a time from its own right-click menu. Several named colour sets and rule sets can be kept and switched between from the module’s menu. The rules live in a file you can edit, for anyone who wants to go further.

What it changes about how you work. Click a port to pick up a cable and click another to connect it. Dragging works exactly as it always has, so this is an addition rather than a replacement and you can use whichever suits the moment. Cable trace assist fades back everything except the cable you are following. Pinch to zoom on a trackpad. Pick up any of the cables on a port, or add another, without a modifier key. Note that I’ve only tested pinch-to-zoom on Apple trackpads. Feedback is welcome on how well it works on Windows or Linux.

Take as much or as little as you want. Each of these has its own button on Clarity’s panel, so you can switch on the ones that suit you and leave the rest off. It is not all or nothing.

Why it exists. I built it for myself. Three or four years ago I gave up using Rack — an eye problem I developed made faceplates hard for me to read and cables hard to follow across a patch, and it stopped being worth the effort. I was wishing I could return to VCV so I invented the features of Clarity and figured out how to put them in a plug-in :slight_smile:

Most of what came out of that turns out to help anyone, though — whatever a rack doesn’t cost you to read is attention left over for the patch itself. Two groups will probably get the most from it: anyone whose eyesight is less than perfect, and anyone patching on a trackpad rather than a mouse, since click-to-connect and pinch-to-zoom were both written with trackpads in mind.

Getting it. Clarity is not in the VCV Library yet. It has been out for testing while people put it through its paces, and now that it has been through that it will be submitted shortly. In the meantime, built packages for macOS (Apple Silicon and Intel), Windows and Linux:

The manual: DreamerDevelopment/docs/clarity.md at main · chrisgr99/DreamerDevelopment · GitHub

Source: GitHub - chrisgr99/DreamerDevelopment · GitHub — GPL-3.0-or-later.

Clarity ships in the Dreamer Development plugin alongside Test Gear, sixteen test tools that clip onto any port, announced separately.

Bug reports and feature requests are welcome. The development thread is the place for them:

Thanks to everyone who has already tested it and reported back — several of the things described above came out of that thread.

8 Likes

Unusable for me on linux. Mentioned this before, totally ignored.

Your report was not ignored. @chrisgr99 thought it had been resolved.

I saw a dramatic reduction in TestGear CPU usage in recent builds on Windows. Did you not see an improvement on Linux? Or have you not installed the latest version?

Apologies. Going through changes here…

Latest version.

@contemporaryinsanity — no apology needed, and thanks for staying with it.

If you’re on 2.0.5 and still seeing 11%, then it isn’t the bug I fixed and I’d like to find out what it is. How many modules are in the patch, and how many widgets do you have attached — that’s where the actual work happens. Would you also try a patch with just a few modules and see whether the reading drops? I don’t have a Linux system to test on, so I’m relying on what you can tell me.

Nothing in Test Gear should be expensive to run, so whatever this is, it’s a bug.

1 Like

Module count has no effect, uses 10% with zero widgets.

This concept is really cool!

Further, loaded Test Gear, created a widget, deleted Test Gear, widget still present. Is this expected behaviour?

Ah, yes.

If Test Gear is removed and there is not a Clarity present, then the widget(s) remain on the screen, though they are dysfunctional. I agree they should be removed.

If Clarity is present when Test Gear is removed, then the widgets are removed properly.

One other issue: Now that the number of available widgets has increased, the instruction text interferes with the “Monitor out” label.

1 Like

I think Clarity and Test Gear may be a bit too intertwined. Test Gear alone changes all the knobs like Clarity does.

1 Like

I saw that behavior a while ago, but hadn’t been able to reproduce it until recently.

I think if you never place a Clarity, then Test Gear will implement all the Clarity default GUI changes.

But once Clarity has been placed and then removed, then Test Gear no longer implements the Clarity features.

1 Like

DreamerDevelopment — latest releaseRelease v2.0.8 · chrisgr99/DreamerDevelopment · GitHub

Thanks for the reports — that was a productive few hours. Three of them are fixed:

The full changelog is in the module’s right-click menu.

@contemporaryinsanity — on the CPU reading.

Thanks for your help tracking this down. For some reason I can’t reproduce the high usage on my machine, so I’ve added a diagnostics window you can use to help isolate the cause: right-click Test Gear and choose “Show diagnostics”.

It shows what the module’s per-sample work costs, alongside what a pair of clock reads costs on its own. Rack brackets every module with such a pair in order to time it, so if those two figures are close, the meter is largely measuring itself. It also counts the widgets attached.

The switches take the work out a piece at a time. The first, “Whole process()”, stops the module doing anything at all, which takes its code out of the path entirely — so if Rack’s meter still reads high with that switched off, the cause is something passive about the module rather than anything it does. Most likely the seventeen hidden ports it adds, since even an inactive port may cost something per sample.

You’ve already said you had no widgets attached, so the per-widget switches won’t tell us anything about your case. They’re there so the cost of each kind of widget can be measured on its own, which will be useful later.

Open it, let the readings settle for a few seconds, and what would help is: the two figures, and what Rack’s meter shows before and after switching off “Whole process()”. Your Rack version, sample rate and block size too, if that’s easy.

Everything is restored when you close the window.

Anyone on any platform is welcome to run the same test and post their numbers. Mac and Windows readings are as useful as Linux ones — without them there’s nothing to compare a Linux figure against.

1 Like

Hi @chrisgr99, I’m using Debian Linux on Intel x64.

I got interested in the conversation about CPU usage, so I tried using DreamerDevelopment 2.0.7, but I can’t get VCV Rack to load the plugin. The log file says:

[0.329 warn src/plugin.cpp:203 loadPlugin] Could not load plugin /home/don/.local/share/Rack2/plugins-lin-x64/DreamerDevelopment: Failed to load library /home/don/.local/share/Rack2/plugins-lin-x64/DreamerDevelopment/plugin.so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32’ not found (required by /home/don/.local/share/Rack2/plugins-lin-x64/DreamerDevelopment/plugin.so)

Here is the whole log file in case that matters:

log.txt (67.1 KB)

Please let me know if I can provide more info from my system. I would love to help test.

Crash on exit — fixed in the latest release (2.0.8)

If Test Gear is in your rack and you’ve opened the module browser at any point, VCV Rack crashes when you quit. Please update.

No work is lost when it happens — the crash is on the way out, after the patch has been saved. The fault was in Test Gear’s own clean-up code when the module is destroyed.

Apologies to anyone who ran into it. It came in with one of today’s earlier releases.

@cosinekitty — thank you, that log is exactly what I needed.

The plugin is linked against a newer glibc than Debian provides, so it can’t load on your system. That’s my build environment rather than anything in the code. I build with GitHub Actions, and it’s choosing what to build against. I’ll look into whether I can point it at the version VCV builds with. If I can’t, then Linux will have to wait until the plugin is in the VCV Library, since they build it against the right one.

In the meantime, building from source would sidestep it entirely, if that would work for you: GitHub - chrisgr99/DreamerDevelopment · GitHub — GPL-3.0-or-later, needing the Rack SDK and a C++11 compiler. Same goes for anyone else on Linux who builds their own.

Either way, I’d like to take you up on the offer to test.

1 Like

Building it myself did the trick…

The visual effects with ports and cables appear to be working correctly. I don’t see any issues with CPU usage out of the box.

Oh yeah, for this part, take a look at my yml script for the Sapphire plugin. The Linux plugin it builds works fine on my own Linux system. It is based on the one in this thread that most VCV developers are using. This is actively maintained tribal knowledge! :laughing:

@cosinekitty — that’s a great help on both counts. I’ll reconfigure my GitHub Actions build to use that, and thanks for pointing at the thread behind it too.

Your reading is also the first from Linux showing no CPU problem, which is useful in itself — it puts the 10% down to something particular rather than Linux in general. Good to hear the ports and cables behave properly there as well.

1 Like

More accurate automatic colour classification for ports and cables

Clarity chooses port and cable colours automatically, from rules based on the port’s name. When a name matches none of the rules, the port is treated as audio, which may be wrong — a level input may be coloured the same as the signal it scales. Many port names match nothing, and those ports are coloured as audio.

I’m replacing that with a scheme that uses more than the name alone, and a fallback that leaves a port uncoloured instead of assuming audio. I plan to run the rules across every port name in my installed library, over a thousand modules, to find which names match nothing and which match the wrong family.

I’ll release a version with the improvements as soon as they are ready.

Clarity discussion has moved to Dreamer Development, which covers Clarity, Test Gear, Dark, Help and MPX in one thread: Dreamer Development: Clarity, Test Gear, Dark, Help and MPX (latest: Help 2.0.1)

Please post Clarity feedback, questions and bug reports there from now on.