Re: Updates to emms-mpris: please test!

[Fran Burstall (Gmail)]

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.

---Fran

On Mon, 6 Feb 2023 at 15:03, Yoni Rabkin <yoni@rabkins.net> wrote:

"Fran Burstall (Gmail)" <fran.burstall@gmail.com> 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"