Automated commit

2 files changed, 2128 insertions, 0 deletions

diff --git a/2023/captions/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main--chapters.vtt b/2023/captions/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main--chapters.vtt
new file mode 100644
index 00000000..f183a115
--- /dev/null
+++ b/2023/captions/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main--chapters.vtt
@@ -0,0 +1,80 @@
+WEBVTT
+
+
+00:00:00.000 --> 00:01:03.319
+Introduction
+
+00:01:03.320 --> 00:01:21.319
+The structure of this talk
+
+00:01:21.320 --> 00:08:04.239
+Introduction to Emms: The practical part
+
+00:08:04.240 --> 00:11:01.199
+The modeline
+
+00:11:01.200 --> 00:11:29.859
+Meta-playlist mode
+
+00:11:29.860 --> 00:13:19.919
+The browser
+
+00:13:19.920 --> 00:16:23.819
+How Emms works: The technical part
+
+00:16:23.820 --> 00:16:36.439
+The Emms core
+
+00:16:36.440 --> 00:17:18.459
+Tracks
+
+00:17:18.460 --> 00:18:22.079
+Playlist
+
+00:18:22.080 --> 00:19:22.159
+Sources
+
+00:19:22.160 --> 00:20:20.519
+Players
+
+00:20:20.520 --> 00:21:36.659
+Info
+
+00:21:36.660 --> 00:22:51.619
+The cache
+
+00:22:51.620 --> 00:23:31.559
+Healthy back and forth: mpv, mpd, and GNU.FM
+
+00:23:31.560 --> 00:24:47.469
+MPV
+
+00:24:47.470 --> 00:26:07.439
+MPD
+
+00:26:07.440 --> 00:27:12.559
+GNU FM and Libre FM
+
+00:27:12.560 --> 00:28:52.589
+How we work: Emms development
+
+00:28:52.590 --> 00:29:06.079
+The Rime Of The Ancient Maintainer
+
+00:29:06.080 --> 00:31:24.079
+The life and times of an Emms patch
+
+00:31:24.080 --> 00:32:23.399
+Let It Go: The release process
+
+00:32:23.400 --> 00:34:44.848
+It Is Not In Our Stars, But In Ourselves: Future directions
+
+00:34:44.849 --> 00:36:05.979
+Development policies: Interface language
+
+00:36:05.980 --> 00:38:12.369
+Development policies: Freedom
+
+00:38:12.370 --> 00:38:38.040
+Acknowledgements
diff --git a/2023/captions/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main.vtt b/2023/captions/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main.vtt
new file mode 100644
index 00000000..ecbed3fb
--- /dev/null
+++ b/2023/captions/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main.vtt
@@ -0,0 +1,2048 @@
+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.