|
|
 |
 |
|
|
|
Computer Music Generation Based on Chord ProgressionsMy article about automated text generation shows ways to simulate creativity on a computer. This conception gains more success in generating musical pieces since music is much more forgiving towards construction rules. This principle will of course not replace the art of a talented composer, but may be an interesting tool to study and perhaps to base some further inventions upon. Just like with text generation, an input musical sequence is needed, which will define a style of the output.- a carefully edited MIDI file with chord harmonies, which are edited to maintain strict boundaries and allow a reassembly. A chord progression markup is then created in a text file, where it closely represents a harmony with a symbol for every two beats. "Yankee Doodle Boy" will have this markup: G G G D7 G G D7 D7 G G C C D7 D7 G G... Chunks with the same markup (G, for instance) are considered to be equivalent and are randomly interchangeable, even though the actual MIDI file may have different notes corresponding to this markup. For example, this is a more complicated markup of some hypothetic tune, though in a real program the input sequence is longer: C C E7 E7 F F Fm Fm uC uC A7 A7 D G7 Cf Cf C C F F uC Am D G C7 C7 F Fm uC G7 Cf Cf C E7 F D uC G C Cf Symbols do not need to represent a proper chord. They are only used by a computer program to recognize a sequence of similar chords. For instance, in the sequence above uC may be used to notify C-chunk without a bass note, and Cf - for an ending (coda) chord. Then for every two consequent chords, a program creates a table with possible resolutions into the third one. This work is done entirely with markup symbols, thus MIDI is not used until the final stage. According to the original sequence, a table will have entries: [C C] [C E7] [E7 E7] [E7 F] [F F] [...] [C Cf] with no duplicates. For an entry [C C], stored data will be: {E7,F} - in the original sequence E7 and F have equal probabilities of appearing after "C C". Similarly, for an entry [F F] the stored data will be {Fm,uC}. If a certain resolution chord is more probable for a given sequence (appears multiple times in the original line), it will appear in the table multiple times as well, such as {Fm,Fm,uC} for instance. A program starts with two random chords, then it randomly picks from the table a next chord (resolution chord). So, for instance, for [C C], either C or E7 will be picked as a next chord. Assuming that 'E7' was picked, the output sequence will be C C E7. After this, the last two chords are taken into a pair [C E7] and the program looks up a match in the table for this tuple. The table for this tuple contains possible resolutions {E7,F}, and thus either E7 or F will selected. When a sufficient length of an output sequence is reached, it is then converted into MIDI by substituting symbols with small chunks of data from the original MIDI file. To add more variation into the output, a table of single chord transitions may be created as well (with entries such as [C] -> {C,E7,C,F,E7,C} for example) to which a program may refer at some random time intervals instead of using tuple-to-one table. This will create an output which is less resembling the original sequence.
The approach works rather well for stylistic playing, and depends mostly on a quality of a given input material and its markup. The algorithm itself is quite streamlined and does not require complex computations. Further variations can be applied on top of this method, such as tonality shift, tempo variations, note shifts, etc... I have created two programs RAGMIDI and CLASMIDI to illustrate the concept. The first one generates random ragtime music, and the second one generates unsophisticated classical music. Both generate a single track of piano playing. The following examples are available:
|