VolumeController plugin

[jovial wadi]

I'm trying to make a volume controller for linux very similar to the elgato one. Continuing the discussion from general here.

[jovial wadi]

I'll respond to @maiden path messages here, pulled from general

You can't use switchProfile
after all, in the Starter Pack source it does say '// Non-spec OpenDeck-specific protocols are used in this file.'
why would you need that to make audio actions?
it's restricted to the starter pack (and the streamcontroller plugin i guess) because they have uses for it, but regular action plugins dont have it

I see now, I saw the comment but thought it just meant there is no API method (yet) for profile switching similar to how you have set_title or set_image on the OutboundEventManager. It did make me wonder why there was no such API method tbh 😆

but regular action plugins dont have it

Is this the only reason? I think that this is a bit limiting for plugin development, you can probably do more cool stuff with it. For example the elgato volume controller uses it quite a bit from what I gathered looking through wtv files I could and deducing how it was built:

• you have this auto config button which seems to infer what SD you have and then switch to one predefined profile. Their plugin code contains 3 such profiles, one for the SD, the SD XL and SD+. Their manifest also contains refs to these profiles (which is another thing I think the opensource API doesn't understand for now?)

  "Profiles": [
     {
       "Name": "Volume Controller (Auto)",
       "DeviceType": 0,
       "Readonly": true,
       "DontAutoSwitchWhenInstalled": true,
       "AutoInstall": false
     },
   ...

These profiles seem to be built with actions that are hidden from the user in the GUI, through this manifest property VisibleInActionsList. So for example, and this is me assuming this is how the original controller works, pressing the auto config switches to some profile that has some static actions set (like a go back btn) and then sets the rest of the grid to some placeholder actions that the plugin code later sets, placeholder action probably being this:

{
      "Icon": "blank",
      "Name": "-",
      "States": [
        {
          "Image": "blank"
        }
      ],
      "UUID": "volume-controller.auto-detection.blank",
      "VisibleInActionsList": false,
      "UserTitleEnabled": false,
      "PropertyInspectorPath": "pi/application/auto-detection/inspector.html",
      "SupportedInMultiActions": false
    },

and these get dynamically set based on what apps are running and what volume settings they each have

Alas, this is nothing that cannot be avoided, I can manually build the profile in the gui with the placeholder actions and then my plugin can take over, so nothing that blocks the plugin itself. Just a bit more manual processing when setting up the plugin (unless I'm missing something)

I was just wondering if this would be something you'd want to extend in the future (allowing profile switching, adding profiles in plugins, new actions props like VisibleInActionsList)? I'm not sure what the effort is tho.

But I went too far nonetheless, the main question is if you would consider allowing switchProfile as an API method

[maiden path]

Hello!

yeah, I know about ESD's support for pre-defined plugin profiles, and the VisibleInActionsList property

the reason that there is no switch profile event available to plugins yet is because there is no support for the pre-defined profiles

and it doesn't make sense for plugins to be able to switch to user-created profiles (which are the only ones supported right now)

if you wanted to look into adding support for profiles defined by plugins then by all means go ahead

[jovial wadi]

Awesome! Thank you for your response! If time is on my side, I’ll try to look into extending that

[maiden path]

@compact pebble @jovial wadi this is what you'd be looking for right?

[compact pebble]

oh this is exactly what im looking for

this feature is what i used the absolute most with my windows install

[compact pebble]

heres my current solution

• logged in as your user, run: nano ~/.local/bin/app-volume-ticks.sh & paste the script, or just download the file i sent
• after saving: chmod +x ~/.local/bin/app-volume-ticks.sh
• paste STEP=1 ~/.local/bin/app-volume.sh %d into the "Dial rotate" text box

you can increase / decrease STEP var in the text box as desired

[jovial wadi]

hey! nice, looks like you have the SD with dials, would be great to have help on that with dev and testing since I only have the 3x5

I've made some progress on the plugin, still needs polishing tho, code is still local will try to push to github when I get some time

but basically works pretty decently, mimics the auto setup on the original elgato plugin, although there is quite a bit of configuration for it :/ first off, I'm using a modified OpenDeck that allows me to send profile switch events

then I have this hand made Sound profile which is basically black placeholder btns that get overriden by the plugin. everything is dynamic, so when a new sound app starts the SD picks it up and shows it, theres an event listener in the plugin.

so ideally plugin profiles are also added to openDeck, it's something that I'll try to look into later on after getting this plugin into a usable state

also it's currently working with pulse audio only, using pulsectl just cuz my distro is using pulse and this crate was there and ready to use. I wanted to get the plugin working asap for me. audio systems are abstracted tho so it should be easy to just plug in pipewire. I'll look into that as well after getting the plugin in a decent state

[maiden path]

hey, very cool!!

[maiden path]

couldn't u just let the user fill the profile with your buttons manually?

like this plugin: https://github.com/JavanPoirier/AudioMixer

take a look at 1:30 in the tutorial video, the Application Placeholder buttons double as volume controls

[jovial wadi]

Oh yeah for sure, thats what i do now. But this would come with instructions like: you must have a profile named Sound where each btn has id X. So folks would need to do some manual preparation on install in lack of plugin profiles.

Ill check the video too see what they do there

[maiden path]

why does it have to be called Sound and why do they need specific IDs?

can't you just keep track of all the buttons they added (all the willAppear events you receive)

[jovial wadi]

good point yeah, I've thought about this more and I'll change my approach to not use the switch profile event. I would've liked to get the functionality very close to elgatos, but I think I'm obsessing a bit at this point. I'm gunna refactor some things

[maiden path]

new OpenAction crate version keeps track of all visible actions for you btw

[jovial wadi]

cool, cool! will check!

[jovial wadi]

Awesome changes with the new crate version @maiden path , thank you! Been a pleasant experience migrating and having visible actions tracked, made my plugin code quite cleaner, very happy with how it's shaping: managed to refactor a bunch of stuff with this migration, ditched the switch profile events and using the inbuilt action. Just a bit of cleanup and polishing needed at this point.

[maiden path]

awesome!

[jovial wadi]

got dynamic icons as well using tux-icons crate, gonna style the bars a bit too next

[maiden path]

this is looking so cool

yk in my analytics, at least a third of plugin installs are for audio plugins that don't work

[maiden sun]

This is one I would love to use!

[jovial wadi]

I'm glad, I'm pretty stoked about it too! 😆