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 <[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"
>

Reply via email to