Re: Updates to emms-mpris: please test!

[Fran Burstall (Gmail)]

Nice work.  I am going to be travelling for a couple of weeks but will fold all this into emms-mpris on my return.

---Fran

On Thu, 2 Mar 2023 at 18:10, Yoni Rabkin <yoni@rabkins.net> wrote:

Yoni Rabkin <yoni@rabkins.net> writes:

> 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,

amixer getter function implemented. We now also determine the correct
getter function on the fly to avoid getting the volume from one command
line and setting it using another.

This is a real concern, seeing as how amixer, pactl, and mpc can all be
present on a system simultaneously.

Also, note the arbitraty limitation to the range [0-100]. We are going
to ignore over-amplification settings as a rule. If anyone complains, we
can add an exception.

> then finally for mpd.

this is next.

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