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