VolumeController plugin
I'm trying to make a volume controller for linux very similar to the elgato one. Continuing the discussion from general here.
25 Replies
I'll respond to @nekename 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 itI 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 itIs 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?) 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:
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 methodHello!
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
Awesome! Thank you for your response! If time is on my side, I’ll try to look into extending that
@Zoe @ryncops this is what you'd be looking for right?
oh this is exactly what im looking for
this feature is what i used the absolute most with my windows install
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 boxyou can increase / decrease STEP var in the text box as desired
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
GitHub
GitHub - krruzic/pulsectl: Easy to use Rust PulseAudio API
Easy to use Rust PulseAudio API. Contribute to krruzic/pulsectl development by creating an account on GitHub.
hey, very cool!!
couldn't u just let the user fill the profile with your buttons manually?
like this plugin: https://github.com/JavanPoirier/AudioMixer
GitHub
GitHub - JavanPoirier/AudioMixer
Contribute to JavanPoirier/AudioMixer development by creating an account on GitHub.
take a look at 1:30 in the tutorial video, the Application Placeholder buttons double as volume controls
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
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)
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
new OpenAction crate version keeps track of all visible actions for you btw
cool, cool! will check!
Awesome changes with the new crate version @nekename , 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.
awesome!
this is looking so cool
yk in my analytics, at least a third of plugin installs are for audio plugins that don't work
This is one I would love to use!
I'm glad, I'm pretty stoked about it too! 😆