FR: Add support for more multimedia keys

I’ve been trying to use JUCE for a general media app and found myself stuck when trying to configure an assortment of input shortcuts. This is particularly off-putting because I need to use a remote control for the app on an embedded device.

To summarise the missing media key input functionality:

  • pause (Note that this is different than the play/pause key)
  • stop
  • volume up
  • volume down
  • mute
  • record
  • channel up
  • channel down
  • find/search
  • help

For Windows:

  • VK_PAUSE + APPCOMMAND_MEDIA_PAUSE
  • VK_MEDIA_STOP + APPCOMMAND_MEDIA_STOP
  • VK_VOLUME_DOWN + APPCOMMAND_VOLUME_DOWN
  • VK_VOLUME_UP + APPCOMMAND_VOLUME_UP
  • VK_VOLUME_MUTE + APPCOMMAND_VOLUME_MUTE
  • APPCOMMAND_MEDIA_CHANNEL_UP
  • APPCOMMAND_MEDIA_CHANNEL_DOWN
  • APPCOMMAND_FIND
  • VK_HELP + APPCOMMAND_HELP

In terms of Linux’s input events (which JUCE doesn’t apparently use, unless I’m confused? See https://github.com/torvalds/linux/blob/master/include/uapi/linux/input-event-codes.h ):

  • KEY_PAUSE
  • KEY_STOP
  • KEY_VOLUMEUP
  • KEY_VOLUMEDOWN
  • KEY_MUTE
  • KEY_RECORD
  • KEY_CHANNELUP
  • KEY_CHANNELDOWN
  • KEY_FIND
  • KEY_HELP

Some investigations have found this for Linux/X11, but it’s incomplete in terms of media keys: XF86keysym.h - xorg/proto/x11proto - X.org X11Proto protocol headers. (mirrored from https://gitlab.freedesktop.org/xorg/proto/xproto)

  • XF86XK_AudioPause
  • XF86XK_AudioStop
  • XF86XK_AudioRaiseVolume
  • XF86XK_AudioLowerVolume
  • XF86XK_AudioMute
  • XF86XK_AudioRecord

For macOS, this is what I could conjure up:

  • NSPauseFunctionKey
  • NSStopFunctionKey
  • NSPauseFunctionKey
  • NSFindFunctionKey
  • NSHelpFunctionKey

Note: it looks like macOS idiotically controls volume up/down/mute at a lower level. See: Function-Key Unicode Values | Apple Developer Documentation

Note that some function keys are handled at a lower level and are never seen by your app. They include the Volume Up key, Volume Down key, Volume Mute key, Eject key, and Function key found on many computers.


For Android:

  • KEYCODE_MEDIA_PAUSE
  • KEYCODE_MEDIA_STOP
  • KEYCODE_VOLUME_UP
  • KEYCODE_VOLUME_DOWN
  • KEYCODE_VOLUME_MUTE
  • KEYCODE_MEDIA_RECORD
  • KEYCODE_CHANNEL_UP
  • KEYCODE_CHANNEL_DOWN
  • KEYCODE_SEARCH
  • KEYCODE_HELP

Possibly related to this, I’ve noticed that JUCE-based apps on Windows prevent global media hotkeys from working correctly when they have focus. For example, if I have a music player minimized, the player responds to media key presses correctly when other apps have focus, unless they are JUCE apps (observed with Projucer, DemoRunner, and my own apps).

I haven’t had the time yet to do any debugging and I’m on a laptop without media keys at the moment, so I’m not sure if this is really related to the FR or if it’s a separate issue.

My votes are stuck in old Feature Requests, but this would be great!
(I cannot even like it, because the likes in this category would be a vote).

I wonder if the buttons will also work when the screen is off while the app is running…
Makes perfect sense, but I experienced they don’t always reliably do in some player apps.

I did a POC of these various new keys in a branch on my github and found a few OS specific oddities.

First, it looks like most OSs use window focus to process input; if your app isn’t in the foreground, it’s unlikely to receive input.

WRT to the media keys, each OS handles this differently.

On Windows, the volume up/down keys are likely to be eaten by Windows if your app isn’t in focus and isn’t intercepting the VK keys.

On macOS, it’s a completely different story: it forcibly passes all media keys (play, pause, stop, track prev/next) keys to iTunes, and the volume up/down to the OS itself… which is pretty bogus. But, if you have a media app that takes focus, like Spotify, it may get the chance to interpret the media keys. I’d be curious to know if TVOS and iOS have a similar configuration…

1 Like

And you can’t keep it from handling the keys, no matter if you return true or false, maybe we need to find another place in the chain

There isn’t one. I looked! The volume up/down keys are also specially handled by Windows.

Are you sure this is the case? I am using Tidal and the media keys work fine in macOS when the program is minimised, and pretty sure Spotify was the same when I was using that before, I have never used iTunes.

My gut instinct would be that there is some API in macOS to register oneself as a music player, in order to hook into this menu bar item that normally shows Music (the app formerly known as iTunes) related shit:

image

and then likely also be informed about media key presses. But this is pure speculation.

To be honest, I’ve only tested this on Catalina and didn’t investigate much more deeply once I noticed this. There’s nothing obvious and clearly laid out by Apple on this topic. For all I know there could be app settings like changing the category or something that could coax macOS into piping the inputs consistently, or - like you mention - whatever hidden API hackery lurking.

I’m using “Squeezer”, a controller app for squeezebox / logitech clients.
It uses the volume rocker pretty reliably - even with screen off.

Since it’s open source, we can have a glance at line ~327:

Maybe it’s a hint for devs, at least for the android-level?
Doesn’t look so heavy though…

merp
I was hoping for some progress in juce7, but still no luck.
How come no audio app wants to use the hardware volume buttons?
If I were new to juce I’d definitely expect this working…