"Fran Burstall (Gmail)" <[email protected]> writes: > emms-mpris changes pushed to main. > > Feel free to specify a unifying format.
Apologies for absence. Life is getting in the way of devoting time to Emms development. I'll be back on this Real Soon Now(TM). > > 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. > > ---Fran > > > > > > 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"
