WEBVTT captioned by yoni, checked by sachac NOTE Introduction 00:00:00.000 --> 00:00:05.399 The Sound of Emacs, Emms, The Emacs Multimedia System. 00:00:05.400 --> 00:00:09.159 Hi, I'm Yoni Rabkin and I'll be talking about Emms; 00:00:09.160 --> 00:00:11.519 the Emacs Multimedia System. 00:00:11.520 --> 00:00:14.559 What is Emms? 00:00:14.560 --> 00:00:18.119 Emms displays and plays media from within Emacs 00:00:18.120 --> 00:00:20.519 using a variety of external players 00:00:20.520 --> 00:00:23.539 and from different media sources. 00:00:23.540 --> 00:00:26.679 Emms can run as a minimalistic player 00:00:26.680 --> 00:00:28.559 which is controlled with no more than 00:00:28.560 --> 00:00:31.119 a handful of simple M-x commands, 00:00:31.120 --> 00:00:36.059 or as a fully-fledged interactive media browser and player. 00:00:36.060 --> 00:00:40.639 Emms can display album art, play streaming audio, 00:00:40.640 --> 00:00:43.439 tag music files, search for lyrics, 00:00:43.440 --> 00:00:46.679 provide MPD connectivity, control the volume, 00:00:46.680 --> 00:00:49.619 and more. Much more. 00:00:49.620 --> 00:00:53.879 The Emms project acts like Emacs in microcosm. 00:00:53.880 --> 00:00:56.559 It slowly but surely grows bigger 00:00:56.560 --> 00:00:58.479 and gets ever more features. 00:00:58.480 --> 00:01:03.319 Perhaps Emms will one day even have a text editor. NOTE The structure of this talk 00:01:03.320 --> 00:01:05.599 The structure of this talk: 00:01:05.600 --> 00:01:08.159 We'll start with an introduction to Emms. 00:01:08.160 --> 00:01:10.559 This is the practical part. 00:01:10.560 --> 00:01:15.879 Then, a bit about how Emms works. That's the technical part. 00:01:15.880 --> 00:01:21.319 Finally, how we work. All about Emms development. NOTE Introduction to Emms: The practical part 00:01:21.320 --> 00:01:25.020 Introduction to Emms: The practical part: 00:01:25.021 --> 00:01:28.679 I want this talk to be of immediate use to people, 00:01:28.680 --> 00:01:33.519 so I'm going to present a quick TL;DR of the Emms manual 00:01:33.520 --> 00:01:36.399 concerning installation and use. 00:01:36.400 --> 00:01:38.439 By the end of this part you should be able to 00:01:38.440 --> 00:01:45.279 install, configure, and use Emms in a variety of ways. 00:01:45.280 --> 00:01:48.119 Where can I get Emms? 00:01:48.120 --> 00:01:54.319 Emms is distributed primarily via GNU ELPA. 00:01:54.320 --> 00:02:02.079 So it's really only a M-x list-packages away at any moment. 00:02:02.080 --> 00:02:07.719 There's also a website hosted at gnu.org. 00:02:07.720 --> 00:02:11.019 Among other things on the website, you'll find 00:02:11.020 --> 00:02:21.279 a copy of the friendly, robust, and up-to-date user manual. 00:02:21.280 --> 00:02:25.919 Installing Emms has become progressively easier over time 00:02:25.920 --> 00:02:28.719 and will continue to get easier. 00:02:28.720 --> 00:02:32.559 In the bad old days, it required downloading a tarball 00:02:32.560 --> 00:02:35.059 and compiling a C language shim 00:02:35.060 --> 00:02:38.919 to enable reading metadata from media files. 00:02:38.920 --> 00:02:43.359 But those days are long gone, and installing Emms is now 00:02:43.360 --> 00:02:47.039 as easy as invoking M-x list-packages, 00:02:47.040 --> 00:02:51.839 installing the Emms package, and placing as few as 00:02:51.840 --> 00:02:57.719 2 or 3 lines of configuration in your Emacs initialization. 00:02:57.720 --> 00:03:02.839 So after the package is installed via ELPA, 00:03:02.840 --> 00:03:08.439 you can add these few lines. 00:03:08.440 --> 00:03:12.359 `emms-all` will make available all of the stable features 00:03:12.360 --> 00:03:15.739 which are shipped with Emms. 00:03:15.740 --> 00:03:20.839 The `emms-player-list` variable is a list of players 00:03:20.840 --> 00:03:25.599 like MPV, MPlayer, VLC, etc. 00:03:25.600 --> 00:03:29.399 Emms will call and control these external players 00:03:29.400 --> 00:03:31.999 to play your media. 00:03:32.000 --> 00:03:36.659 The variable `emms-info-functions` is a list of ways 00:03:36.660 --> 00:03:40.959 for Emms to read the metadata in your media files 00:03:40.960 --> 00:03:45.279 so that Emms can display song title, artist name, 00:03:45.280 --> 00:03:49.479 year of production, etc. 00:03:49.480 --> 00:03:55.199 The `emms-info-native` feature in the setup example 00:03:55.200 --> 00:03:58.159 is the built-in metadata reader 00:03:58.160 --> 00:04:01.799 written entirely in Emacs Lisp. 00:04:01.800 --> 00:04:04.239 But there are also other backends 00:04:04.240 --> 00:04:07.719 which can call external programs for info 00:04:07.720 --> 00:04:14.719 such as TinyTag, the TagLib library, exiftool, and so on. 00:04:14.720 --> 00:04:17.559 You can then old-school restart your Emacs 00:04:17.560 --> 00:04:22.799 or simply evaluate the above couple of lines to get going. 00:04:22.800 --> 00:04:26.279 Now that we have Emms installed and configured, 00:04:26.280 --> 00:04:29.239 we should load some media for player. 00:04:29.240 --> 00:04:32.719 There are multiple ways to load media into Emms for playing. 00:04:32.720 --> 00:04:36.279 They can be directories with local files, 00:04:36.280 --> 00:04:38.519 synchronized from a remote instance of 00:04:38.520 --> 00:04:44.719 a music player daemon, PLS or M3U playlists, 00:04:44.720 --> 00:04:47.439 a list of URLs for streaming, 00:04:47.440 --> 00:04:51.119 or even Emms' own native playlist format 00:04:51.120 --> 00:04:57.199 which is unsurprisingly a just serialized Emacs Lisp. 00:04:57.200 --> 00:05:00.199 No matter how you add tracks to Emms, 00:05:00.200 --> 00:05:03.879 you'll end up with a playlist. 00:05:03.880 --> 00:05:08.959 A fundamental strength of Emms is that each playlist 00:05:08.960 --> 00:05:13.479 is a regular Emacs buffer and the track listing therein 00:05:13.480 --> 00:05:17.859 is nothing more than text lines with property overlays. 00:05:17.860 --> 00:05:21.359 This means that you can navigate, search, copy, 00:05:21.360 --> 00:05:24.879 and edit an Emms playlist buffer 00:05:24.880 --> 00:05:28.679 just as you would any Emacs buffer. 00:05:28.680 --> 00:05:31.319 If you want to reorganize the tracks in the playlist, 00:05:31.320 --> 00:05:33.959 then you can simply kill yank the tracks 00:05:33.960 --> 00:05:36.759 just as you would any buffer with lines of text, 00:05:36.760 --> 00:05:42.959 and the same can be done between multiple playlist buffers. 00:05:42.960 --> 00:05:46.119 One of the most straightforward ways to add media 00:05:46.120 --> 00:05:51.939 is to invoke a command like `M-x emms-add-directory-tree`. 00:05:51.940 --> 00:05:55.679 You can point it to the top of a set of directories 00:05:55.680 --> 00:06:00.279 with playable files for Emms to traverse. 00:06:00.280 --> 00:06:05.199 Another rather convenient method is to mark files in Dired 00:06:05.200 --> 00:06:09.679 and to invoke `emms-add-dired`. 00:06:09.680 --> 00:06:11.679 I definitely use this one a lot. 00:06:11.680 --> 00:06:16.119 The Emms playlist mode binds 00:06:16.120 --> 00:06:19.879 a number of useful keys and commands. 00:06:19.880 --> 00:06:23.959 It's highly recommended that you either 00:06:23.960 --> 00:06:25.959 read the friendly manual 00:06:25.960 --> 00:06:32.319 or hit "C-h m" in a playlist buffer to discover them. 00:06:32.320 --> 00:06:35.959 Now we have a playlist buffer with a number of tracks, 00:06:35.960 --> 00:06:40.819 so the next step is going to be playback. 00:06:40.820 --> 00:06:44.399 Emms can be used as a minimalistic player 00:06:44.400 --> 00:06:48.319 with nothing more than a handful of commands. 00:06:48.320 --> 00:06:51.359 Once there is a current Emms playlist, 00:06:51.360 --> 00:06:57.559 invoking emms-start will begin playing the current track. 00:06:57.560 --> 00:07:00.039 Now of course in a new playlist 00:07:00.040 --> 00:07:02.579 that would be the first track. 00:07:02.580 --> 00:07:07.199 Now emms-next, emms-pause, and emms-stop 00:07:07.200 --> 00:07:11.259 do exactly what you think they do. 00:07:11.260 --> 00:07:13.199 To visit the current playlist, 00:07:13.200 --> 00:07:17.639 you can invoke M-x emms-playlist-mode-go, 00:07:17.640 --> 00:07:22.699 which is a long command I personally bind to "M-f12". 00:07:22.700 --> 00:07:25.319 You'll be taken to the current playlist buffer. 00:07:25.320 --> 00:07:29.239 While you can have multiple playlist buffers, 00:07:29.240 --> 00:07:35.779 only one is current for the purposes of playback commands. 00:07:35.780 --> 00:07:38.119 The playlist buffer has keys bound 00:07:38.120 --> 00:07:39.919 to control the media being played. 00:07:39.920 --> 00:07:44.199 `emms-seek-forward` and `emms-seek-backwards` allow you 00:07:44.200 --> 00:07:49.039 to scrub along the media being played. 00:07:49.040 --> 00:07:51.719 Which commands are available is a function of 00:07:51.720 --> 00:07:54.199 the player backend being employed. 00:07:54.200 --> 00:07:56.599 The simplest of players may have nothing more 00:07:56.600 --> 00:07:59.559 than the ability to play, stop, and seek, 00:07:59.560 --> 00:08:04.239 but others may implement a plethora of commands. NOTE The modeline 00:08:04.240 --> 00:08:08.879 The Modeline: Emms will by default display 00:08:08.880 --> 00:08:11.839 the name of the currently playing track in the mode line 00:08:11.840 --> 00:08:14.999 with information such as playing time. 00:08:15.000 --> 00:08:15.559 The mode line format is controlled 00:08:15.560 --> 00:08:20.639 via the `emms-mode-line-format` variable 00:08:20.640 --> 00:08:27.139 and the `emms-mode-line-playlist-current` function. 00:08:27.140 --> 00:08:31.039 Metadata and the cache. 00:08:31.040 --> 00:08:34.799 It would be sufficient for emms to simply list 00:08:34.800 --> 00:08:38.619 the file names or urls of each piece of media, 00:08:38.620 --> 00:08:40.999 but unless you name your music and media 00:08:41.000 --> 00:08:43.939 with obsessive consistency and precision, 00:08:43.940 --> 00:08:46.679 not that there is anything wrong with that 00:08:46.680 --> 00:08:50.859 then the resulting list will be a bit of an eyesore. 00:08:50.860 --> 00:08:54.119 Moreover, there are a lot of other useful metadata 00:08:54.120 --> 00:08:58.619 in the media files, including cool stuff like album art. 00:08:58.620 --> 00:09:01.919 So instead of just files, Emms will try 00:09:01.920 --> 00:09:04.399 to extract metadata from each track 00:09:04.400 --> 00:09:08.219 and display a nicely-formatted track listing. 00:09:08.220 --> 00:09:10.799 The format can be controlled by customizing 00:09:10.800 --> 00:09:15.459 the variable `emms-track-description-function`. 00:09:15.460 --> 00:09:19.639 Emms uses so-called info methods to extract 00:09:19.640 --> 00:09:22.439 the metadata from each file. 00:09:22.440 --> 00:09:25.679 `emms-info-native`, which I mentioned before, 00:09:25.680 --> 00:09:30.359 is the built-in metadata reader written in Emacs Lisp. 00:09:30.360 --> 00:09:37.659 It provides support for Ogg Vorbis, Ogg Opus, FLAC, and MP3. 00:09:37.660 --> 00:09:40.359 However, if you have media in other formats, 00:09:40.360 --> 00:09:42.439 you can also add info methods 00:09:42.440 --> 00:09:45.239 to the `emms-info-functions` list, 00:09:45.240 --> 00:09:48.699 which call external programs such as exiftool, 00:09:48.700 --> 00:09:55.419 the LibTag library, tiny-tag, etc. to read file metadata. 00:09:55.420 --> 00:09:58.199 Since reading metadata takes time 00:09:58.200 --> 00:10:01.339 and that metadata doesn't change very often, 00:10:01.340 --> 00:10:04.079 Emms builds a cache as it extracts 00:10:04.080 --> 00:10:06.859 the information from each file. 00:10:06.860 --> 00:10:09.879 The first time loading of thousands of tracks 00:10:09.880 --> 00:10:13.259 into the emms cache may take a while, 00:10:13.260 --> 00:10:16.999 but as is the nature of caching, subsequent loads 00:10:17.000 --> 00:10:20.059 will be nearly instantaneous. 00:10:20.060 --> 00:10:22.719 To ease loading huge media collections, 00:10:22.720 --> 00:10:26.519 emms also can populate the cache asynchronously, 00:10:26.520 --> 00:10:30.519 so that your emacs isn't locked up in the interim. 00:10:30.520 --> 00:10:33.779 Let's talk about streams and URLs. 00:10:33.780 --> 00:10:37.619 Not all playlist entries need to be associated with files. 00:10:37.620 --> 00:10:39.839 It's possible to add streaming playlists 00:10:39.840 --> 00:10:42.639 and URLs to any playlist. 00:10:42.640 --> 00:10:46.119 Emms also comes with a built-in eclectic list 00:10:46.120 --> 00:10:50.039 of streaming audio stations to get you started. 00:10:50.040 --> 00:10:52.639 Any playlist entry can be a URL, 00:10:52.640 --> 00:10:56.719 and that URL will be passed on to the media player backend, 00:10:56.720 --> 00:11:01.199 which can play it, if any. NOTE Meta-playlist mode 00:11:01.200 --> 00:11:03.679 Meta-playlist mode: 00:11:03.680 --> 00:11:08.299 Emms also has meta-playlist mode 00:11:08.300 --> 00:11:11.959 to help manage multiple playlists. 00:11:11.960 --> 00:11:13.879 When you invoke meta-playlist mode, 00:11:13.880 --> 00:11:16.959 you will see a listing of all of the current Emms playlists, 00:11:16.960 --> 00:11:21.999 and this mode binds a handful of useful keybindings 00:11:22.000 --> 00:11:29.859 to help manage those playlists. NOTE The browser 00:11:29.860 --> 00:11:31.759 The Browser: 00:11:31.760 --> 00:11:35.439 Music doesn't always lend itself to being viewed 00:11:35.440 --> 00:11:38.199 as a series of discrete files. 00:11:38.200 --> 00:11:41.559 While there may be a good taxonomy of music 00:11:41.560 --> 00:11:45.459 that can be reflected using directories and filenames, 00:11:45.460 --> 00:11:49.099 there are other aspects which cannot. 00:11:49.100 --> 00:11:51.599 This is especially true when you consider that 00:11:51.600 --> 00:11:55.299 unlike many computer file taxonomies, 00:11:55.300 --> 00:11:56.719 music files may contain 00:11:56.720 --> 00:11:58.759 a lot of self-descriptive information 00:11:58.760 --> 00:12:00.619 in the form of metadata, 00:12:00.620 --> 00:12:04.279 such as the year a work was published, the composer, 00:12:04.280 --> 00:12:07.519 the performing artist, etc. 00:12:07.520 --> 00:12:11.079 Therefore, it makes sense for Emms to enable 00:12:11.080 --> 00:12:13.199 a different view into a media collection 00:12:13.200 --> 00:12:17.059 which is based on the cached metadata. 00:12:17.060 --> 00:12:19.839 The browser interface binds a host of keys 00:12:19.840 --> 00:12:22.079 to help navigate the tree structure 00:12:22.080 --> 00:12:24.539 of the metadata information. 00:12:24.540 --> 00:12:25.839 Since browser display 00:12:25.840 --> 00:12:28.279 is not predicated upon directory structure, 00:12:28.280 --> 00:12:32.939 you can invoke functions such as `emms-browse-by-album`, 00:12:32.940 --> 00:12:35.639 or `emms-browse-by-artist`, etc. 00:12:35.640 --> 00:12:42.179 to view the collection in different ways. 00:12:42.180 --> 00:12:43.759 Emms can do a lot more, 00:12:43.760 --> 00:12:46.319 but covering it all would take too much time. 00:12:47.020 --> 00:12:50.239 I do recommend opening the fine Emms manual 00:12:50.240 --> 00:12:52.319 and getting to know some additional features 00:12:52.320 --> 00:12:54.999 such as sorting tracks in playlists, 00:12:55.000 --> 00:12:57.199 sorting and filtering in the browser, 00:12:57.200 --> 00:12:59.079 editing track information, 00:12:59.080 --> 00:13:01.919 deriving a new playlist from an existing playlist, 00:13:01.920 --> 00:13:07.039 the music player daemon, lyrics display, volume control, 00:13:07.040 --> 00:13:13.359 bookmarks, GNU FM, and Dbus/Mpris support. 00:13:13.360 --> 00:13:19.919 I hope this was a useful introduction to Emms. NOTE How Emms works: The technical part 00:13:19.920 --> 00:13:23.219 How Emms Works: The technical part: 00:13:23.220 --> 00:13:26.819 This part is an overview of how Emms works. 00:13:26.820 --> 00:13:29.759 By the end of this, you should be familiar enough 00:13:29.760 --> 00:13:34.739 with Emms internals to hack on it. Hint hint. 00:13:34.740 --> 00:13:37.679 A short history of Emms 00:13:37.680 --> 00:13:42.939 Emms is 20 years old as of the time of writing. 00:13:42.940 --> 00:13:45.399 Old enough to drink in many countries. 00:13:45.400 --> 00:13:48.879 This means it was developed back in 2003 00:13:48.880 --> 00:13:53.439 for emacs 21.2 or thereabouts. 00:13:53.440 --> 00:13:56.279 As developers, we don't go around looking to 00:13:56.280 --> 00:13:58.839 replace code just because it's old. 00:13:58.840 --> 00:14:01.839 On the other hand, some parts were inadequate 00:14:01.840 --> 00:14:04.919 or just didn't age gracefully. 00:14:04.920 --> 00:14:10.359 And we have been partially or completely rewriting those. 00:14:10.360 --> 00:14:13.719 I became the maintainer of Emms about a decade ago, 00:14:13.720 --> 00:14:16.099 but I didn't start the project. 00:14:16.100 --> 00:14:21.019 Jorgen Schäfer started the project. 00:14:21.020 --> 00:14:22.519 I reached out to Jorgen 00:14:22.520 --> 00:14:25.619 and he kindly shared some of his recollections. 00:14:25.620 --> 00:14:28.199 Jorgen states that Emms was born back 00:14:28.200 --> 00:14:31.279 when the music format wars raged. 00:14:31.280 --> 00:14:38.699 MP3 was the standard, but overshadowed with patent issues. 00:14:38.700 --> 00:14:42.479 In fact, Technicolor and Fraunhofer IIS 00:14:42.480 --> 00:14:45.559 only stopped licensing their patents for MP3 00:14:45.560 --> 00:14:49.359 as recently as April of 2017. 00:14:49.360 --> 00:14:53.539 Jorgen said that, and I quote, 00:14:53.540 --> 00:14:56.079 "I needed a tool that was player agnostic 00:14:56.080 --> 00:14:59.439 and that could deal with a large collection of music files. 00:14:59.440 --> 00:15:02.799 And I did not want any of the GUI music players 00:15:02.800 --> 00:15:04.039 that existed back then. 00:15:04.040 --> 00:15:07.519 Primarily, actually, because I did not want 00:15:07.520 --> 00:15:11.399 to be switching windows to skip to the next song. 00:15:11.400 --> 00:15:12.879 If I remember correctly, 00:15:12.880 --> 00:15:16.279 I had just a shell script before that. 00:15:16.280 --> 00:15:20.159 But I figured I lived in Emacs, so why not write a tool 00:15:20.160 --> 00:15:23.039 that I can control my music from Emacs 00:15:23.040 --> 00:15:27.759 without ever having to leave Emacs?" Unquote. 00:15:27.760 --> 00:15:32.119 We can see that Jorgen's motivations were of the best kind, 00:15:32.120 --> 00:15:35.319 to stay in Emacs. 00:15:35.320 --> 00:15:40.679 Emms, an architecture of sensible abstractions. 00:15:40.680 --> 00:15:44.039 Emms can be divided into a number of parts. 00:15:44.040 --> 00:15:48.119 The core, tracks, playlists, sources, players, 00:15:48.120 --> 00:15:51.759 info, cache, and ancillary. 00:15:51.760 --> 00:15:53.679 Now David J. Wheeler once said 00:15:53.680 --> 00:15:55.999 that all problems in computer science 00:15:56.000 --> 00:15:59.799 can be solved by another level of indirection, 00:15:59.800 --> 00:16:01.639 except of course for the problem 00:16:01.640 --> 00:16:04.419 of too many layers of indirection. 00:16:04.420 --> 00:16:06.999 Emms core has survived this long 00:16:07.000 --> 00:16:11.619 because it makes sensible and flexible coding abstractions. 00:16:11.620 --> 00:16:15.499 Keep this in mind as we explore the implementation. 00:16:15.500 --> 00:16:18.879 This following part of the talk will also be invaluable 00:16:18.880 --> 00:16:21.559 if you want to hack on Emacs. 00:16:21.560 --> 00:16:23.819 Another hint. NOTE The Emms core 00:16:23.820 --> 00:16:25.359 The Emms core. 00:16:25.360 --> 00:16:29.079 The core defines tracks, playlists, 00:16:29.080 --> 00:16:31.759 a way to start and stop playback, 00:16:31.760 --> 00:16:36.439 as well as ways to proceed to the next track. NOTE Tracks 00:16:36.440 --> 00:16:38.459 Tracks: 00:16:38.460 --> 00:16:44.779 Emms tracks consist of a list whose CAR is the symbol track, 00:16:44.780 --> 00:16:47.079 and CADR is an alist starting with 00:16:47.080 --> 00:16:50.639 the association of `type'. 00:16:50.640 --> 00:16:56.739 Type can be something like file, streamlist, URL, etc. 00:16:56.740 --> 00:17:00.079 A track of classical music from Bach's Art of Fugue 00:17:00.080 --> 00:17:04.379 may look something like this. 00:17:04.380 --> 00:17:07.599 While a track may contain many associations, 00:17:07.600 --> 00:17:11.079 the number of associations remains a small constant 00:17:11.080 --> 00:17:14.199 from the perspective of computational steps required 00:17:14.200 --> 00:17:18.459 to find any particular association. NOTE Playlist 00:17:18.460 --> 00:17:20.619 Playlist: 00:17:20.620 --> 00:17:23.479 An Emms playlist consists of an Emacs buffer 00:17:23.480 --> 00:17:26.459 with a buffer-local non-nil variable, 00:17:26.460 --> 00:17:29.819 `emms-playlist-buffer-p`. 00:17:29.820 --> 00:17:33.719 The buffer can contain anything, any amount or type of text, 00:17:33.720 --> 00:17:35.959 or anything else. 00:17:35.960 --> 00:17:40.499 Emms tracks are stored in text properties within the buffer, 00:17:40.500 --> 00:17:46.399 with the unimaginatively named text property `emms-track`. 00:17:46.400 --> 00:17:49.239 For Emms, to go to the next track consists of 00:17:49.240 --> 00:17:52.839 nothing more than looking for the next text property change 00:17:52.840 --> 00:17:57.179 containing `emms-track`, wherever that is. 00:17:57.180 --> 00:18:00.239 That means that there is a healthy decoupling between 00:18:00.540 --> 00:18:03.839 the visual representation of a playlist 00:18:03.840 --> 00:18:08.259 and its contents as far as Emms is concerned. 00:18:08.260 --> 00:18:11.599 This decoupling allows Emms playlist buffers 00:18:11.600 --> 00:18:15.319 to look like anything as long as that anything consists of 00:18:15.320 --> 00:18:22.079 one or more `emms-track` text properties. NOTE Sources 00:18:22.080 --> 00:18:23.579 Sources: 00:18:23.580 --> 00:18:25.839 A source is how you tell Emms: 00:18:25.840 --> 00:18:29.779 "Go and get those things and turn them into tracks." 00:18:29.780 --> 00:18:34.479 More specifically, an Emms source is a function called in 00:18:34.480 --> 00:18:37.259 a playlist buffer in order to add tracks. 00:18:37.260 --> 00:18:40.199 And even more specifically, a source is really 00:18:40.200 --> 00:18:42.679 a family of related functions 00:18:42.680 --> 00:18:47.679 defined by the macro `define-emms-source`. 00:18:47.680 --> 00:18:49.959 A straightforward example 00:18:49.960 --> 00:18:52.959 is the function `emms-add-directory`, 00:18:52.960 --> 00:18:55.879 which adds an entire directory of files 00:18:55.880 --> 00:18:57.439 to the current playlist. 00:18:57.440 --> 00:19:02.319 It accepts, or interactively queries for, a directory 00:19:02.320 --> 00:19:06.119 and iterates over each file in that directory, 00:19:06.120 --> 00:19:10.759 adding them as tracks to the playlist buffer as it goes. 00:19:10.760 --> 00:19:15.039 Emms comes with sources for files, directories, URLs, 00:19:15.040 --> 00:19:17.319 playlists of various formats, 00:19:17.320 --> 00:19:22.159 files from dired mode, and etc. NOTE Players 00:19:22.160 --> 00:19:24.879 Players: 00:19:24.880 --> 00:19:28.959 An Emms player is, at its simplest, a data structure 00:19:28.960 --> 00:19:30.839 with three functions. 00:19:30.840 --> 00:19:34.519 One to start playing, one to stop, 00:19:34.520 --> 00:19:38.179 and one which returns true if the player knows 00:19:38.180 --> 00:19:41.279 how to play a given track. 00:19:41.280 --> 00:19:44.759 However, if your player also knows how to pause, resume, 00:19:44.760 --> 00:19:48.279 seek, etc, then additional functions can be added 00:19:48.280 --> 00:19:51.319 to the player data structure. 00:19:51.320 --> 00:19:55.399 This is abstract enough to be able to, for example, 00:19:55.400 --> 00:19:58.839 define a simple player for images with the help of 00:19:58.840 --> 00:20:04.579 the `define-emms-simple-player` macro. 00:20:04.580 --> 00:20:09.559 The above will define a player called `emms-player-display`, 00:20:09.560 --> 00:20:12.959 which would call ImageMagick's `display` command 00:20:12.960 --> 00:20:15.639 on each file in our playlist 00:20:15.640 --> 00:20:20.519 with the image file extension we listed. NOTE Info 00:20:20.520 --> 00:20:23.059 Info: 00:20:23.060 --> 00:20:28.019 As previously described, Emms comes with info methods, 00:20:28.020 --> 00:20:29.639 which are functions to add 00:20:29.640 --> 00:20:32.339 descriptive information to tracks. 00:20:32.340 --> 00:20:34.639 Emms is set up so that 00:20:34.640 --> 00:20:37.719 the hook `emms-track-initialize-functions` is called 00:20:37.720 --> 00:20:41.639 when a track is created, and that ends up calling 00:20:41.640 --> 00:20:46.279 the info methods listed in the `emms-info-functions` list. 00:20:46.280 --> 00:20:51.199 These will modify the track data structure to add metadata. 00:20:51.200 --> 00:20:54.319 One of the coolest recent features of Emms 00:20:54.320 --> 00:20:58.699 is `emms-info-native`, written by Petteri Hintsanen; 00:20:58.700 --> 00:21:01.325 again, sorry for the pronunciation. 00:21:01.326 --> 00:21:06.519 `emms-info-native` is a purely Emacs Lisp implementation 00:21:06.520 --> 00:21:11.439 which reads Ogg Vorbis, Ogg Opus, FLAC, and MP3 files 00:21:11.440 --> 00:21:14.679 and parses out the metadata. 00:21:14.680 --> 00:21:17.519 This is in comparison with other info readers 00:21:17.520 --> 00:21:20.559 which Emms supports, which all involve calling out 00:21:20.560 --> 00:21:25.619 to external processes and parsing the values returned. 00:21:25.620 --> 00:21:29.319 `emms-info-native` works by unpacking and examining 00:21:29.320 --> 00:21:32.039 the binary data in the media file headers 00:21:32.040 --> 00:21:36.659 and parsing the data layout specifications. NOTE The cache 00:21:36.660 --> 00:21:38.879 The Cache: 00:21:38.880 --> 00:21:43.279 The Emms cache is a mapping between a full path name 00:21:43.280 --> 00:21:45.719 and its associated information. 00:21:45.720 --> 00:21:48.199 Once information is extracted from a file 00:21:48.200 --> 00:21:50.759 using an info method, that information is then 00:21:50.760 --> 00:21:53.979 associated with that file in the cache. 00:21:53.980 --> 00:21:57.159 One thing to bear in mind is that the caching system 00:21:57.160 --> 00:21:58.359 was originally written back 00:21:58.360 --> 00:22:00.759 when slow spinning disks were common. 00:22:00.760 --> 00:22:07.519 A 32GB SSD drive cost close to $700 in 2006, 00:22:07.520 --> 00:22:10.279 which is the equivalent of about $1,000 00:22:10.280 --> 00:22:12.439 at the time of writing. 00:22:12.440 --> 00:22:15.259 But despite the speed of modern drives, 00:22:15.260 --> 00:22:17.439 the caching system is still worth using 00:22:17.440 --> 00:22:19.679 for larger music collections. 00:22:19.680 --> 00:22:22.439 The caching system is also a prerequisite 00:22:22.440 --> 00:22:26.599 for being able to use the Emms browser. 00:22:26.600 --> 00:22:30.379 The cache implementation is relatively naive. 00:22:30.380 --> 00:22:33.199 For instance, moving a file will invalidate 00:22:33.200 --> 00:22:35.799 that cache entry for that file 00:22:35.800 --> 00:22:37.579 and will require a refresh. 00:22:37.580 --> 00:22:40.599 However, relatively little work has been done 00:22:40.600 --> 00:22:42.779 to the cache implementation over the years 00:22:42.780 --> 00:22:44.999 since it has proven to be good enough 00:22:45.000 --> 00:22:47.059 for the majority of situations. 00:22:47.060 --> 00:22:51.619 Which is to say, nobody complained. NOTE Healthy back and forth: mpv, mpd, and GNU.FM 00:22:51.620 --> 00:22:56.239 Healthy back and forth. MPV, MPD, GNU.FM 00:22:56.240 --> 00:23:00.119 Process communication with a simple media player 00:23:00.120 --> 00:23:01.759 can be as straightforward 00:23:01.760 --> 00:23:03.799 as starting an asynchronous process 00:23:03.800 --> 00:23:05.799 and waiting for that process to complete 00:23:05.800 --> 00:23:07.919 in order to move to the next track. 00:23:08.620 --> 00:23:10.879 This is how the example above 00:23:10.880 --> 00:23:13.359 with ImageMagick's display binary worked. 00:23:13.760 --> 00:23:17.439 However, Emms also handles asynchronous 00:23:17.440 --> 00:23:20.299 two-way communication with processes. 00:23:20.300 --> 00:23:23.959 A simple example of this would be sending strings 00:23:23.960 --> 00:23:31.559 to a running process such as the pause command to VLC. NOTE MPV 00:23:31.560 --> 00:23:33.379 MPV: 00:23:33.380 --> 00:23:37.039 MPV is a popular media player forked 00:23:37.040 --> 00:23:39.899 in a roundabout way from mplayer. 00:23:39.900 --> 00:23:42.079 One of its most notable features is 00:23:42.080 --> 00:23:46.599 support for a robust client API. 00:23:46.600 --> 00:23:52.959 Mike Kazantsev has been working since 2018 00:23:52.960 --> 00:23:58.349 to develop the excellent `emms-player-mpv.el'. 00:23:58.350 --> 00:24:01.999 It can communicate with a long running MPV process 00:24:02.000 --> 00:24:07.179 via Unix sockets or IP sockets. 00:24:07.180 --> 00:24:11.169 This allows for MPV to do things 00:24:11.170 --> 00:24:14.889 like update ICY metadata for streaming audio. 00:24:14.890 --> 00:24:17.639 So that, for example, when a song changes 00:24:17.640 --> 00:24:22.049 while you're listening to a streaming audio via Emms, 00:24:22.050 --> 00:24:24.679 the song title displayed in the mode line 00:24:24.680 --> 00:24:28.329 and track listing can update as well. 00:24:28.330 --> 00:24:30.399 This means that deep inside the code 00:24:30.400 --> 00:24:35.629 there is an Emacs `make-network-process` call. 00:24:35.630 --> 00:24:37.919 The fact that Mike has put this together 00:24:37.920 --> 00:24:42.639 in fewer than 1,000 lines of legible Emacs Lisp 00:24:42.640 --> 00:24:47.469 is a testament to some serious coding ability. NOTE MPD 00:24:47.470 --> 00:24:49.609 MPD: 00:24:49.610 --> 00:24:52.399 Similar to MPV but potentially 00:24:52.400 --> 00:24:54.119 on a completely different machine 00:24:54.120 --> 00:24:58.459 is Emms support for the Music Player Daemon. 00:24:58.460 --> 00:25:01.519 Music Player Daemon or MPD is a media player 00:25:01.520 --> 00:25:03.959 with an explicit client-server design 00:25:03.960 --> 00:25:09.949 and communicates with Emms via a network process. 00:25:09.950 --> 00:25:16.089 Unfortunately, MPD support has never been all that great. 00:25:16.090 --> 00:25:20.469 But this isn't the emms developers fault! 00:25:20.470 --> 00:25:25.599 Because unlike every other media player 00:25:25.600 --> 00:25:29.729 that Emms interfaces with MPD is designed around 00:25:29.730 --> 00:25:31.929 its own internal playlist database. 00:25:31.930 --> 00:25:35.269 This is a surprising design decision 00:25:35.270 --> 00:25:37.649 on the MPD developers' part 00:25:37.650 --> 00:25:41.749 since it goes against the client-server mindset. 00:25:41.750 --> 00:25:45.959 A consequence is that we end up having to try and coordinate 00:25:45.960 --> 00:25:51.399 and harmonize the MPD playlist with the Emms playlist. 00:25:51.400 --> 00:25:56.689 I can foresee writing a completely new MPD mode for Emms 00:25:56.690 --> 00:26:01.509 which is designed to be a true pure MPD client. 00:26:01.510 --> 00:26:05.339 Unless of course someone volunteers to beat me to it. 00:26:05.340 --> 00:26:07.439 Hint hint. NOTE GNU FM and Libre FM 00:26:07.440 --> 00:26:10.959 GNU FM and Libre FM: 00:26:10.960 --> 00:26:13.639 Libre FM is a music community which allows you 00:26:13.640 --> 00:26:17.449 to share your listening habits with other users of the site. 00:26:17.450 --> 00:26:21.269 A kind of online listening party. 00:26:21.270 --> 00:26:25.649 In the case of `emms-librefm-scrobber.el` 00:26:25.650 --> 00:26:28.639 we use Emacs' `url-retrieve` function 00:26:28.640 --> 00:26:32.449 to asynchronously send to a URL 00:26:32.450 --> 00:26:40.049 and then fire a callback function to process the response. 00:26:40.050 --> 00:26:42.679 This represents numerous challenges 00:26:42.680 --> 00:26:45.089 to implement within Emacs. 00:26:45.090 --> 00:26:47.399 The primary issue being that Emacs itself 00:26:47.400 --> 00:26:50.099 is pretty weak at doing anything 00:26:50.100 --> 00:26:54.219 truly and really asynchronously. 00:26:54.220 --> 00:26:56.399 I can say with confident sarcasm 00:26:56.400 --> 00:26:59.529 and with tongue firmly planted in cheek 00:26:59.530 --> 00:27:02.879 that it is almost as if the original designers 00:27:02.880 --> 00:27:05.839 of Emacs didn't foresee their text editor 00:27:05.840 --> 00:27:07.039 needing to play music 00:27:07.040 --> 00:27:09.819 while interacting with a remote network server. 00:27:09.820 --> 00:27:12.559 How myopic! NOTE How we work: Emms development 00:27:12.560 --> 00:27:15.699 How we work: Emms development: 00:27:15.700 --> 00:27:19.619 This part is an overview of how Emms is developed. 00:27:19.620 --> 00:27:23.899 By the end of this part you should be able to understand 00:27:23.900 --> 00:27:28.719 how we hacked this project, and how you can too. 00:27:28.720 --> 00:27:29.949 Where it's at. 00:27:29.950 --> 00:27:32.369 How to find our forge. 00:27:32.370 --> 00:27:36.499 Emms has been hosted at the FSF's forge, Savannah, 00:27:36.500 --> 00:27:39.839 since around 2003. 00:27:39.840 --> 00:27:46.229 Emms is distributed via GNU ELPA and integrated into Emacs. 00:27:46.230 --> 00:27:49.799 Before ELPA it was distributed as a tarball 00:27:49.800 --> 00:27:55.139 via ftp.gnu.org but that stopped back in 2020. 00:27:55.140 --> 00:27:58.719 I was initially resistant to ELPA but around the time 00:27:58.720 --> 00:28:03.849 when the thousandth person asked me why Emms isn't on ELPA, 00:28:03.850 --> 00:28:07.209 I realized that it had to happen. 00:28:07.210 --> 00:28:10.599 Emms can also be found in other places 00:28:10.600 --> 00:28:16.079 such as Melpa or GitHub but we, the developers of Emms, 00:28:16.080 --> 00:28:17.999 have nothing to do with that 00:28:18.000 --> 00:28:21.759 and we don't monitor those channels. 00:28:21.760 --> 00:28:26.299 If you want the source straight from, well, the source, 00:28:26.300 --> 00:28:30.369 then go to the Savannah Git repository. 00:28:30.370 --> 00:28:34.989 Look who's talking: Where development discussion happens. 00:28:34.990 --> 00:28:37.999 If you want to talk to us, discussions all happen 00:28:38.000 --> 00:28:41.429 on emms-help@gnu.org. 00:28:41.430 --> 00:28:45.559 We used to use emms-patches@gnu.org 00:28:45.560 --> 00:28:48.279 but didn't feel like the volume of incoming patches 00:28:48.280 --> 00:28:52.589 justified a separate mailing list. NOTE The Rime Of The Ancient Maintainer 00:28:52.590 --> 00:28:55.719 The Rime Of The Ancient Maintainer: 00:28:55.720 --> 00:28:57.479 There are a number of activities 00:28:57.480 --> 00:29:00.099 particular to being a maintainer. 00:29:00.100 --> 00:29:03.389 These are all part of a project's lifecycle. 00:29:03.390 --> 00:29:06.079 Let's review some of them. NOTE The life and times of an Emms patch 00:29:06.080 --> 00:29:09.999 The life and times of an Emms patch: 00:29:10.000 --> 00:29:13.239 A maintainer needs to be able to accept, critique, 00:29:13.240 --> 00:29:17.559 and integrate patches from contributors and developers. 00:29:17.560 --> 00:29:20.559 This means, among other things, that the maintainer 00:29:20.560 --> 00:29:24.469 needs to keep on top of copyright issues. 00:29:24.470 --> 00:29:29.359 Before being able to add Emms to GNU/ELPA, 00:29:29.360 --> 00:29:31.879 we had to make sure that the copyright situation 00:29:31.880 --> 00:29:33.849 was in order. 00:29:33.850 --> 00:29:37.519 This long process required reaching out to people 00:29:37.520 --> 00:29:39.959 and having them assign the copyright 00:29:39.960 --> 00:29:42.509 for their work to the FSF, 00:29:42.510 --> 00:29:45.199 or even removing their code entirely 00:29:45.200 --> 00:29:47.969 if they couldn't be reached. 00:29:47.970 --> 00:29:50.629 The experience left me with the conviction 00:29:50.630 --> 00:29:52.399 that the easiest way to fix 00:29:52.400 --> 00:29:54.519 the copyright situation of your package 00:29:54.520 --> 00:30:00.639 is to ensure that it never gets broken in the first place. 00:30:00.640 --> 00:30:04.439 Often a person will write in to the emms-help mailing list, 00:30:04.440 --> 00:30:08.029 or perhaps raise an issue on IRC. 00:30:08.030 --> 00:30:11.679 If it's a bug report or feature request, we'll discuss it, 00:30:11.680 --> 00:30:14.159 and when it's fixed, we'll ask the reporter 00:30:14.160 --> 00:30:17.639 to test the result and provide feedback. 00:30:17.640 --> 00:30:22.039 If it's a patch, then we'll typically go one of three ways. 00:30:22.040 --> 00:30:24.799 A trivial patch, such as fixing a typo 00:30:24.800 --> 00:30:27.279 or corrections on a single line of code, 00:30:27.280 --> 00:30:32.039 will simply be applied by one of the developers. 00:30:32.040 --> 00:30:34.519 A non-trivial, but one-time patch, 00:30:34.520 --> 00:30:37.989 will have to be cleared from a copyright perspective. 00:30:37.990 --> 00:30:42.419 This means assigning copyright for the changes to the FSF. 00:30:42.420 --> 00:30:46.319 Once that's cleared, then the patch will be applied. 00:30:46.320 --> 00:30:49.879 Finally, if it's a non-trivial patch, 00:30:49.880 --> 00:30:52.079 which looks like it would be the start 00:30:52.080 --> 00:30:56.009 of a long-term development work (my favorite), 00:30:56.010 --> 00:30:57.879 then after copyright is cleared, 00:30:57.880 --> 00:31:00.799 that person will be offered to be added 00:31:00.800 --> 00:31:05.019 to the members with Git repo access on Savannah. 00:31:05.020 --> 00:31:08.199 From there, we usually use a dedicated branch 00:31:08.200 --> 00:31:09.639 to do all the playing around 00:31:09.640 --> 00:31:13.629 before merging it with the main Git repo. 00:31:13.630 --> 00:31:16.879 If you have ever sent a patch, feature request, 00:31:16.880 --> 00:31:24.079 or bug report into Emms (small or large), we thank you. NOTE Let It Go: The release process 00:31:24.080 --> 00:31:27.789 Let It Go, The Release Process: 00:31:27.790 --> 00:31:31.609 The maintainer is responsible for the release process. 00:31:31.610 --> 00:31:35.129 I found that a consistent schedule works well, 00:31:35.130 --> 00:31:39.379 which is not to say that we have to release on schedule, 00:31:39.380 --> 00:31:42.759 but that aiming for a consistent release schedule 00:31:42.760 --> 00:31:46.049 provides structure and a goal. 00:31:46.050 --> 00:31:50.159 The main Git branch in the repository is stable 00:31:50.160 --> 00:31:53.239 and more often than not of release quality. 00:31:53.240 --> 00:31:56.649 Releases are done about every three months. 00:31:56.650 --> 00:31:58.999 And with such a stable main branch, 00:31:59.000 --> 00:32:02.319 the process of releasing often involves little more 00:32:02.320 --> 00:32:05.059 than writing a NEWS entry. 00:32:05.060 --> 00:32:08.439 As a consequence, new and wonderful features 00:32:08.440 --> 00:32:11.439 which aren't quite ready for prime time 00:32:11.440 --> 00:32:13.499 when a release comes around, 00:32:13.500 --> 00:32:18.199 will remain safely in their branch on the Git repo 00:32:18.200 --> 00:32:23.399 until after the ELPA release. NOTE It Is Not In Our Stars, But In Ourselves: Future directions 00:32:23.400 --> 00:32:29.629 It Is Not In Our Stars, But In Ourselves; Future Directions: 00:32:29.630 --> 00:32:34.899 One aspect of Emms that needs to improve is ease of setup. 00:32:34.900 --> 00:32:37.719 Now that might surprise you, since at the time of writing, 00:32:37.720 --> 00:32:40.069 it's already pretty easy. 00:32:40.070 --> 00:32:43.879 But my ideal is that the user would need to do 00:32:43.880 --> 00:32:46.839 nothing at all after installation. 00:32:46.840 --> 00:32:49.359 And with that, as a goal in mind, 00:32:49.360 --> 00:32:52.749 there is more work to be done. 00:32:52.750 --> 00:32:55.499 We are working on a player discovery feature. 00:32:55.500 --> 00:32:57.039 The idea is simple. 00:32:57.040 --> 00:33:00.079 The code looks for binaries of popular media players 00:33:00.080 --> 00:33:01.639 on the user's machine, 00:33:01.640 --> 00:33:04.519 and for each one found, it asks the user 00:33:04.520 --> 00:33:07.519 if they want the associated Emms player backend 00:33:07.520 --> 00:33:09.809 to be configured. 00:33:09.810 --> 00:33:12.589 In effect, this code is already working, 00:33:12.590 --> 00:33:16.289 but currently an undocumented, unofficial feature. 00:33:16.290 --> 00:33:17.719 You can try it for yourself with 00:33:17.720 --> 00:33:21.079 `emms-setup-discover-players`. 00:33:21.080 --> 00:33:22.969 So what's the holdup? 00:33:22.970 --> 00:33:26.039 `emms-setup-discover-players` currently configures 00:33:26.040 --> 00:33:27.839 the `emms-player-list` variable, 00:33:27.840 --> 00:33:29.899 but doesn't write it to disk. 00:33:29.900 --> 00:33:31.679 And that means that the configuration 00:33:31.680 --> 00:33:35.039 isn't preserved between Emacs sessions. 00:33:35.040 --> 00:33:36.899 The question then becomes, 00:33:36.900 --> 00:33:40.309 what is the best way to preserve this setting? 00:33:40.310 --> 00:33:42.599 I personally don't like anything 00:33:42.600 --> 00:33:46.199 to edit my .emacs except me, 00:33:46.200 --> 00:33:49.279 and I wouldn't do that to anyone else. 00:33:49.280 --> 00:33:55.959 Now we already write state to the .emacs.d/emms/ directory, 00:33:55.960 --> 00:33:58.359 but that would require care not to 00:33:58.360 --> 00:34:01.909 clobber a user's existing setup. 00:34:01.910 --> 00:34:04.719 Having the user set up their system in one place, 00:34:04.720 --> 00:34:08.839 such as a .emacs or a .emmsrc, 00:34:08.840 --> 00:34:11.419 while saving state to a different place 00:34:11.420 --> 00:34:14.209 is asking for confusion. 00:34:14.210 --> 00:34:16.719 This is a good example which I bring up 00:34:16.720 --> 00:34:18.399 of where a maintainer needs to 00:34:18.400 --> 00:34:21.308 solicit opinions from developers, 00:34:21.309 --> 00:34:23.899 both the Emacs developers, 00:34:23.900 --> 00:34:28.169 asking them where packages should save state, 00:34:28.170 --> 00:34:33.169 and the Emms developers, and also users. 00:34:33.170 --> 00:34:35.439 Then, the maintainer needs to 00:34:35.440 --> 00:34:38.019 carefully choose a path forward. 00:34:38.020 --> 00:34:41.559 It is typical of the kind of issue you have to have in mind 00:34:41.560 --> 00:34:44.848 when you're maintaining a package. NOTE Development policies: Interface language 00:34:44.849 --> 00:34:49.159 Development Policies: Interface Language. 00:34:49.160 --> 00:34:52.359 A maintainer of an interactive program such as Emms 00:34:52.360 --> 00:34:55.359 needs to think about user interaction. 00:34:55.360 --> 00:34:58.399 Emms doesn't use key bindings which are familiar 00:34:58.400 --> 00:35:02.719 to people who are used to GUI media players, 00:35:02.720 --> 00:35:06.559 and that can, and has, caused friction. 00:35:06.560 --> 00:35:09.959 Some new users are confused when they press the spacebar 00:35:09.960 --> 00:35:12.529 on an entry in the Emms browser, 00:35:12.530 --> 00:35:15.459 only to find that nothing starts playing. 00:35:15.460 --> 00:35:18.679 Indeed, all that does is to expand the browser tree 00:35:18.680 --> 00:35:20.469 at that point. 00:35:20.470 --> 00:35:22.999 Then they might press RET on the same entry, 00:35:23.000 --> 00:35:28.259 and be further frustrated at the continuing silence. 00:35:28.260 --> 00:35:33.399 Since what return does is just to add that entry at point 00:35:33.400 --> 00:35:36.169 to the current playlist. 00:35:36.170 --> 00:35:37.759 The discussion then arises 00:35:37.760 --> 00:35:41.819 about how Emms should handle that situation. 00:35:41.820 --> 00:35:45.559 On one hand, we want to make it as easy as possible 00:35:45.560 --> 00:35:48.819 for new users to learn Emms, 00:35:48.820 --> 00:35:52.759 and adopt a do-what-I-mean interface approach. 00:35:52.760 --> 00:35:56.749 On the other hand, this is an Emacs project. 00:35:56.750 --> 00:35:59.439 It isn't a stand-alone GUI media player, 00:35:59.440 --> 00:36:01.399 and should integrate into Emacs, 00:36:01.400 --> 00:36:05.979 and serve Emacs users first and foremost. NOTE Development policies: Freedom 00:36:05.980 --> 00:36:10.289 Development policies: Freedom. 00:36:10.290 --> 00:36:14.999 Another maintainer job is to think of Emms' posture 00:36:15.000 --> 00:36:17.379 in regards to software freedom. 00:36:17.380 --> 00:36:19.729 Here are a few examples. 00:36:19.730 --> 00:36:23.759 Back with MP3 was still a patent encumbered format, 00:36:23.760 --> 00:36:26.080 we pushed hard for Vorbis everywhere 00:36:26.081 --> 00:36:29.639 along with the PlayOgg campaign. 00:36:29.640 --> 00:36:32.699 A then popular music streaming service, 00:36:32.700 --> 00:36:34.929 which will remain unnamed, 00:36:34.930 --> 00:36:38.619 changed their stance towards third-party applications, 00:36:38.620 --> 00:36:43.129 and required individual API keys which could not be shared. 00:36:43.130 --> 00:36:45.399 We stood firm, said "no", 00:36:45.400 --> 00:36:48.669 and removed support for that service. 00:36:48.670 --> 00:36:51.359 A recent suggestion to add support for YouTube 00:36:51.360 --> 00:36:53.889 was also nixed, 00:36:53.890 --> 00:36:55.679 because the particular backend 00:36:55.680 --> 00:36:58.959 was found to download and run proprietary javascript 00:36:58.960 --> 00:37:01.849 on the user's machine. 00:37:01.850 --> 00:37:05.399 Saying no to potentially useful or wanted features 00:37:05.400 --> 00:37:07.919 because it involves non-free software 00:37:07.920 --> 00:37:13.489 is often an unpopular decision and can alienate people. 00:37:13.490 --> 00:37:15.559 A maintainer needs to think carefully 00:37:15.560 --> 00:37:17.399 about each of these decisions, 00:37:17.400 --> 00:37:21.919 as they are rarely straightforward and one-sided. 00:37:21.920 --> 00:37:25.839 And as you see above, they also change over time 00:37:25.840 --> 00:37:30.299 and need to be re-evaluated. 00:37:30.300 --> 00:37:32.999 One of the most useful things a maintainer can do 00:37:33.000 --> 00:37:35.519 is to coordinate the development effort 00:37:35.520 --> 00:37:39.229 and help new people join the project. 00:37:39.230 --> 00:37:41.839 In light of that, if you want to work on a project 00:37:41.840 --> 00:37:44.059 which has a bit of everything, 00:37:44.060 --> 00:37:47.809 you could do worse than hacking on Emms. 00:37:47.810 --> 00:37:49.719 There is inter-process communication, 00:37:49.720 --> 00:37:52.479 displaying graphics, parsing binary files, 00:37:52.480 --> 00:37:56.529 caching, asynchronous processes, user interface design. 00:37:56.530 --> 00:37:59.599 We also are a project that insists on 00:37:59.600 --> 00:38:02.959 keeping a well-written and up-to-date manual. 00:38:02.960 --> 00:38:06.759 If you can write English or hack Emacs Lisp at all, 00:38:06.760 --> 00:38:09.939 chances are that there is something you can do for Emms. 00:38:09.940 --> 00:38:12.369 Just saying. NOTE Acknowledgements 00:38:12.370 --> 00:38:14.189 Acknowledgements: 00:38:14.190 --> 00:38:18.079 I'd like to express my deep gratitude for all of the people 00:38:18.080 --> 00:38:19.559 who have hacked on Emms 00:38:19.560 --> 00:38:23.169 during my time as a maintainer and before it. 00:38:23.170 --> 00:38:25.759 It is often the case that I'm just the person 00:38:25.760 --> 00:38:28.559 holding the rudder and steering the ship, 00:38:28.560 --> 00:38:30.039 with all of these developers 00:38:30.040 --> 00:38:33.179 rowing furiously to provide the power 00:38:33.180 --> 00:38:36.369 which actually moves the ship forward. 00:38:36.370 --> 00:38:38.040 Thank you to all.