generic programmable event sequencer for pure-data/max



Components view

The core of mxdublin is written in Java, but the API is presented in Jython so the user doesn't have to mess with Java typing and syntax. Jython 2.2a comes built-in with mxdublin that doesn't require any installation of python.

This software doesn't generate any sound or directly send midi data to midi ports; this is why it is bundled to work with pure-data or max. Although mxdublin can send atoms to specific receivers in pure-data/max that will trigger a sound or generate a midi message. By doing this you can still route or modify sequencer information with-in your patch.


There is basic concept of thread in mxdublin and it's called trail. A trail looks like a thread where it do something (like playing a note, sending a bang) and then wait a logical time expressed in quarter note to be called again. By design a trail always loop over it self if it has played all the events. Also a trail never knows when it should be started or stopped. If it has to be sequenced in time, another trail should start/stop it when needed. Trails could be considered as lowlevel stuff because it doesn't contain any static data. The reason for that is to be able to design a trail that change it self while it is playing. If the user need to build trail from a set of static events, event lists can be used to synchronize these events from a trail.


Time is always relative from when the trail has been started or when the last event was played. It is also based on a master tempo and each quarter note have a value of 1. This means that if your trails needs to wait for a half note, the value "2" must be used. Internally mxdublin uses a time code of 480 PPQ. When we are using the float format (example 1.25), the trail will multiply the float internally value by 480.

Timing usage reference :
4 2 1 0.5 or 1/2 0.25 or 1/4

Event lists

Event lists could be considered as the high level stuff that will sequence a set of static events using a trail. The static word is used since the timing of theses events are programmed to be fixed within the list. Contents of the list can also be saved into a mxdublin session file that can be used later.

All items into the list must be a subclass of EvAbstractItem that is the base class of any events. Event type that extends this class must override method play() that the trail will execute when the event trigger time is reached. This UML diagram can give an idea on how event list objects are related.

To be able to initialize each event in the tracker interface, each object must have a 'string' constructor that will define the value of this object. Each object have a dynamic part of the event, take for instance the note to play and a more static part of the event, like a midi channel. The static part of the event can be stored in a group-properties to share a common value between objects. Event will share the same column in the tracker editor interface if they share the same group-properties.



EvAbstractItem is the base type for all events that will be added to the event list. The usage of properties, timing and event serialization are defined in this object.


EvSender is probably the most used type of event; this event will send atoms to a pure-data/max receiver when it is played. The content of the event is specified in a string since it can be a bang (by using !), symbol or a float. The @sender is also used to define a property that will assign this event to a specific pure-data/max receiver.


EvNote is an extended class of EvSender that will send a midi note to the specified sender. It will also trigger the note-off midi message when the duration of the event time is reached so you don't have to add another event into the list that simply "stop" the note. The event argument is the midi note value in tracker format (e.g.: E-2, F#3, D-4, G-5), the event duration in mxdublin format (see time signature) and the optional velocity for this event (default is 127).


EvChord is an extended class of EvNote that will send midi notes to the specified sender that represent the chord.


EvProg is an extended class of EvNote that sends a chord base on a scale progression. By using a root note, the user can experiment chord progression like II/IV/V but by using standard numbers.


EvTrgNote is a extended class of EvSender that will simply generate a midi "note on" message. This event can be use to trigger sounds on a rhythmical midi device.


EvList is used to put event items into a list chronologically. It basically works like a java.util.List except that it will only accept objects based on EvAbstractItem like EvSender or EvNote. EvList also contains a set of utility methods to be able to extract, stretch or filter types of events within the list.


TrailEventList is used to play events within a list. If the list content has changed since the last event was played it will re-adapt it self from the new content of the associated list. If the trail has played all the event into the list it will simply loop to the first event; like any another trails.