Emacs MultiMedia System (EMMS)

Yoni Rabkin - IRC: yrk

Format: 39-min talk; Q&A: BigBlueButton conference room
Status: Q&A to be extracted from the room recordings

Talk

00:00.000 Introduction
01:03.320 The structure of this talk
01:21.320 Introduction to Emms: The practical part
08:04.240 The modeline
11:01.200 Meta-playlist mode
11:29.860 The browser
13:19.920 How Emms works: The technical part
16:23.820 The Emms core
16:36.440 Tracks
17:18.460 Playlist
18:22.080 Sources
19:22.160 Players
20:20.520 Info
21:36.660 The cache
22:51.620 Healthy back and forth: mpv, mpd, and GNU.FM
23:31.560 MPV
24:47.470 MPD
26:07.440 GNU FM and Libre FM
27:12.560 How we work: Emms development
28:52.590 The Rime Of The Ancient Maintainer
29:06.080 The life and times of an Emms patch
31:24.080 Let It Go: The release process
32:23.400 It Is Not In Our Stars, But In Ourselves: Future directions
34:44.849 Development policies: Interface language
36:05.980 Development policies: Freedom
38:12.370 Acknowledgements

Q&A

Description

• Introduction to Emms: A Practical Introduction
• How Emms Works: The Technical Part
• How We Work: Emms Development

Discussion

Questions and answers

• Q: To warm up, what is the music playing during the lunch break?
  • A:(zaeph) Album: basement days  by shoshin (Grant Shangreaux) ❤️
    • https://cicadas.surf/~shoshin/casiopeia/basement%20days/
• Q: For next emacsconf, could we have an EMMS playlist to follow the talks along? 
  • A:
• Q:I I like to use Music and AudioBooks in very different ways. With music I like shuffling by artist and with AudioBooks want to read sequentially and pick it the same playlist over a couple of days/weeks. Do you have any tips for using these 2 opposing media workflows
  • A:
  • Q: For audiobooks I use mpv with m4b files
• Q: Is there a way to search your music selection by lyrics-- assuming those lyrics are in the meta-data or available elsewhere. It would be neat to call songs up from the lyrics to the song.
  • A: For the lyrics: not possible to do right now.  The caching system is extremely naïve.  Now, with sqlite3 integration, we need to expand the cache to be a lot more greedy and lot more flexible.  The rewrite is in progress, and any related information (including lyrics) will be integrated.
• Q: Are aliases available for the songs that you like? Defining those aliases or shortcuts either inside or outside emms? ;;BTW: melpa version of emms is missing; however, I was able to install from elpa. 
  • A: We'll put a pin on this
• Q:Are there plans for managing meta-data with online resource backends; i.e. discogs or musicbrains? What about something like Beets in Emacs or part of EMMS?
  • A: That's an active discussion on the mailing-list right now.  We don't want to replicate what Beets does really well, and we don't want a clunky interface with Beets.  It's hard to tell where to draw the line.  Short answer: yes, we want to do that, but the long answer is that it's complicated.  The backends that are used are complicated.
• Q: Have the developers considered using Emacs' "Customize" functionality to persistently store settings when using emms-setup-discover-players? 
  • A: Another active project, especially with -discover-players.  It's tough to figure out what is a good way to not annoy people too much.
• Q: Is there a way to store a bookmark pointing to a song in a playlist?
  • A:
• Q: I like what you said about balancing the concern for software freedom with the worry that this might alienate the package user. I was wondering if you have advice for other maintainers on how to communicate this sort of thing diplomatically, when you have to deny implementing a feature for a "freedom" reason.
  • A:I found that people appreciate knowing where the project stands. But care needs to be taken to be descriptive and not perscriptive; explain why your project is like that as opposed to making them feel judged. Some people are ornery and will get upset anyway, but that's a part of working within the public eye.

• Q: i wonder if it would be possible to add fluidsynth as a backend for emms to play midis

  • A: I can add a fluidsynth backend to the tasklist no problem. right now, emms-player-fluidsynth works, but only with basic play/stop/pause support. I assume you are looking for more features than that. emms-player-simple.el defines a few, appropriately named, simple interfaces to some midi players such as fluidsynth and timidity Notes:

• This guy has <chefs-kiss> taste in music, by the way. Take it from me, I'm a big snob

  • i like how it was a bunch of classical and then Tool
• Brilliant 👏
• Amazeballs 👏
• oh that's a good idea
• I just really enjoy seeing the folks that contribute to free software. They are truly people to emulate. That goes double for Yoni.
• someone on the pad mentioned there not being an EMMS package in MELPA, that is intentional, since EMMS is built into Emacs, and we have the newest version in ELPA

Transcript

[00:00:00.000] Introduction

The Sound of Emacs, Emms, The Emacs Multimedia System. Hi, I'm Yoni Rabkin and I'll be talking about Emms; the Emacs Multimedia System. What is Emms? Emms displays and plays media from within Emacs using a variety of external players and from different media sources. Emms can run as a minimalistic player which is controlled with no more than a handful of simple M-x commands, or as a fully-fledged interactive media browser and player. Emms can display album art, play streaming audio, tag music files, search for lyrics, provide MPD connectivity, control the volume, and more. Much more. The Emms project acts like Emacs in microcosm. It slowly but surely grows bigger and gets ever more features. Perhaps Emms will one day even have a text editor.

[00:01:03.320] The structure of this talk

The structure of this talk: We'll start with an introduction to Emms. This is the practical part. Then, a bit about how Emms works. That's the technical part. Finally, how we work. All about Emms development.

[00:01:21.320] Introduction to Emms: The practical part

Introduction to Emms: The practical part: I want this talk to be of immediate use to people, so I'm going to present a quick TL;DR of the Emms manual concerning installation and use. By the end of this part you should be able to install, configure, and use Emms in a variety of ways. Where can I get Emms? Emms is distributed primarily via GNU ELPA. So it's really only a M-x list-packages away at any moment. There's also a website hosted at gnu.org. Among other things on the website, you'll find a copy of the friendly, robust, and up-to-date user manual. Installing Emms has become progressively easier over time and will continue to get easier. In the bad old days, it required downloading a tarball and compiling a C language shim to enable reading metadata from media files. But those days are long gone, and installing Emms is now as easy as invoking M-x list-packages, installing the Emms package, and placing as few as 2 or 3 lines of configuration in your Emacs initialization. So after the package is installed via ELPA, you can add these few lines. emms-all will make available all of the stable features which are shipped with Emms. The emms-player-list variable is a list of players like MPV, MPlayer, VLC, etc. Emms will call and control these external players to play your media. The variable emms-info-functions is a list of ways for Emms to read the metadata in your media files so that Emms can display song title, artist name, year of production, etc. The emms-info-native feature in the setup example is the built-in metadata reader written entirely in Emacs Lisp. But there are also other backends which can call external programs for info such as TinyTag, the TagLib library, exiftool, and so on. You can then old-school restart your Emacs or simply evaluate the above couple of lines to get going. Now that we have Emms installed and configured, we should load some media for player. There are multiple ways to load media into Emms for playing. They can be directories with local files, synchronized from a remote instance of a music player daemon, PLS or M3U playlists, a list of URLs for streaming, or even Emms' own native playlist format which is unsurprisingly a just serialized Emacs Lisp. No matter how you add tracks to Emms, you'll end up with a playlist. A fundamental strength of Emms is that each playlist is a regular Emacs buffer and the track listing therein is nothing more than text lines with property overlays. This means that you can navigate, search, copy, and edit an Emms playlist buffer just as you would any Emacs buffer. If you want to reorganize the tracks in the playlist, then you can simply kill yank the tracks just as you would any buffer with lines of text, and the same can be done between multiple playlist buffers. One of the most straightforward ways to add media is to invoke a command like M-x emms-add-directory-tree. You can point it to the top of a set of directories with playable files for Emms to traverse. Another rather convenient method is to mark files in Dired and to invoke emms-add-dired. I definitely use this one a lot. The Emms playlist mode binds a number of useful keys and commands. It's highly recommended that you either read the friendly manual or hit "C-h m" in a playlist buffer to discover them. Now we have a playlist buffer with a number of tracks, so the next step is going to be playback. Emms can be used as a minimalistic player with nothing more than a handful of commands. Once there is a current Emms playlist, invoking emms-start will begin playing the current track. Now of course in a new playlist that would be the first track. Now emms-next, emms-pause, and emms-stop do exactly what you think they do. To visit the current playlist, you can invoke M-x emms-playlist-mode-go, which is a long command I personally bind to "M-f12". You'll be taken to the current playlist buffer. While you can have multiple playlist buffers, only one is current for the purposes of playback commands. The playlist buffer has keys bound to control the media being played. emms-seek-forward and emms-seek-backwards allow you to scrub along the media being played. Which commands are available is a function of the player backend being employed. The simplest of players may have nothing more than the ability to play, stop, and seek, but others may implement a plethora of commands.

[00:08:04.240] The modeline

The Modeline: Emms will by default display the name of the currently playing track in the mode line with information such as playing time. The mode line format is controlled via the emms-mode-line-format variable and the emms-mode-line-playlist-current function. Metadata and the cache. It would be sufficient for emms to simply list the file names or urls of each piece of media, but unless you name your music and media with obsessive consistency and precision, not that there is anything wrong with that then the resulting list will be a bit of an eyesore. Moreover, there are a lot of other useful metadata in the media files, including cool stuff like album art. So instead of just files, Emms will try to extract metadata from each track and display a nicely-formatted track listing. The format can be controlled by customizing the variable emms-track-description-function. Emms uses so-called info methods to extract the metadata from each file. emms-info-native, which I mentioned before, is the built-in metadata reader written in Emacs Lisp. It provides support for Ogg Vorbis, Ogg Opus, FLAC, and MP3. However, if you have media in other formats, you can also add info methods to the emms-info-functions list, which call external programs such as exiftool, the LibTag library, tiny-tag, etc. to read file metadata. Since reading metadata takes time and that metadata doesn't change very often, Emms builds a cache as it extracts the information from each file. The first time loading of thousands of tracks into the emms cache may take a while, but as is the nature of caching, subsequent loads will be nearly instantaneous. To ease loading huge media collections, emms also can populate the cache asynchronously, so that your emacs isn't locked up in the interim. Let's talk about streams and URLs. Not all playlist entries need to be associated with files. It's possible to add streaming playlists and URLs to any playlist. Emms also comes with a built-in eclectic list of streaming audio stations to get you started. Any playlist entry can be a URL, and that URL will be passed on to the media player backend, which can play it, if any.

[00:11:01.200] Meta-playlist mode

Meta-playlist mode: Emms also has meta-playlist mode to help manage multiple playlists. When you invoke meta-playlist mode, you will see a listing of all of the current Emms playlists, and this mode binds a handful of useful keybindings to help manage those playlists.

[00:11:29.860] The browser

The Browser: Music doesn't always lend itself to being viewed as a series of discrete files. While there may be a good taxonomy of music that can be reflected using directories and filenames, there are other aspects which cannot. This is especially true when you consider that unlike many computer file taxonomies, music files may contain a lot of self-descriptive information in the form of metadata, such as the year a work was published, the composer, the performing artist, etc. Therefore, it makes sense for Emms to enable a different view into a media collection which is based on the cached metadata. The browser interface binds a host of keys to help navigate the tree structure of the metadata information. Since browser display is not predicated upon directory structure, you can invoke functions such as emms-browse-by-album, or emms-browse-by-artist, etc. to view the collection in different ways. Emms can do a lot more, but covering it all would take too much time. I do recommend opening the fine Emms manual and getting to know some additional features such as sorting tracks in playlists, sorting and filtering in the browser, editing track information, deriving a new playlist from an existing playlist, the music player daemon, lyrics display, volume control, bookmarks, GNU FM, and Dbus/Mpris support. I hope this was a useful introduction to Emms.

[00:13:19.920] How Emms works: The technical part

How Emms Works: The technical part: This part is an overview of how Emms works. By the end of this, you should be familiar enough with Emms internals to hack on it. Hint hint. A short history of Emms Emms is 20 years old as of the time of writing. Old enough to drink in many countries. This means it was developed back in 2003 for emacs 21.2 or thereabouts. As developers, we don't go around looking to replace code just because it's old. On the other hand, some parts were inadequate or just didn't age gracefully. And we have been partially or completely rewriting those. I became the maintainer of Emms about a decade ago, but I didn't start the project. Jorgen Schäfer started the project. I reached out to Jorgen and he kindly shared some of his recollections. Jorgen states that Emms was born back when the music format wars raged. MP3 was the standard, but overshadowed with patent issues. In fact, Technicolor and Fraunhofer IIS only stopped licensing their patents for MP3 as recently as April of 2017. Jorgen said that, and I quote, "I needed a tool that was player agnostic and that could deal with a large collection of music files. And I did not want any of the GUI music players that existed back then. Primarily, actually, because I did not want to be switching windows to skip to the next song. If I remember correctly, I had just a shell script before that. But I figured I lived in Emacs, so why not write a tool that I can control my music from Emacs without ever having to leave Emacs?" Unquote. We can see that Jorgen's motivations were of the best kind, to stay in Emacs. Emms, an architecture of sensible abstractions. Emms can be divided into a number of parts. The core, tracks, playlists, sources, players, info, cache, and ancillary. Now David J. Wheeler once said that all problems in computer science can be solved by another level of indirection, except of course for the problem of too many layers of indirection. Emms core has survived this long because it makes sensible and flexible coding abstractions. Keep this in mind as we explore the implementation. This following part of the talk will also be invaluable if you want to hack on Emacs. Another hint.

[00:16:23.820] The Emms core

The Emms core. The core defines tracks, playlists, a way to start and stop playback, as well as ways to proceed to the next track.

[00:16:36.440] Tracks

Tracks: Emms tracks consist of a list whose CAR is the symbol track, and CADR is an alist starting with the association of `type'. Type can be something like file, streamlist, URL, etc. A track of classical music from Bach's Art of Fugue may look something like this. While a track may contain many associations, the number of associations remains a small constant from the perspective of computational steps required to find any particular association.

[00:17:18.460] Playlist

Playlist: An Emms playlist consists of an Emacs buffer with a buffer-local non-nil variable, emms-playlist-buffer-p. The buffer can contain anything, any amount or type of text, or anything else. Emms tracks are stored in text properties within the buffer, with the unimaginatively named text property emms-track. For Emms, to go to the next track consists of nothing more than looking for the next text property change containing emms-track, wherever that is. That means that there is a healthy decoupling between the visual representation of a playlist and its contents as far as Emms is concerned. This decoupling allows Emms playlist buffers to look like anything as long as that anything consists of one or more emms-track text properties.

[00:18:22.080] Sources

Sources: A source is how you tell Emms: "Go and get those things and turn them into tracks." More specifically, an Emms source is a function called in a playlist buffer in order to add tracks. And even more specifically, a source is really a family of related functions defined by the macro define-emms-source. A straightforward example is the function emms-add-directory, which adds an entire directory of files to the current playlist. It accepts, or interactively queries for, a directory and iterates over each file in that directory, adding them as tracks to the playlist buffer as it goes. Emms comes with sources for files, directories, URLs, playlists of various formats, files from dired mode, and etc.

[00:19:22.160] Players

Players: An Emms player is, at its simplest, a data structure with three functions. One to start playing, one to stop, and one which returns true if the player knows how to play a given track. However, if your player also knows how to pause, resume, seek, etc, then additional functions can be added to the player data structure. This is abstract enough to be able to, for example, define a simple player for images with the help of the define-emms-simple-player macro. The above will define a player called emms-player-display, which would call ImageMagick's display command on each file in our playlist with the image file extension we listed.

[00:20:20.520] Info

Info: As previously described, Emms comes with info methods, which are functions to add descriptive information to tracks. Emms is set up so that the hook emms-track-initialize-functions is called when a track is created, and that ends up calling the info methods listed in the emms-info-functions list. These will modify the track data structure to add metadata. One of the coolest recent features of Emms is emms-info-native, written by Petteri Hintsanen; again, sorry for the pronunciation. emms-info-native is a purely Emacs Lisp implementation which reads Ogg Vorbis, Ogg Opus, FLAC, and MP3 files and parses out the metadata. This is in comparison with other info readers which Emms supports, which all involve calling out to external processes and parsing the values returned. emms-info-native works by unpacking and examining the binary data in the media file headers and parsing the data layout specifications.

[00:21:36.660] The cache

The Cache: The Emms cache is a mapping between a full path name and its associated information. Once information is extracted from a file using an info method, that information is then associated with that file in the cache. One thing to bear in mind is that the caching system was originally written back when slow spinning disks were common. A 32GB SSD drive cost close to $700 in 2006, which is the equivalent of about $1,000 at the time of writing. But despite the speed of modern drives, the caching system is still worth using for larger music collections. The caching system is also a prerequisite for being able to use the Emms browser. The cache implementation is relatively naive. For instance, moving a file will invalidate that cache entry for that file and will require a refresh. However, relatively little work has been done to the cache implementation over the years since it has proven to be good enough for the majority of situations. Which is to say, nobody complained.

[00:22:51.620] Healthy back and forth: mpv, mpd, and GNU.FM

Healthy back and forth. MPV, MPD, GNU.FM Process communication with a simple media player can be as straightforward as starting an asynchronous process and waiting for that process to complete in order to move to the next track. This is how the example above with ImageMagick's display binary worked. However, Emms also handles asynchronous two-way communication with processes. A simple example of this would be sending strings to a running process such as the pause command to VLC.

[00:23:31.560] MPV

MPV: MPV is a popular media player forked in a roundabout way from mplayer. One of its most notable features is support for a robust client API. Mike Kazantsev has been working since 2018 to develop the excellent `emms-player-mpv.el'. It can communicate with a long running MPV process via Unix sockets or IP sockets. This allows for MPV to do things like update ICY metadata for streaming audio. So that, for example, when a song changes while you're listening to a streaming audio via Emms, the song title displayed in the mode line and track listing can update as well. This means that deep inside the code there is an Emacs make-network-process call. The fact that Mike has put this together in fewer than 1,000 lines of legible Emacs Lisp is a testament to some serious coding ability.

[00:24:47.470] MPD

MPD: Similar to MPV but potentially on a completely different machine is Emms support for the Music Player Daemon. Music Player Daemon or MPD is a media player with an explicit client-server design and communicates with Emms via a network process. Unfortunately, MPD support has never been all that great. But this isn't the emms developers fault! Because unlike every other media player that Emms interfaces with MPD is designed around its own internal playlist database. This is a surprising design decision on the MPD developers' part since it goes against the client-server mindset. A consequence is that we end up having to try and coordinate and harmonize the MPD playlist with the Emms playlist. I can foresee writing a completely new MPD mode for Emms which is designed to be a true pure MPD client. Unless of course someone volunteers to beat me to it. Hint hint.

[00:26:07.440] GNU FM and Libre FM

GNU FM and Libre FM: Libre FM is a music community which allows you to share your listening habits with other users of the site. A kind of online listening party. In the case of emms-librefm-scrobber.el we use Emacs' url-retrieve function to asynchronously send to a URL and then fire a callback function to process the response. This represents numerous challenges to implement within Emacs. The primary issue being that Emacs itself is pretty weak at doing anything truly and really asynchronously. I can say with confident sarcasm and with tongue firmly planted in cheek that it is almost as if the original designers of Emacs didn't foresee their text editor needing to play music while interacting with a remote network server. How myopic!

[00:27:12.560] How we work: Emms development

How we work: Emms development: This part is an overview of how Emms is developed. By the end of this part you should be able to understand how we hacked this project, and how you can too. Where it's at. How to find our forge. Emms has been hosted at the FSF's forge, Savannah, since around 2003. Emms is distributed via GNU ELPA and integrated into Emacs. Before ELPA it was distributed as a tarball via ftp.gnu.org but that stopped back in 2020. I was initially resistant to ELPA but around the time when the thousandth person asked me why Emms isn't on ELPA, I realized that it had to happen. Emms can also be found in other places such as Melpa or GitHub but we, the developers of Emms, have nothing to do with that and we don't monitor those channels. If you want the source straight from, well, the source, then go to the Savannah Git repository. Look who's talking: Where development discussion happens. If you want to talk to us, discussions all happen on emms-help@gnu.org. We used to use emms-patches@gnu.org but didn't feel like the volume of incoming patches justified a separate mailing list.

[00:28:52.590] The Rime Of The Ancient Maintainer

The Rime Of The Ancient Maintainer: There are a number of activities particular to being a maintainer. These are all part of a project's lifecycle. Let's review some of them.

[00:29:06.080] The life and times of an Emms patch

The life and times of an Emms patch: A maintainer needs to be able to accept, critique, and integrate patches from contributors and developers. This means, among other things, that the maintainer needs to keep on top of copyright issues. Before being able to add Emms to GNU/ELPA, we had to make sure that the copyright situation was in order. This long process required reaching out to people and having them assign the copyright for their work to the FSF, or even removing their code entirely if they couldn't be reached. The experience left me with the conviction that the easiest way to fix the copyright situation of your package is to ensure that it never gets broken in the first place. Often a person will write in to the emms-help mailing list, or perhaps raise an issue on IRC. If it's a bug report or feature request, we'll discuss it, and when it's fixed, we'll ask the reporter to test the result and provide feedback. If it's a patch, then we'll typically go one of three ways. A trivial patch, such as fixing a typo or corrections on a single line of code, will simply be applied by one of the developers. A non-trivial, but one-time patch, will have to be cleared from a copyright perspective. This means assigning copyright for the changes to the FSF. Once that's cleared, then the patch will be applied. Finally, if it's a non-trivial patch, which looks like it would be the start of a long-term development work (my favorite), then after copyright is cleared, that person will be offered to be added to the members with Git repo access on Savannah. From there, we usually use a dedicated branch to do all the playing around before merging it with the main Git repo. If you have ever sent a patch, feature request, or bug report into Emms (small or large), we thank you.

[00:31:24.080] Let It Go: The release process

Let It Go, The Release Process: The maintainer is responsible for the release process. I found that a consistent schedule works well, which is not to say that we have to release on schedule, but that aiming for a consistent release schedule provides structure and a goal. The main Git branch in the repository is stable and more often than not of release quality. Releases are done about every three months. And with such a stable main branch, the process of releasing often involves little more than writing a NEWS entry. As a consequence, new and wonderful features which aren't quite ready for prime time when a release comes around, will remain safely in their branch on the Git repo until after the ELPA release.

[00:32:23.400] It Is Not In Our Stars, But In Ourselves: Future directions

It Is Not In Our Stars, But In Ourselves; Future Directions: One aspect of Emms that needs to improve is ease of setup. Now that might surprise you, since at the time of writing, it's already pretty easy. But my ideal is that the user would need to do nothing at all after installation. And with that, as a goal in mind, there is more work to be done. We are working on a player discovery feature. The idea is simple. The code looks for binaries of popular media players on the user's machine, and for each one found, it asks the user if they want the associated Emms player backend to be configured. In effect, this code is already working, but currently an undocumented, unofficial feature. You can try it for yourself with emms-setup-discover-players. So what's the holdup? emms-setup-discover-players currently configures the emms-player-list variable, but doesn't write it to disk. And that means that the configuration isn't preserved between Emacs sessions. The question then becomes, what is the best way to preserve this setting? I personally don't like anything to edit my .emacs except me, and I wouldn't do that to anyone else. Now we already write state to the .emacs.d/emms/ directory, but that would require care not to clobber a user's existing setup. Having the user set up their system in one place, such as a .emacs or a .emmsrc, while saving state to a different place is asking for confusion. This is a good example which I bring up of where a maintainer needs to solicit opinions from developers, both the Emacs developers, asking them where packages should save state, and the Emms developers, and also users. Then, the maintainer needs to carefully choose a path forward. It is typical of the kind of issue you have to have in mind when you're maintaining a package.

[00:34:44.849] Development policies: Interface language

Development Policies: Interface Language. A maintainer of an interactive program such as Emms needs to think about user interaction. Emms doesn't use key bindings which are familiar to people who are used to GUI media players, and that can, and has, caused friction. Some new users are confused when they press the spacebar on an entry in the Emms browser, only to find that nothing starts playing. Indeed, all that does is to expand the browser tree at that point. Then they might press RET on the same entry, and be further frustrated at the continuing silence. Since what return does is just to add that entry at point to the current playlist. The discussion then arises about how Emms should handle that situation. On one hand, we want to make it as easy as possible for new users to learn Emms, and adopt a do-what-I-mean interface approach. On the other hand, this is an Emacs project. It isn't a stand-alone GUI media player, and should integrate into Emacs, and serve Emacs users first and foremost.

[00:36:05.980] Development policies: Freedom

Development policies: Freedom. Another maintainer job is to think of Emms' posture in regards to software freedom. Here are a few examples. Back with MP3 was still a patent encumbered format, we pushed hard for Vorbis everywhere along with the PlayOgg campaign. A then popular music streaming service, which will remain unnamed, changed their stance towards third-party applications, and required individual API keys which could not be shared. We stood firm, said "no", and removed support for that service. A recent suggestion to add support for YouTube was also nixed, because the particular backend was found to download and run proprietary javascript on the user's machine. Saying no to potentially useful or wanted features because it involves non-free software is often an unpopular decision and can alienate people. A maintainer needs to think carefully about each of these decisions, as they are rarely straightforward and one-sided. And as you see above, they also change over time and need to be re-evaluated. One of the most useful things a maintainer can do is to coordinate the development effort and help new people join the project. In light of that, if you want to work on a project which has a bit of everything, you could do worse than hacking on Emms. There is inter-process communication, displaying graphics, parsing binary files, caching, asynchronous processes, user interface design. We also are a project that insists on keeping a well-written and up-to-date manual. If you can write English or hack Emacs Lisp at all, chances are that there is something you can do for Emms. Just saying.

[00:38:12.370] Acknowledgements

Acknowledgements: I'd like to express my deep gratitude for all of the people who have hacked on Emms during my time as a maintainer and before it. It is often the case that I'm just the person holding the rudder and steering the ship, with all of these developers rowing furiously to provide the power which actually moves the ship forward. Thank you to all.

Captioner: yoni

Q&A transcript (unedited)

Hi, Yanny, how are you doing? thank you. I first want to commend you on your ability to both do the how the user encounters the MMS, how the developer might be interested about how it works, and I feel like you've done a wonderful job of talking to absolutely everyone in our audience, whatever their skill level. So thank you so much for this. you know, good for some, but excellent for none. But hopefully the result is that people can get something out of it. I think it's very important to make sure that everyone feels that they have access to Emacs, they have access to EMMS, that they can do this in whatever capacity they want. It's for everyone. I really believe that. a talk that is kind of a jack-of-all-trades, but frankly you've done a wonderful job of making it interesting for everyone, because also I think the parts worked really well, and people always had something to look forward in terms of their expertise of what particularly spoke to them. So thank you again. What I'm going to do, we have about 14 minutes of Q&A, So I'll invite people, as I usually do, to add their questions in the other pad that you can find on the talks or on IRC. You can also join us in the discussion. I will make sure this time to ping Sasha to open the Q&A. Can you open, I-V-E-M-M-S. All right, and in the meantime, whilst we wait for people to join us in the room, I will start reading some of the questions off the pad. So we had the first question about the music that we played during the launch break, and It's 1 of our dear friends, Shoshin Ganshangroh, a free album, Basement Dazed. I've put the link in the pad and we've been using Shoshin's music for the last 3 years, I think, and everyone, people are so excited. Some people say, why is it so noisy in the background? But it's just because there's 1 part of the different tracks that sounds like static and it always gets people. We should probably do something about this, but frankly it makes me laugh every time. Starting with the first actual question, well actually it's a bit of a meme question, for the next Emacs Con, could we have an eMMS playlist to follow the talks along? guess I'm wondering what they mean exactly by that. Is that a shareable playlist that we can pass along and just have people go to a URL and just be able to play that? I think that's an excellent idea. It should be a relatively low bandwidth process. right of our alley. I'm thinking about the ICS file that we produce for all the events that are related to Emacs. You know the workshop that happened in Paris or in New York, LA? Sasha compiles a list of all the events and when they happen, and then we provide this to everyone. And we can do very much the same with EmacsConf. You could have a playlist for EmacsConf 2023, where you get all the talks and perhaps also the Q&A sessions so that you can relieve the 16 hours of content that we're producing. That'd be great, that's a great idea I think. in the Emacs playlist structure that things are missing in the playlist structure, then it would be a great impetus to implement those and extend the playlist structure. Because after all, it's Lisp, it really is data and functions all mixed together, so we can do that. It would be very interesting to dive into it and see what's missing. That would be even more informative than what it can do. question. I like to use music and audiobooks in very different ways. With music, I like shuffling by artists and with audiobooks, I want to read sequentially and pick the same playlist over a couple of days or weeks. Do you have any tips for using these 2 opposing media's workflow? have very long endurance races that I watch, which I do all my media consumption is done via EMMS. I also listened to music. And so there's also a middle in between. There's 1 end in which you have popular music. These are standalone songs that are typically 3 to 4 minute long and they are best consumed in a random you know order because they are designed around, you know, a commercial radio distribution. I guess I'm dating myself by saying radio, but you know all the that. In the middle there are longer works like musicals and classical where these are units where they might be very long but you would have several tracks that you do want to have 1 after the other, and you want to be able to stop and go to the next track. And then at the very, very other end, you have extremely long format, which is included in a single file, such as an audio book, a movie, a tutorial that you're watching, or in my case, you know, a 24 hour, the 24 hours of Le Mans, just the 24 hour race, which, you know, that's 1 heck of a file. So that is 1 of the reasons eMMS has a number of elements such as the meta playlist mode and multiple playlists. So I would say that they would open a number of playlists in eMMS, generate a number of playlists that have each class of media. So the shorter form songs, the more pop songs you have in 1 playlist where you can sort, shuffle it, you know, save it, do whatever you want. Then a separate playlist for the long form stuff. Sometimes that playlist will have even only 1 file in it if it's long enough, then have a key combination which takes you directly to 1 playlist or the other, and within the long-form playlist, looking at the bookmarking function of EMMS, which is designed around being able to save a particular stopping point or multiple stopping points, bookmarks in the audio, and being able to jump back into that audio. The point to remember about the bookmarking feature is that sometimes it really depends on you have to have the right back end. Not all back ends with replaying, not all types of media work well with a bookmarking function, and bug reports welcome. But also there are other backends such as MPV where you can configure it that when you quit playing the song or the media with, you know, cue internally. So sometimes the back end has to continue playing that song. That's what I do in order to, on 1 hand, switch over to a... I want to hear... I'm coding, I want to hear some music, I go to my playlist of short songs, then I'm sitting back and I want to watch a long form something from where I left off and there I go to the other playlist and use bookmarks or the features of the back end that I'm using. We have about 7 minutes and we have more questions, so that's great. Moving on to the next 1. Is there a way to search a music selection by lyrics? Assuming those lyrics are in the metadata or are available elsewhere, it would be neat to call songs up from the lyrics to the song. Perhaps is this implemented so that you can all aliases, so they can use aliases for the song that you like, defining those aliases or shortcuts either inside or outside eMMS? Okay, so I think you've got 2 questions. First about the lyrics and then the aliases. right now. There's a sense in which it is, but not really. What actually needs to happen? The problem is that the caching system is extremely naive. It's just really a hash that's written to disk. And maybe now with SQLite integration or other or just the fact that computers have a lot more speed and space than they used to have, we need to expand the cache to be a lot more greedy and a lot more flexible so that we can store things such as lyrics in as part of the metadata. There's no reason not to do that. Unless your collection would have to be truly enormous in order to slow things down. We wouldn't even need to compress the lyrics in order to store them like that. But that is a goal. So our rewrite of the cache is currently in progress, and the goal is to have a system where you can put any related information, including lyrics, and map that to a particular piece of the media, be it a URL or a... So you could have in a sense, you could have a URL to a lecture and the metadata associated would be some text, some notes or something else like that. I'm not sure how it answers the question about the aliases. I mean you can still filter what you've mentioned about the cache. I think it's... Do we consider the aliases to be anything within the metadata? question. I don't have a great answer for that right now. and we can return to it. You can return to it at a later stage. Yeah. All right, moving on to the next question, then. I'll just, we'll put a pin on this. All right, next question. Are there plans for managing metadata with online resource backends, i.e. Discogs or music brains? What about something like Beats and Emacs or part of the EMMS? mailing list right now. We don't want to replicate what Beats does very, very well in eMMS. We don't want a clunky interface with Beats. We do want some kind of, and so it's hard to tell exactly where to draw that line. So the big answer is yes, absolutely, there is a plan to do that. The details become complicated because for 1 thing, the backend, the database that MusicBrain uses, AcoustID, I don't remember if AcoustID is the binary or the database, but that's actually for non-commercial use only. So not only do you need to compile a piece of software on your computer as a shim, which is what you need to do in order to set up beats to do fingerprinting. But it also crosses this line between completely free software to completely free software interfacing with a non-commercial only service. So a lot of the discussion that's going on now is what is the contour? Where would be where we would be effective for EMMS to do management and where not? For 1 thing, I would love to be able to... 1 thing that we definitely would love to be able to do is when you hit E on a file and you get all the metadata to be able to then give a command to say, hey, play to music brains and see if you can improve that metadata. Do you have better metadata, more complete metadata to complete that? That is definitely in the pipeline. How best to do it, that's a discussion. need to go to the next talk. Okay, I'll risk it. 1 more question and a short answer if you can. Have the developers considered using Emacs customized functionality to persistently store settings when using eMMS setup discover players? especially with the discover players. How to do it exactly without annoying people and clobbering their own settings, we just need to be very careful about that. Yes, that's in the coming releases. thank you so much for your time. Feel free to stay in the room. I see that some people have started joining on BBB. If you have more questions, feel free to unmute yourself and ask them live. Younid, I could ask you also to perhaps answer the question. I've put the link to the pad in the BBB chat, so if you look at the... Here, I think, we're not mirrored on BBB. If you look at the left you should be able to see the chat and the questions and if you could just answer the last question that would be great. For us on the general track we will be moving to the next talk and Yannick do you have any last thing to say in conference and thank you to everyone who helps with the EMMS. well, thank you so much, Yoni. We'll probably see you later. Bye-bye. Wonderful. And I think we are off air. Thank you so much, Juni. I need to step out and go take care of And just to, I forgot to mention, but you can still talk here and everything is still being recorded. So, I'll see you later. conference. and thank you. My name's Grant. I've, you helped me contribute to EMMS maybe 2 or 3 years ago. I was trying to do the So I just wanted to say thank you. that entire process. I know that 1 of the things that happens is that people want to contribute, but it's not as slick as GitHub and stuff like that, especially with the copper assignment. And objectively, it's not that. It's just harder than what they imagine it might be. I think you're doing a wonderful job as a maintainer. I still hang out on the list and enjoy listening in on the discussions. So. I think that's it. And I think that's it. And I think that's it. I appreciate it. And I'll leave you to all of you to go on from being a product. And that she valued to all of us long term being a project. being there long term, people tend to find it easier trying to continue contributing to the project if there's a consistency there, if there isn't a churn, if there is a kind of a core group. I guess it's like, you think it's constant. Eliezer Etzke and RMS, whatever on the next mailing list, You know, okay, there are certain people that I think so. So thank you for that. That's very important. That helps. EMMS several years ago, it's, it's improved a lot since then. And I notice your focus on helping new users get started quickly. And I think the talk today will help with that too. So the, especially the TLDR, like how to start it on the link that to the website, find somehow that we can get on to prepare for that. And this together. Now, question for you, Where would you like to see EMMS go? Where do you see it landing? What do you feel like this is what this is we're sorely missing these things? because I both use it to play my music collection, but also, like I record my own music. And I wanted to be able to edit my metadata in Emacs, because editing metadata elsewhere sucks. And so that's kind of why I got involved with that. And I was like, being able to edit metadata, especially for content that maybe you're creating or because I have a bunch of files of just unlabeled stuff I've recorded on, you know, different quarters, things like that. So that's kind of where I was focusing on it. It's the only media tool that lets me do that, you know, I can play the music back and have quick editing. So I know there was a couple of things we had talked about in terms of maybe improving kind of the user interface for the tag editor, things like that. So I don't have any grand visions for where EMMS should go. I know pretty much all the things I've heard about it already. You can hook up to GNU FM, the Scrabbling Service, and all that kind of stuff. I don't really feel like it's missing much, especially being able to choose the back ends. I guess, if anything, it's the interface. How can it be even more intuitive for users? And I think that, you know, we need more people playing around with it, I guess. Yeah. because I'm sure there are lots of people playing around with it, arriving at a conclusion, keeping it to themselves and moving on. Yeah. Which, and I know that a lot of bits of software put a send a bug report feature in and stuff like that and no 1 uses those either. So that's the frictional cost. I think the context switch for people between this doesn't work to actually formulating in words what didn't work, that is a very expensive context which most people will not do. And we're poorer for that. So, I think that when we integrate music brains and other things like that into. Now, of course, music brains will probably, it would be very funny if you pull up your stuff, right? Something that you wrote and you say, hey, music brains match this and it's not there, then it'll probably suggest because there are, there was a system I was looking at its code for researching stuff for EMS And I'm trying to remember what it's named. It begins with a J, it's this media player, free floss media player that it's like a media server that can cast to a television and stuff like that. And I asked it to automatically label things and the results were horrible. It thought that half of my songs were movies. It thought that JPEGs were songs. It just, it did some, it did incredibly, it's not a solved problem, I think. So the, what I'm thinking with MusicBrainz and those services is that you hit a button and you have you get another pane with a suggestion and you either and you can copy through you can say okay copy this and this in this field over or reject the suggestion and maybe get another 1. So, That's more like a diff, right? Like you get the diff between the 2 and you can apply which changes you like. Yeah. Was it Jellyfin? Is that... Jellyfin? Yeah, did it clobber all your metadata? Or does it just label stuff? looking for really, not allow me to do very easily. So I was, so, you know, on 1 hand, it makes me feel, oh, we're not the only ones dealing with this. We're not the only ones struggling with this. On the other hand, it would be nice if that's a paragon that we can look to and say, this is a wonderful way of doing it. Let's incorporate as much of especially if you're modifying people's media files you know so that so I'm not a mainframe for MMS because I'm old and curmudgeonly essentially in my, in the way they do it. And honestly, I rarely ever, I use the MMS browser when I need to debug the MS browser. I don't, I use very simple commands and I even rarely look at the playlists. That was 1 of the things because when I got into MMS originally when my eyesight started going so I had to rely less and less on GUI interfaces. So that was, so to this day that's how I use EMMS. I remember running into a browser bug because I think just my age, like, I want to be able to tab through and like that was a huge that that changed recently right where you tab and it unfolds in the browser but yeah I realized that people use emms in so many different ways just like any piece of emacs there's there's many ways to do it but appreciate your time I'm gonna actually put together this Christmas tree meet you in person. But yeah. generate Yeah, thank you. conference. here. Let's see. Let's see. So there is, okay. There's a question here. I like what you said about balancing the concern for software freedom with the worry that this might alienate the package user. I wonder if you have advice for other maintainers how to communicate this sort of thing diplomatically? Yes, when you have to deny implementing a feature for a freedom reason. This in fact happens all the time. A recent example of this was a YouTube download, right, the YouTube download feature. At the time, okay, so stepping back, the request was to have a YouTube download feature integrated strongly into eMMS so that you put in a YouTube URL and you can download the video and play it. And the question isn't really whether you can chain YouTube Downloader or 1 of those things into your EMMS configuration. You can do whatever you want. But the question is, does EMMS actually integrate with it really, really strongly to the extent where it tells you oh you don't need to download install please go ahead and install that or whatever and at the time we checked it we found out that you know the version that we were looking at of the YouTube download or YTDLP or whatever it was called, actually downloaded a good amount of proprietary JavaScript onto your machine and ran it, just as if you were going on to the YouTube page, which is not for me to tell people not to do if they want to do that, but it's absolutely for me not to cause to happen on the user's machine without them. 1 of the last thing that I want to do in the world is have a user inside Emacs press a button and have proprietary software get downloaded behind their back and run on their machine that would be disastrous so we had to say no we had to say that's I'm sorry that's beyond the pale and in fact in doing so some people who were using this system said, actually I had no idea it was doing this behind my back. I thought it was just magic. I thought it was a YouTube video without any freedom issues. I'm going to look into it or I'm going to stop using it. So my advice would be Stand firm and just be Not not preachy. Don't tell people what they need to do be very clear about what you stand for and what the project stands for, and so they very clearly know where you stand. And I think that people actually appreciate that more than a political answer, right? That has been my experience. Now, excuse me, taking into account that 1 or 2 people will tell you, this is terrible. I'm leaving. whatever, and just leave. But some people are ornery. That's not necessarily something bad that you did. But that has happened. There are multiple stories. Because the MMS is so old, there are multiple points in which non-free software intersected with the EMS because of multimedia and we had to go the other direction and so far it has served EMS well like the project has died as a result. Of course, can't prove a negative, don't know where we would be if we had taken, gone down that route. I'm pretty sure we would need a new ELPA, and I think being so clearly integrated with emacs is a huge benefit to eMMS because it's it allows people to install it very easily. And those are all the questions that I can see.

Questions or comments? Please e-mail emacsconf-org-private@gnu.org