diff options
Diffstat (limited to '2023/captions/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main.vtt')
| -rw-r--r-- | 2023/captions/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main.vtt | 2048 |
1 files changed, 2048 insertions, 0 deletions
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. |