The 'dublin' object
The main entry point for mxdublin can be considered as pure-data/max java external, the 'dublin' or 'lldbln' object. The most important message for the 'dublin' object is the console message that will bring a GUI to edit your python code and play with the current trails.
The 'dublin' java external doesn't have any outlet because you don't want to managed a external with 40 outlets. Messages that needs to be triggered will be sended via pure-data/max senders. If you want to link this sender, simply put a "r/receiver object <name>" into your patch.
Here is a complete list on what each message can do:
The object 'lldbln' is an extension of 'dublin' that can also be used to define a static set of trails and limits the usage of the mxdublin console and python. 'lldbln' takes an additional parameters that tells the number of trail to create once to object is instantiated. Trail can be started/stopped/edited by using the trail name or number.
You can edit/start/stop trail using a array of booleen values to control multiple trails into a single message. For example, if you need to start trail #1 and trail #5, you can send the message 'start 1 0 0 0 1'. The same logic apply to the stop and toggle message.
This object also have a outlet that will send the registred trail status at each 1.5 seconds. If trail #2 and trail #4 is started, this object will send the message '0 1 0 1 0'.
It is possible to sync midi clock and sequencer event data with mxdublin. For this you need to filter raw midi data (from the midiin object) to select the 'clock', 'start' / 'stop' events. Map 248 to 24PPQ clock messages, 250 for the start message and 252 for the stop message.
By mapping the midi message 248 to a [bang], the dublin instance will synchronized the internal clock by this tick. Any bang sended to any mxdublin inlet are considered as a clock tick.
The 'start' and 'start_ref' message will mark the quarter note reference for trail start quantizing.
On Max/MSP, you can map your midiout receiver to a midiout object without modifing the data. On pure-data, you need to put the midiout receiver into a 'iter' object. This is because pure-data cannot write a list a of midi events. You can use the 'iter' object that comes with maxlib external package (that comes with pd-extented) or use the java object 'iter' that comes with mxdublin.
When you send the 'edit' message to a dublin/lldbln instance, this instance will bring the trail editor. This trail editor looks like a tracker editor that can edit the content of your TrailEvList. Each cell of the editor is the content of a EvAbstractItem. Using group properties defined in the project, common events item that share the same group properties will be put in the same column of the tracker. It is also possible to edit those properties by simply selecting one column of the tracker.
Inside each column, it is possible by the group properties to know the default type of object to instanciate by using the key 'defaultObject'
The console is the GUI to mxdublin. The main usage is to program and modify trails. During a performance, the console is optional since you can open a session, start/stop trails by sending messages to the pure-data/max external.
In the bottom right, you have the list of registered trail within the session. You can start/stop/dispose them by right clicking on the trail name. It is also possible to create a trail by clicking Add > TrailEventList . This will create a new trail of type TrailEventList and can be edited by double-clicking on the trail name.
In the middle, you have the snippet editor. A snippet is simply a portion of a python script that can be executed later on by sending the message "ex" to the external with the snippet name. Snippet can be added/removed/renamed/executed by right clicking on the name. There is a special trail named "autoexec" that will always execute it self when the session is loaded.
At the bottom, there is a python prompt where you can test your objects interactively. You can afterwards alter the content of your sequence by using python
Session are used to save the content of session into a file; off course you can save or load a session from the file menu. It is important to know that not all trails can be saved to a session. Right now, only TrailEventList will save the content of the list and the events. Other trails will be discarded since they don't support persistence. Python functions and variable that has been defined in the interactive session will also be lost. You can use the autoexec snippet to define any object that is required by the project. Script in the autoexec snippet will be execute each time the session is loaded.