Re: Updates to emms-mpris: please test!

[Yoni Rabkin]

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

-- 
   "Cut your own wood and it will warm you twice"