|
This whitepaper details a method of generating new MIDI drum loops using a combination of AutoHarp — an algorithmic music playing software package created by the author — and Andrej Karpathy's character-based Recurrent Neural Network, char-rnn. It is a herculean task to track all of the inputs and prior art that led to this experiment and informed its construction (the history of algorithmic music is, at this point, vast), but a few specific experiments led me to begin investigating char-rnn as a fruitful source for progress in the arena:
This experiment focused on AutoHarp's drummer. In the open-source version of AutoHarp, you "seed" it with existing MIDI drum loops (a plethora of free and royalty-free MIDI loops are available online for the Googling); thereafter it plays in particular musical genres by selecting a loop or loops you have tagged in that genre during the seeding process and modifying them slightly as the music requires (e.g. repeating loops or truncating them, adding simple fills at the end of phrases, switching one type of drum to another to add variance). The very first attempt was merely to print out the MIDI notes of all the drum loops in my AutoHarp library as text representations of their MIDI data. This was done without regard for differences in tempo, genre, or meter (a.k.a. time signature) among the loops themselves. As it is easier to manage and manipulate in code, I did switch MIDI note_on/note_off events, which use relative time, to using a single quasi-MIDI "note" event which uses absolute time and a note duration. I also used the MIDI utilities of AutoHarp to break each loop into one-bar sections and re-zeroed the absolute time of each bar. A section of the input file appears below:
*The "note" quasi-event is of the format: 'note',absolute time,pitch,channel,duration,velocity. In Standard MIDI percussion, pitches have set associated drums; in my library, e.g., 35 == kick, 38 == snare, 42 == closed hi-hat, etc.
This file was 1.2 MB — according to the documentation, a small sample size. Nonetheless, the initial results — run with default settings for char-rnn — were somewhat promising. Example output from a mid-epoch checkpoint looked like:
I used AutoHarp's built-in text utilities to harvest loops, using all valid lines between Start and End markers. Converting those back to MIDI and looping the results over four bars produced output such as this:
Interesting — nothing to make Gene Krupa quake in his...um...grave — but interesting, and certainly indicative that the approach (of converting MIDI to text, building a text learning model, and then harvesting the resulting text and converting it back to MIDI) might be promising.
However, from there, it was initially difficult to make much forward progress. I did succeed, by using the same method, but limiting the input to only 4/4 loops, in getting examples of fairly rhythmic one-bar loops (here again looped to 4 bars):
Attempting to get the machine to string together its own, longer, drum lines using this method were, however, unsuccessful. I tried a variety of changes to the inputs — for instance, in one iteration I used only the Rock loops (i.e. straight-ahead 4/4 beats with kicks on 1 and 3, snares on 2 and 4); in several I used only the 4-measure phrases as input; I fed them through AutoHarp first to simplify the beats where possible. All outputs in this set of iterations were thematically similar to this:
Kind of like a kid who just got his drum set, and can keep things going for a couple of beats, falls apart, gets it back, and then falls apart again.
It was at this point that I had a kind of pedagogical revelation: the drum loops I was using as input were too advanced. They were recorded on MIDI drum kits by professional human players who had, presumably, years of practice to develop groove and feel. Here again is one bar of a sample input loop (from a later iteration where I had changed the format — the data is still the same):
AutoHarp uses 240 MIDI ticks per beat, so a drum loop that was rigidly on the beat would have time values like 120, 240, 480, etc. This loop, and indeed all of the input loops, isn't robotically on the beat. Human drummers, especially good ones, play in a groove: they slightly anticipate or lag behind some or all of the beats in a measure. Here's what the above loop sounds like, fyi:
From Groove Monkee's free MIDI drum loops package
This is like trying to teach someone the drums by transcribing a Stewart Copeland line down to a resolution of 960th notes and expecting her to learn an expert drummer's rhythm, groove, and feel from it.
At this point, I switched file formats to a simple text drum notation that I'd created in AutoHarp to visualize drum loops. It looks like this:
Each line represents a drum, and each character within the bars represents a 16th note. A dot is no drum hit, a number represents how hard the drum is hit with 0 being the lightest and 9 being the hardest. In addition to forcing the hits of the loop into a grid, I also bootstrapped the dataset by creating a series of virtual song sections of 4 bars apiece, and letting AutoHarp's drummer play them (via the method previously described using altered MIDI loops) and running it 5000 times. This created a 2 MB dataset, which I fed to the char-rnn train module. It took a few epochs before it got the hang of the format, but after that, well...here's a random sample of the results (now with a richer drum sound font):
The trailing off is one of the ways AutoHarp will end a phrase in order to bring the energy of the song down. It has learned well.
Straight ahead. Is that last little hi-hat flutter a screw up, or did you mean to do that? It's learned to do little variances at the end of phrases — here, e.g., the open hi-hats. If it weren't so perfectly on the beat, this would be indistinguishable from a human player Yeah, this one's a little wonky; it's also undeniably rhythmically interesting.
I didn't cherry pick those. I have a script that runs through char-rnn's checkpoint files (on this run I was writing them every 25 iterations, so I have a lot of data for this single experiment), harvests the results, and writes them to MIDI files; I then sample them randomly, and the five above came out of that random sampling one right after another. There are certainly loops in the set that aren't quite passing as drum grooves (that fifth one is probably one of them), but there aren't very many of them. This just seems to me to be a stunning result; I tried a very difficult pedagogy and it more or less failed. I simplified the pedagogy, as you might when teaching a human to do something, and it succeeded.
I've since written code into the experimental branch of AutoHarp that can use existing, human played drum loops as a "groove template" to make the loops that come out of this model feel more natural — that is, it will move notes slightly off the beat and give them more nuanced note velocities so as to give the loops groove and feel. And I also hope that as I develop the model, this will prove unnecessary. As it is when a human learns music, it seems that the basic rhythms have to be taught first. Actually "feeling" the music — making it musical — is a study that lasts a lifetime. Or that's how it is for a human, anyway — in the case of char-rnn, it might take just a few more epochs.
0 Comments
This whitepaper explores a process of creating music, specifically short (3 to 4 minute) pop songs, using an algorithmic music generation software package called AutoHarp. It details the process of creating The Inquisitivists' first musical release, the three-song Lost on this Island e.p., which will be linked here for download when it is available. Additional sound and data files generated by the program are embedded below as well. This is "Generation 1" of a long-term art and science project exploring the nature of creativity and machine intelligence. We expect this process to evolve and change as AutoHarp becomes more advanced, and as the field of machine creativity evolves in general. In this iteration, a human was heavily involved (e.g. as lyricist, singer, and producer). As the technology improves, we expect that involvement to change; indeed, the changing relationship between man and machine is the theme that drives the art created by this project.
AutoHarp is a suite of algorithmic music generation tools created by the author, currently in active development (c.f. other whitepapers concerning machine learning and neural networks on this site). The version that was used to create the songs on the Lost on this Island e.p. is documented and available for download as the mainline branch of this project on GitHub. It outputs music in the form of multitrack MIDI files (using MIDI format 1), with appropriate MIDI patches selected and assigned to each track (a bass patch for the bass part, pianos, organs, or strings for the rhythm instrument, drums for percussion, etc). Of the three songs on the e.p., two were generated via an iterative process described below. The third, "Falling for the World," was created by taking the following 8 bars that were generated by AutoHarp
and looping them, via cut and paste, in a digital audio workstation (Apple's Logic). For this composition in particular, the 8 bars above were the extent of the machine's tangible contribution to the song. From an artistic point of view (and probably also a legal one), this isn't true: it is recognizably the crux of the final song, and the song's lyrics tell the story of art generated by a machine. It is both foundation and inspiration. The debate of the machine's true role in creating this song, while absolutely within the purview of the project, is, however, outside the scope of this paper.
The other two songs were created via the process that follows. Their foundational MIDI files were generated (along with somewhere between 250 and 500 others) to create an album for the 2015 RPM Challenge, an event in which the author regularly participates (click the link for more information). The author ran AutoHarp's "generate" utility (which creates a new song and outputs a MIDI and a data file) over and over again, listening to each composition for as long as it held his interest, marking ones that were notable to him in some way and passing over or deleting ones that he deemed unworthy. This relationship was very like a music producer with access to a composer who wrote new music for the asking, never grew tired, and was never offended when the producer rejected its songs. Here are some example snippets of generated pieces that were saved, but for one reason or another were not developed any further:
From this process, the pool was winnowed down to a handful of songs (completing the RPM Challenge requires ten songs, the author selected 12 at this point) which were workshopped. As a human song writer will take a song that has a solid musical foundation and rewrite the bridge, repeat the chorus after the second verse, or add a prechorus, AutoHarp can do the same via the "regenerate" utility. The "generate" utility produces a data file along with the MIDI; "regenerate" takes that file as input and creates a new song. Deleting elements out of the file before feeding it back in causes AutoHarp to regenerate those parts, and changing chords or melodies manually causes AutoHarp to use those instead. "This Cosmic Place," which appears on the e.p., is the only song of the 12 that didn't go through this process--its structure, progression, and instrumentation remain as the machine originally wrote it (Thief of the Daylight, by contrast, went through 10 different bridges before the author "suggested" his own set of chord changes and a new song structure with the bridge played twice, and had AutoHarp iterate on that structure).
At this point the resulting MIDI files were imported into Logic and assigned more fully rendered instrument patches (either built in to Logic or from third parties). At this point the machine's job was done--it had composed and played what it was going to play. The author wrote lyrics, sang them, and added guitar parts. Some extremely game musicians known to the author added additional vocals and guitar (thank you Jennie and Andy). This is also the stage at which the author, as a music producer might, went in to tweak individual notes. An example of that from "Thief of the Daylight" appears below:
(AutoHarp output)
(same section, produced)
Note how the machine's clav track repeats the same motif every measure, whereas the produced version has had its last four notes altered slightly on the second and fourth measures of the phrase.
After completing the RPM Challenge, the author did some polishing and then went and solicited some musical opinions to determine what should be on the final release (thanks everyone, you know who you are) some of whom knew the nature of the project and some of whom didn't. The result is the three songs that appear on the e.p. We hope you enjoy it and feel inspired to evangelize it a little. Links to the original MIDI files for each of the three songs, and final AutoHarp data files that will generate them appear below.
Given that one of the focuses of this website is technology, and I've just spent the morning on a technological struggle in order to bring said website into being, I thought I'd spend a little time documenting that struggle. Also, in my pursuit of knowledge about the world, I've found articles like this to be incredibly helpful. We live in a world in which, if you have a problem, it is highly likely that both
I wanted to run an Nginx site and an Apache site side by side on the same AWS (that's Amazon Web Services) EC2 Linux micro instance. My wife is a novelist, and I run her website. A t1.micro with a little extra swap space configured can easily handle all of the traffic we garner, and I didn't want to pay the extra $18/month for a second server. www.inquisitivists.com runs on Rails, her website is Perl CGI (and now the more clever amongst you know how old I am).
What you've done here is told Apache that port 80 is a proxy server; it proxies requests for your Nginx domain to port 1080 of the localhost (your EC2 instance), where the Nginx is waiting to serve that site. It proxies requests to your Apache domain to port 2080, where the same Apache is waiting to serve that site. Note that the server in the ProxyPass line is literally "localhost." You're just telling Apache to proxy the local server to get content to serve back to the user. You may or may not be tempted to fill in your actual domain with the port number attached. Like, don't do this: first off it won't work because you haven't opened those ports via EC2 Security groups, and if you do do that, Apache will get really freaking confused.
|
ArchivesCategories |
RSS Feed