This project is read-only.

Building the Project

Before you build the Aleator, you need to set up your environment up to use VST .NET. See the project for more details. Be sure to make a copy of Jacobi.Vst.Interop.dll, renaming it <YourPluginName>.dll and placing it wherever you will be referencing your assembly, most likely your DAW's plugins directory (your assembly will be named <YourPluginName>.net.dll). I have been working with Reaper so I have a post-build action that copies my assembly into the Reaper plugins directory, just for convenience. Please let me know if you have problems building.

You will also need to install /Libraries/Sanford/Sanford.Multimedia.dll into your GAC.

You will want to edit the XML so that the Aleator plays the arrangements that you want. You will need to know a bit of music theory to do this - the plugin is a songwriting tool. We have kept these documents separate because the classes they represent were generated using the XSD tool and managing the data this way has helped with development. There are four documents and I will try to explain what the various nodes, values and attributes they represent. We'll go from the top down.

  • Rhythm - This document is completely independent from the other three. The nodes describe different kinds of rhythm and get read in by the LoadRhythms method in the DrumPhrase class - that's one of the first things that happens when the Aleator starts up. Right now, the only one of these elements that matters is Distribution. The others will come into play as we build more rhythm algorithms into the plugin. 
  • Composition - The Composition XML is read in by Session.LoadCompositions(). It describes all of the movements that make up your suite of music. At the composition level, you must specify a mode - we are only accounting for Aolian and Ionian currently. If you want to play in an odd meter, you need to specify a numerator otherwise 4/4 is assumed. We do not account for compound meters as of yet. Compositions contain a sequence of Progression nodes with the following attributes/values:
    • SequenceID - Should be self explanatory.
    • Multiplier - How many times the progression will be repeated
    • Modulation [optional] - The direction we are moving away from the previous key
    • Value - the ProgressionID from progression.xml
  • Progression - A progression is really just a series of chords (represented in the usual roman numeral notation) and beat designations. The Beats attribute describes how many quarter notes the chord will be held for. The chord used must be valid for the mode of the progression - that will either be the mode declared at the composition level or the result of any modulation that has occurred. Breaking this rule will cause a runtime exception.There's a reference to the parent Composition at the progression level. The entire document is read in by Composition class' constructor.
  • Melody - This document is probably the most difficult to describe. Melodies are tied to progressions in terms of their duration. Specifically, the total beat length of a progression must be divisible by the total beat length of the melody or melodies its associated with. Breaking this rule will cause a runtime exception. Melodies are comprised of note clusters, which have the following attributes aside from ClusterID:
    • Beats - How many quarter notes the cluster will last for
    • Notes - The scale degrees that are available to the melody phrase for the cluster's length
    • Multiplier - How many times the cluster is to be repeated before moving to the next one. By default, the Aleator will play each cluster once and repeat the entire melody for as many times as it takes to fill up the associated progression. You can force it to repeat at either the cluster OR the melody level by using a multiplier. You just have to make sure that the total number of beats associated with the melody when any multipliers are applied matches the total progression length. You know why? Breaking this rule will cause a runtime error.

Changing the MIDI Configuration

By default the Aleator is currently configured to output MIDI to channels 1, 4 - 6 and channel 9, as indicated below. The plugin's phrasing techniques provide MIDI suitable for kicks, snares, high hats, bass, rhythm chords and lead melody. Right now, it will also play the occasional rim shot. The default mapping is:

  • CC
  • [Empty]
  • [Empty]
  • Bass
  • Chords
  • Melody
  • [Empty]
  • [Empty]
  • All Drums (by noteid)

We are using CC messages 14 and 15 on channel 1 to decrease and increase tempo, respectively. Reaper is set up to change the BPM of the current project in increments of 10 each time it receives one of these messages. You can't really do a direct program change in Omnisphere (my main synth) - instead you have to MIDI learn the browser up/down arrows and change multis using the learn if you need to automate that, which I do. That is set up as note 0 (scroll up) and note 127 (scroll down) on the channel 1.

The long story short is that if you want to change how these are being directed, you will need to change noteon/noteoff messageids in AppResources.resx. The comments will tell you which channel ids are associated with which message numbers.

You are now ready to start Aleating. Take a look at the Roadmap to see what changes we're working on.

Last edited Mar 8, 2014 at 7:29 PM by kil0watt, version 25