GitHub Actions in Action: Automation for Digital Music Editions

This article is based on a talk given at the Music Encoding Conference (MEC 2026) in Tokyo on 28 May 2026
by Julia Maria Jaklin, Henning Burghoff, David M. Weigl.

Abstract:

In the E-LAUTE project, lute music from the German-speaking world of the 15th and 16th centuries (Fig. 1) is being edited and made available as a digital edition. The edition consists of several thousand files, which the project team keeps internally in around 50 so-called repositories, one for each historical source: online storage spaces that record every change as a separate version. We work with established editing tools, but they don’t cover every requirement of our project, so a lot still has to be done by hand. Every file needs, for example, a header with information about the source and who worked on it, page turns have to be linked to the digitised images of the original source, and before publication we check everything against our editorial guidelines.

 Fig. 1: “Zart Schönste Fraw” in German lute tablature, A-Wn Cod. 9704, fols. 28v–30r.

So the question was: how can we automate these steps in a way that fits as smoothly as possible into the way our editors already work? Since we manage our files on GitHub anyway, a widely used platform for collaborative, versioned work on data and program code, we chose to work with GitHub Actions. With them, GitHub can open files at the click of a button, apply prepared programs to them and save the result as a new version. Sounds good – but usually, such a workflow has to be set up separately in every repository. For us, that would mean setting everything up 50 times.

So the first step was to separate the data from the automation. We keep the programs together in a single central repository, while the repositories holding the music data contain only a short reference to it (Fig. 2). When a workflow is started, GitHub brings the two together, processes the files and saves the changes back. That way, changes to the programs only need to be made in one place, and other projects can use the central repository too or set up their own in the same way.

Fig 2: The project’s repositories (left) draw on a shared central repository containing the automation (centre); repositories of other projects can use it too (right).

Our editors hardly notice any of this, because the feature is built into mei-friend, an online editor for digital music developed at mdw. If, for example, the line breaks in a newly digitised piece need to be reset, this no longer has to be done by hand: the GitHub menu in mei-friend can be opened, the matching task chosen from a list, the interval set to a new line after every third measure, and the workflow started. A progress bar shows what is happening, and a few moments later the updated piece can be viewed.

We will keep expanding the automation in E-LAUTE, and it also forms the basis of the Let’s Encode project. It doesn’t replace editorial work, but it can take recurring routine tasks off the editors’ hands. If you would like to try the approach in your own project, you can find a guide and templates here: https://mei-friend.github.io/docs/advanced/automation

Funded by the Austrian Science Fund (FWF): https://doi.org/10.55776/I6019 and https://doi.org/10.55776/PAT2277625