Re: Updates to emms-mpris: please test!

"Fran Burstall (Gmail)" <[email protected]> writes:

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

It's now all in the main branch.

I'm not 100% sure it makes a lot of sense to link mpris and mpd via
emms, nor does it make a lot of sense to me to change the local volume
through mpc.


> On Thu, 2 Mar 2023 at 18:10, Yoni Rabkin <[email protected]> wrote:
>
>> Yoni Rabkin <[email protected]> writes:
>>
>> > Yoni Rabkin <[email protected]> writes:
>> >
>> >> "Fran Burstall (Gmail)" <[email protected]> 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 <[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"
>> >>>>
>>
>> --
>>    "Cut your own wood and it will warm you twice"
>>

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