Skip to content

Overview of AMADS: Algorithms for Music Analysis and Data Science

Summary

A great deal of our musical heritage exists and survives in sheet music: scores with notes, rests, dynamics, articulation, and the like. The equivalent digital encoding is generally called “symbolic” music. And while some may associate this with Western classical music, it serves styles and repertoires far beyond that (jazz leadsheets, Korean traditional music, …).

The last few decades have seen a growing body of work focused on this data, and therefore the emergence of many algorithms for analysis. Algorithms for Music Analysis and Data Science (AMADS) aims to provide a summary of those algorithms, bringing them together in a coherent way in relation to new standards for encoding. In so doing, it also fills in some gaps that this process identifies, and expands into some new areas.

Statement of need

We begin with some high-level observations will serve to provide the context and motivation for this topic.

  • Music computing is not a large field. There are wonderful, enthusiastic practitioners, but rather few of us relative to more populous fields.
  • Related, music computing is somewhat disparate, with those practitioners spread out across the world, and with sub-fields like MIR, music theory, and music psychology having rather limited interaction, at least relative to the clearly shared goals, tasks, and data.
  • Educational resources can serve not only as material for preparing specific classes, but also as a vehicle for consolidating the field e.g., textbooks can function both for teaching and as reference books for experts.
  • Code libraries can likewise serve as another gathering point, supporting both newcomers with "how to“ guides and consolidating the field for expert practitioners.

While some parts of the music computing landscape are relatively well served with code libraries (e.g., tool-based libraries for extracting data from audio such as librosa and madmom), there has been little by way of libraries for consolidating algorithms across the music computing, and so the coverage continues to be patchy and disparate.

There have been several promising initiatives that draw together algorithms in a particular area. These include ”OMNISIA“ (Meredith et al. for pattern finding in Java), ”synpy“ (Song et al., for rhythmic syncopation in Python). and the “midi toolbox” (Toiviainen and Eerola, for melodic contour and more in Matlab). These are welcome efforts, but they are expressed in different code languages, address a narrow scope, and in at least some cases, are no longer maintained.

Then there are larger libraries that could serve to draw this together. At one time humdrum was a/the central point of reference. That continues to be used and maintained (an impressive 40 years later!), but there are downsides, e.g., the 'language neutral' set up is commendable, but not very inviting for newcomers with expectations based on the landscape of today.

Later, music21 was introduced. First published in 2010/11, this too continues to be maintained and used. That said, the creator-maintainer recently made the explicit decision (announced/reported here) that it is not or no longer there to provide the holistic directory function stated here. Instead, it specifically invites niche projects to go solo, with or without music21 as a dependency.

Partitura is arguably one such project, though it explicitly suggests using music21 instead if “you are working in computational musicology.”

Students and researchers wishing to explore a topic therefore have to do a lot of “spade-work” to compare any new algorithm with existing work, or even to make use of those existing algorithms. In short, given this state of affairs, and following conversation with the maintainers of all those code libraries, it is clear that we need a new coordination effort drawing together the work cited above in a more coordinated fashion.

Philosophy

AMADS seeks to address the above need, serving primarily to bring together these algorithms. We seek to be as user-friendly as possible, serving as a welcoming introduction to those new to the field, and a helpful reference library for those already active.

There is a spectrum of options we could have taken in pursuing these goals. One extremely light-touch option we considered was to simply list the resources out there. This alone would have provided the field some manner of synthesis and sign-posting. We decided on the more ambitious and extensive undertaking seen here as many useful functions have no public implementation, or else an implementation in an all-but obsolete language. Pointing users to those sources would be of limited use. Much better instead to provide an implementation in those cases.

Where existing code packages are publicly available and clearly maintained by a person or team that is/are both explicitly named and currently active, we aim to avoid re-implementation, and focus instead on providing an ecosystem that incorporates those packages as dependencies via an API. As such, AMADS serves as a kind of meta-package, with a unified Python API for accessing both new code and other relevant packages in one place.

There are trade-offs here. This meta-package scope necessarily makes the overall design less consistent than it might be if we reimplemented everything from scratch. Overall, we consider this an acceptable balance; we consider the current approach the best way to invest time in serving the field and building on what has been accomplished already, particularly where those external packages are likely to expand and develop further.

In keeping with the above, we will gladly consider pull request (PR) contributions that build on any of those packages (IDyoM, music21, Partitura, ...). We reserve the right to later refactor the inner workings, and will in such cases aim to keep details of the user-experience API consistent in terms of input/output and result, as well as follow semantic versioning for any breaking changes.

Another tradeoff has to do with underlying representations. For each algorithm, there is likely to be a “natural” representation of the essential information where non-essential information is excluded, for example, lists of pitches without duration or dynamics. It is tempting to use these representations, but that leads to a proliferation of data readers, writers, converters and filters. This might simplify the implementation of algorithms, but then one cannot simply apply any analysis to any musical data object because the information required by the algorithm may have been abstracted away. AMADS tends to retain more information in its representation but offers an object-oriented approach where algorithms can efficiently extract whatever information they need.

Acknowledgements

We strive to cite all involved in the research gathered here. All contributors to the new repository appear in the commit history and are generally listed as authors of the respective files. The design of this code library is informed by conversations with all relevant precedents (including those cited above). Many thanks to those developers, and to the new ones. Finally, we thank Dagstuhl for supporting seminar number 24302 which helped advance these plans, not least by putting Gotham and Dannenberg together.