Re: Updates to emms-mpris: please test!

[Yoni Rabkin]

Yoni Rabkin <yoni@rabkins.net> writes:

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