path: root/2023/captions/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main.vtt

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.