Deckyard - 0.2.0 Released

Changes

This release introduces support for a new device, new data sources, and significant UI and UX overhauls!

Mirabox N4 Pro support

In my continued quest to support as many Mirabox-class devices as possible, I have now added support for the Mirabox N4 Pro. This is a device which has 10 buttons, a touchscreen, and 4 rotary encoders which also have LED rings.

The touchscreen has been split into 4 separate tap zones for now, but may be adjusted or customisable number in future. Swipe gestures are also supported.

The vibration/haptic feedback control can be enabled or disabled - the vibration happens when you press a button or the touchscreen, and it's not something we can trigger, so unfortunately no way to make it buzz in response to some arbitrary condition.

All the encoder LED rings can be customised, including with support for rules. For example, you might want to display the current audio clipping state for an OBS audio source as an LED colour, or displaying colour and/or brightness of a home-assistant light.

New data sources

Deckyard now includes support for a number of new data sources:

• OBS source level (i.e. an audio source live meter)
• OBS source volume (i.e. an audio source fader position)
• System audio (volume level, muted on/off)

These can be used as data sources and as output (e.g. tags in labels, LED colour, etc).

UI and UX overhaul

This has been on my to-do list for a while.

In the action manager panel that's docked at the right-side of the UI, managing state, conditional rules, and everything else was becoming a bit overwhelming and cramped in some parts, so I've overhauled it entirely. Instead of a single long scrollable list, it is now split into 'look', 'behaviour', and 'advanced' tabs. Rule list and editing now splits out into a modal for easier overview instead of being cramped into one thin area.

In the central area, the device controls now live to the right-side of the keypad UI, but will wrap underneath if the UI isn't wide enough.

Many of the verbose description labels have been removed because they were unnecessary.

Version 0.2.0 can be found via the website, accessible through the Deckyard project page.

Upcoming plans

The below are subject to change or cancellation, but represent features I hope to include in a future release:

MacOS support

I know I mention this every time. It's still on the list, it's just a case of finding time and prioritising amongst other things.

Manual device support

Currently, only devices which I've actually tested are known to be supported. This covers major use-cases, but it's no use for people who don't have one of those devices.

With that in mind, I am proposing a calibration tool and designer. Essentially, this would allow you to select certain elements - e.g. buttons, dials, display, touchscreen, etc - and create a layout from them.

For example, you might say 'I have 2 rows of 5 buttons each at the top, then a touchscreen underneath, then 4 dials, but it's not on the known devices list'.

Live screen buttons

This feature is one which would perhaps be most useful for gamers. For example, let's say you have an ability in World of Warcraft which has a static cooldown, but you have talents which can 'reset' or reduce the cooldown by an amount. Currently, Deckyard has no way of knowing about this, so while it can display set-duration countdowns, it can't display dynamically adjusting ones.

What this proposal is for a near-live view of a section of the screen, cropping a specific area. For example, you might decide to crop in on a specific ability cooldown button. This would update potentially once every second, or maybe 2-3 times per second. It would not perform any inferrence of the content - i.e. it wouldn't know that a cooldown from the screen says e.g. 12 seconds - so it wouldn't be possible to hook it into the static timers or act as data-driven source, but it would potentially be more useful over the existing static countdown feature we have.

There are performance implications for this feature, especially with multiple cropped areas for different buttons. There are also privacy and security implications, and compatibility could be kind of complicated if we decide to tap into games (e.g. different APIs, anti-cheat, etc).