Posts

Disabling the obnoxious lights on the Evoluent Vertical Mouse 4

I've been a fan of the Vertical Mouse for a while now, since the extreme wrist pronation of a conventional horizontal mouse aggravates my wrist. Unfortunately, however, Evoluent saw fit to put a blindingly bright blue lit-up logo on the back of the latest version (much to the delight of absolutely nobody in their target market). This is particularly problematic if you work late or sleep in the same room as your computer (blue light messes with your sleep cycle, hence tools like Redshift).

The offending logo (unlit).

After unplugging my mouse every night for so long, I finally decided to tear the thing apart and see how easy it would be to disable those lights. It turns out this is very easy, you don't even need to desolder anything. There are four screw holes hidden under the label and front pad on the bottom. You don't need to remove the other two pads like I did in the process of figuring this out.

Screw hole locations.

Remove all four screws and the top should come off easily. There are ribbon cables connecting the buttons, though, so don't pull too hard. Now you can see the battery of LEDS.

The seven (!) offending LEDs. When Evoluent shoots for annoying they go full out.

Luckily, this pointless board is connected with a header, so you can simply unplug it, and reassemble the mouse.

Disconnected LED board connector.

Much better.

Edit 2020-08-16: Several people have let me know that there is a less destructive way to do this. Apparently, if you hold the pointer speed "-" button while plugging the mouse in, the light will be disabled. I am not sure if this works for all revisions, though, and have not tested it myself.

Pretty names in Patchage via Jack Metadata

The much-awaited (by me, at least) Jack metadata API has arrived. This will allow us to easily achieve many new things with minimal/nonexistent API friction. One of the simplest and most obvious is pretty names for Jack clients and ports, so I've chosen this as the first thing to tackle (as part of a drive to get Patchage polished up for a much overdue release).

Unfortunately, as far as I can tell, there is a chicken & egg scenario here since nothing is setting this metadata yet. So, I've made Jalv and Ingen both set pretty names for their ports. In the case of Jalv, the "pretty name" is the label given in the plugin data (distinct from the LV2 "symbol" which is restricted and unique).

Firing up Jalv with the Tal Dub III plugin (LV2 port courtesy KXStudio), we can see the port symbols, which are a bit awkward for end users with their prefixes and underscores. Conflating strong identifiers with human-readable labels is a serious design error I learned of the hard way, but that's a discussion for another time...

Enable "Human Names" in the view menu, or press C-h, and voilà, we see the pretty names set in Jack metadata (if present) instead.

Tal Dub III in Jalv as shown by Patchage with human names off.

Tal Dub III in Jalv as shown by Patchage with human names enabled.

The metadata API is very simple to use for ports, though there seems to be a hole in the API which makes it difficult to get the UUID for your client to set metadata (I want a simple jack_client_uuid, like jack_port_uuid, but it seems you have to get a string UUID and parse it to a jack_uuid_t, clunky enough that I just didn't bother). In any case, I am happy to see a low-friction mechanism in Jack which apps can use to share metadata towards making a better user experience.

It will be interesting to see what sort of information proves useful and becomes established/standard. For those of us of a mad scientist bent who live in a nest of patch cables, a CV tag seems like another obvious simple step, but for everyone, a big step is finally having meaningful port grouping and channel roles. I have always liked to joke that Jack (like LADSPA) doesn't really even do stereo, but with metadata, we can mark up stereo, 5.1, Ambisonics, etc., and other clients will be able to make sense of the channel assignments without resorting to dirty kludges based on guessing from names. All without changing the ABI one bit. Good stuff.

Labeled MIDI controller values in Ardour

A while ago, I implemented MIDI patch, controller, and note name support for Ardour.

There was one thing missing from that work: labelled controller values. This is particularly useful for controllers that don't represent a continuous numeric parameter, but instead have a set of specific values. For example, the Moog Minitaur supports CC #86 to control the LFO sync clock division, but it's not obvious how a 0-127 number maps to a clock division. From the manual, we can learn that 61-67 is "1/4", 68-73 is "1/8 Dot", and so on.

Translate that information into standard MIDINameDocument format, and a few hours of hacking later... voila, Ardour displays something sensible when hovering over an automation point instead of a meaningless number.

Ardour displaying a labelled MIDI controller value when hovering over an automation point.

If you want to add support for your MIDI device or program, my .midnam documents for the Moog Minitaur, MF-104M, and MF-108M, included in the Ardour distribution all contain examples of labelled values. It should be relatively obvious how to copy and modify these for other devices.

MDA.lv2 1.2.2

MDA.lv2 1.2.2 has been released. This is a port of the MDA VST plugins to LV2.

Changes:

  • Fix compilation against LV2 < 1.8.0

BLOP.LV2 1.0.0

BLOP.LV2 1.0.0 has been released. BLOP.lv2 is a port of the BLOP LADSPA plugins by Mike Rawes to LV2.

MDA.lv2 1.2.0

MDA.lv2 1.2.0 has been released. This is a port of the MDA VST plugins to LV2.

Changes:

  • Fix const-violating casts
  • Fix tuning of Piano and EPiano at sample rates other than 44.1 kHz

Jalv 1.4.4

Jalv 1.4.4 has been released. Jalv is a simple but fully featured LV2 host for Jack which exposes plugin ports to Jack, essentially making any LV2 plugin function as a Jack application. For more information, see http://drobilla.net/software/jalv.

Changes:

  • Add --no-menu option for jalv.gtk
  • Add -c option for setting controls from the command line
  • Don't expose non-MIDI event ports to Jack
  • Hide controls for ports with notOnGUI property in generic UI (based on patch from Robin Gareus)
  • Preset menu support for Qt (patch from Timo Westkämper)
  • Support ui:portMap feature to allow UIs to avoid hard-coded port indices (useful for compatibility and separately distributed UIs)

Sratom 0.4.4

Sratom 0.4.4 has been released. Sratom is a small library for serialising LV2 atoms to and from RDF, for converting between binary and text or storing in a model. For more information, see http://drobilla.net/software/sratom.

Changes:

  • Escape invalid characters when writing paths as URIs
  • Fancier printing without subject and predicate

Lilv 0.18.0

Lilv 0.18.0 has been released. Lilv is a C library to make the use of LV2 plugins as simple as possible for applications. For more information, see http://drobilla.net/software/lilv.

Changes:

  • Add lilv_port_get_node() for using world query functions with ports
  • Add support for running plugins from Python by Kaspar Emanuel
  • Allow lilv_state_restore() to be used without passing an instance, for restoring port values via a callback only
  • Allow passing NULL port_class to lilv_plugin_get_port_by_designation
  • Call GetProcAddress with correct calling convention on Windows
  • Clean up after test suite so multiple runs are successful
  • Fix unlikely memory leak in lilv_plugin_instantiate()
  • Support denoting latency ports with lv2:designation lv2:latency
  • lilvmm.hpp: Add wrappers for UI API
  • lv2info: Don't display invalid control maxes and defaults (patch from Robin Gareus)

Suil 0.8.0

Suil 0.8.0 has been released. Suil is a library for loading and wrapping LV2 plugin UIs. For more information, see http://drobilla.net/software/suil.

Changes:

  • Add suil_instance_get_handle (patch from Rui Nuno Capela)
  • Fix compilation errors on some systems
  • Upgrade to waf 1.7.14

« Page 13 / 22 »