Music producers nowadays rely on increasingly large libraries of loops, samples and virtual instrument sounds as part of the composition process. Intelligent interfaces are therefore useful in enabling navigation of these databases in a way that supports the production workflow. Within virtual drumming software, producers typically rely on large libraries of symbolic drum loops. Due to their large size, navigating and exploring these libraries can be a dificult process. To address this, preliminary work is presented into the Groove Explorer. Using Self-Organizing Maps, a large library of symbolic drum loops is automatically mapped on a 2D space according to rhythmic similarity. This space can then be explored via a Max/MSP prototype interface. Early results suggest that while the algorithm works well for smaller datasets, further development is required, particularly in the similarity metric used, to make the tool scalable to large libraries.
• Applied computing → Sound and music computing; • Information systems → Clustering and classification ; • Computing methodologies → Machine learning.
IUI Workshops’19, March 20, 2019, Los Angeles, USA © 2019 for the individual papers by the papers’ authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors
Since the early days of Music Information Retrieval (MIR) as a
research field, one significant topic of research has been in the
intelligent visual organization of music data as a means of managing
and understanding the increasingly large quantities of data arising
from advances in music content digitization [
An example of this problem is found within the symbolic drum
loop libraries used in virtual drumming software. Software
emulations of drum kits are finding increasing use in music production for
generating realistic, expressive drum kit parts ‘in the box’, without
requiring recording equipment, a drum kit or a drummer. Examples
of this kind of software include SuperiorDrummer [
These pieces of software work by combining a drum synthesis engine with a pattern library to sequence the sounds into realistic, idiomatic and expressive drumming. In BFD there are roughly 2500 of these sequences, referred to as G` rooves´, within the Core library, but thousands more in third-party addons and expansion packs. Unfortunately, this library can be very dificult to navigate; as well as being very large, it uses limited metadata and names which can be dificult to interpret.
To address this problem, we present ongoing development of
the Groove Explorer, a prototype tool for visual exploration of this
symbolic drum loop library. Using Self-Organizing Maps (SOMs)
[
First, related work that inspired this project will be discussed. Then the details of the mapping algorithm will be described, along with implementation details of the prototype tool. Then, the results of an initial evaluation on the algorithm’s output mapping quality will be presented. Finally, conclusions will be made considering the limitations of the algorithm and evaluation methodology, and an outline of further research will be provided. 2
A growing body of work now attempts to use MIR to address the
limitations of DAW-based music production. The development of
intelligent visual navigation tools for the many types of data libraries
used in music production is a significant area of this research. By
automatically sorting music data according to similarity, it is
suggested that visualizations can make it quicker, easier and more
enjoyable to find music data [
A particular focus has been in improving the navigation of drum
sample libraries. In [
There has similarly been research specifically into the
exploration of loops. In [
The core mapping algorithm used in the Groove Explorer is the
Self-Organizing Map (SOM). The SOM, first developed by Teuvo
Kohonen [
In addition to the radius function, a learning rate reduces the amount of updating over time, ensuring the map converges over its training period. To calculate similarity between input vectors and node vectors, a Euclidean distance function is typically used, although any similarity metric can be used. Once the map has been trained, the final map can be generated of the winner node position for each input data item. As each data item is mapped onto a node, to capture the topological structure of the input data, the number of neurons must be large compared to the number of input data items.
It is possible to perform additional clustering operations on the
output map to aid visualization. The U-matrix is a popular visual
clustering method for the SOM that shows distances between
neighboring node vectors as a heatmap [
To feed into the SOM, raw symbolic drum loops were represented as 160-point feature vectors. The input loops were all 2 bars in length, reduced to 5-part polyphony, and quantized to semiquaver time steps (16 per bar), with velocities for each hit. Each time step for each part was therefore a point on the feature vector. All of the loops were in 4/4 time. While the raw loops used 10-part polyphony, some of the parts were grouped by functional and timbral similarity, as shown in Table 1. The calculation of the SOM relies on a similarity metric to calculate the diference between individual Groove vectors and nodes.
Ensuring this similarity metric is musically and perceptually valid is crucial to ensure the output mapping correlates with the user’s perception of similarity between drum loops in the space.
While the edit or swap distance is considered by some to be the
most robust metric for calculating monophonic rhythm similarity
[
BFD’s Grooves also have velocities for each hit, ranging between 0 for silence, and 1 for the loudest hit. To account for continuous Groove Explorer: An Intelligent Visual Interface for Drum Loop Library Navigation IUI Workshops’19, March 20, 2019, Los Angeles, USA velocity values, a Euclidean vector distance function is an appropriate technique that is analogous to a coincidence-based metric like Hamming distance in that it computes a measure of the combined distance between corresponding points in the vectors. 4
The code for all feature construction and SOM
computation was written in Python 2.7, and can be accessed at
https://github.com/fredbru/musicsom. For training the SOM, scripts
for both CPU and GPU computation were written for added
flexibility, but GPU computation was used for the large maps due to
increased speed. The GPU SOM code was written using CUDA
via the Numba just-in-time compiler Python library [
With non-4/4 Grooves removed, the BFD Core dataset contains approximately 2300 Grooves. The Grooves are structured and tagged in terms of 12 genres and 59 ‘Palettes’. Palettes represent sub-groups of loop style, each containing around 20-40 similar Grooves, with names such as ‘Smooth Jazz’ and ‘Trash Metal’. Each Groove in one Palette is therefore of the same genre. 4.1
For interactively navigating the Groove map, the prototype Groove Explorer was designed in Max/MSP, the UI of which is shown in Figure 1. The Max/MSP patch loads the SOM output maps as JSON ifles of Groove metadata and map coordinates. Each circular object represents a Groove, which is played back when clicked. The user can zoom in and pan across the map, and save Grooves in their own custom bank within BFD. It is possible to switch between coloring Grooves according to genre and according to Palette. TCP/IP socket to a Python background script. This script then parses these messages to generate commands in the right format for a Lua interface used for BFD scripting. Important features of BFD, such as its drum sample playback engine and audio mixing features can therefore be accessed alongside the Groove Explorer. Additionally, Python integration opens up the future possibility of real-time updating of the SOM from the UI. 5
A pilot evaluation of the mapping quality of the Groove Explorer was carried out using Palette and genre tags provided in the software as a benchmark. To assess the ability of the SOM to separate Palettes, the subgenre groupings in the dataset, a smaller map was ifrst generated using a group of 8 Palettes, one for each major genre, for a total of 252 Grooves. To test the ability of the Groove Explorer to represent the structure of the data on a large scale, a map of the whole BFD Core Groove library was generated, with genre tags used to ofer a higher-level indicator of similarity correlating with human categorization. The small SOM dimensions were 16x16 nodes and the larger 80x60. The small map was trained on the CPU of a Dell XPS-15 9550 laptop running Ubuntu 18.10, for a training time of 30 minutes, or 2000 epochs. Due to its much larger size, the larger map was trained using a NVIDIA Tesla P100 GPU, for a training time of 3 days, or 3500 epochs.
The SOM output was plotted as the winner node positions for each Groove overlaid over the U-matrix. That way as well as observing the map positions of groove, it was possible to evaluate the ability of the algorithm to perform clustering. 6
In the first map, shown in Figure 2, the algorithm is able to separate most of the Palettes into separate parts of the map, showing that it is successfully grouping many of the Grooves according to similarity. The Pop V3, Jungle V1, Peter Erskine Rock, Heavy Metal and Funk V3 Palettes are all in their own clear groups, with fairly few outliers.
The Max UI communicates with BFD with a suficiently low latency for real-time use in a DAW. To load and play back Grooves, the names of selected Grooves are sent from Max to BFD via a However, some Palettes are less well separated from others ‘Smooth Jazz’ in particular. Similarly, the Country and Blues Palettes are plotted on top of each other, although this makes some sense as they are similar genres. While the mapping makes topological sense, the U-matrix is not able to cluster entirely successfully, other than the Rock Palettes in the bottom-left of the map. This could be the result of a high level of variation within the input features making clusters unclear.
Although the mapping corresponds quite well to the tagging in the smaller SOM, the larger map, shown in Figure 3, did not clearly separate genre groups, and did not show any real clusters in the Umatrix. Grooves within the same Palette are clustered together still, but Palettes themselves are not really grouped with other Palettes of the same genre. This could indicate a limitation in the similarity function, as it is unable to take account of the higher-level stylistic characteristics of drum loops that motivate human categorization. It could suggest limitations in using factory-supplied genre meta-tags as ground-truth categories for evaluation, due to the high amount of variance within genres, crossover between genres, and possible inconsistencies in tagging. For an evaluation truly representative of the practical quality of the map, a user study is required.
As a work in progress, the Groove Explorer represents a positive step towards easier navigation of drum loop libraries. The current visualization approach is capable of arranging and separating loops by stylistic categories in the case of smaller data libraries. However, for datasets spanning a larger range of styles and genres, the system is not yet able to convincingly express the higher-level genre organization. This could indicate a limitation of the SOM, or limitations in the use of genre tags as a ground truth. Alternatively, the issue could be in the similarity metric; metrics based purely on rhythm similarity may be unable to pick up stylistic similarities of expressive drum loops. Further investigation is required into other similarity metrics, along with the development of alternative features for drum loop analysis. Investigation into diferent visualization techniques other than the SOM could also prove useful. Finally, a study should be carried out involving music producers to assess the usability of the interface and mapping.