Home Banner image
Home

Architecture

ProjectMIDI can be extended through the use of late binding .NET 2.0 assemblies (DLLs). ProjectMIDI will search for and load assemblies which contain a class that implements an interface known to it. I'll refer to these DLL files simply as assemblies within these pages.

The primary executable is ProjectMIDI.exe. This is the core program which in turn locates and loads all other assemblies.

Sets, Songs, Pages, and Patches Data Model

ProjectMidi.exe implements the basic structure which organizes data into Song Sets, Songs, Pages and Patches.

Sets

A group of 1 or more song names can be organized into a collection referred to as a song Set. This is typically the set of songs played for a particular gig, but it could alternatively be a set of songs related by theme or style.

Songs

This is the name of a folder containing all of the data files associated with a given song. This folder name will be used by ProjectMIDI to locate its data files for a given song. It will also be passed to each assembly when the song is selected.

Pages

Songs can be broken down into multiple pieces referred to as pages. Each song will have 1 or more pages.

Patches

Patches allow breaking a song's page into multiple sections, each with a different set of patches. A device assembly should allow selecting a different patch or group of settings for each patch.

Events and Actions Model

ProjectMIDI attempts to provide a very high degree of flexibility and extensibility. One of the ways that it does this is by generalizing the way that user inputs or events are associated with the resultant action.

Events

Each assembly can define and publish a set of events that it supports. This might include a menu or pushbutton, or for a Device Assembly it could be a hardware control (slider or knob) or foot pedal or other MIDI trigger.

ProjectMIDI Events are .NET events with a specific signature and a custom attribute defined by ProjectMIDI. A custom attribute is used to specify the friendly name and number of values the event can generate. Refer to the Attributes section for information about these custom attributes.

Actions

Each assembly also defines and publishes a set of actions which it implements. These are things like "Next page", "Display TD8 Patch Editor", and so forth. This is limited only by our imaginations.

Actions are methods with a signature that matches that needed for handling the events described above. A custom attribute is used to specify the friendly name and number of values the action can handle. Refer to the Attributes section for information about these custom attributes.

The data passed to actions from events is passed in an EventArgs or a class derived from it.

Connection lists

Inputs can be connected to actions in a couple of ways:

  1. Using matching autoconnect names
  2. By using the Connections dialog

    A dialog is provided to allow the user to manually specify additional connections, or to disable autoconnections.

Persistence

User specified connections are persisted to an XML file actions.xml in the Project MIDI root folder. These will be restored each time Project MIDI starts.

Assembly defined Event/Action Associations

In addition the 2 methods described above, different assemblies can communicate with either in a couple other ways:

  1. Expose Events, Actions, Methods, or Properties

    ProjectMIDI provides a mechanism for assemblies to view and connect with other assemblies provided they have flagged these using ProjectMIDI's custom attributes.

  2. Use multiple interface derivation

    In addition to deriving from IProjectMidi, an assembly's ProjectMIDI class can derive from additional interfaces. Another assembly can search the list of ProjectMIDI loaded assemblies using a mechanism provided by ProjectMIDI. Each can be tested to see if it derives from the desired interface. Once found, the custom interface can be used directly.