Yoni Rabkin <[email protected]> writes: > "Fran Burstall (Gmail)" <[email protected]> writes: > >> emms-mpris changes pushed to main. >> >> Feel free to specify a unifying format. >> >> >> Well, the API exposed by emms-volume.el is via emms-volume-*-change which >> changes the volume by AMOUNT (a number). What would be nice to know is >> what the number being changed is! I would like it to be an integer between >> 0 (mute) and 100 (maximum volume). >> >> The pulseaudio controller provides this already via >> emms-volume--pulse-get-volume. None of the others do and I have no insight >> as to whether "volume as a number between 0 and 100" even makes sense for >> the underlying backends. >> >> As far as emms-mpris is concerned, it would be wonderful if emms-volume.el >> exposed a function emms-volume-get-volume which returned this putative >> number. > > There is now a "volume" branch: > https://git.savannah.gnu.org/cgit/emms.git/log/?h=volume > > I'll toss some changes into that which we can discuss.
Now `emms-volume-get' is defined in emms-volume.el in the "volume" branch for pulseaudio (instead of "emms-volume-get-volume"). Next I'll see how easy/hard/impossible it is to implement when we drop down from pulseaudio to alsa, then finally for mpd. >> On Mon, 6 Feb 2023 at 15:03, Yoni Rabkin <[email protected]> wrote: >> >>> "Fran Burstall (Gmail)" <[email protected]> writes: >>> >>> > I have pushed a new version of emms-mpris.el to the mpris branch. >>> >>> Thank you for this work. >>> >>> I see no reason though not to simply push this to main. Unless your work >>> is highly experimental, or there is another compelling reason, please go >>> ahead and do the development of mpris in main where everyone can get >>> those updates easily. >>> >>> Anyone who is running Emms off of the main git repo needs to be OK with >>> living on the bleeding edge. >>> >>> > What's new: >>> > * Support changing LoopStatus and Shuffle properties >>> > * Fix a couple of problems with the artUrl field of the Metadata >>> property. >>> > >>> > Many mpris controllers do not support LoopStatus and Shuffle (playerctl >>> is >>> > an honourable exception) but if you have access to a controller that does >>> > support this, it would be great to have some testing! >>> > >>> > The only thing in the mpris spec that is left for implementation is >>> > changing the volume. The issue here is that every volume backend reports >>> > the volume in a different way, sigh. So there would have to be some >>> > unifying work on emms-volume-* first. Is there any appetite for this? >>> >>> emms-volume-* unifying work should be done in a separate branch unless >>> there is a way of working on that without destabilizing main too much. >>> >>> Feel free to specify a unifying format. >>> >>> I think that different people can work on different backends, based on >>> what they have on their machines. I have pulseaudio running on this >>> machine (a bog-standard Trisquel 10.0.1 install). So I could do that >>> once we have a unifying format to work to. >>> >>> -- >>> "Cut your own wood and it will warm you twice" >>> -- "Cut your own wood and it will warm you twice"
