Player Library 2.0


Introduction

The Player library is provided to allow the development of a complete multi-tracks MidiShare sequencer. Each Player is a MidiShare application, has up to 256 tracks, four different synchronization mode, events chase and loop markers. Sequences in MidiShare format can be set in the Player. Functions are provided to read on write MIDIfiles and convert them to the MidiShare sequence format. This library was first developed to be used in the Symbolic Composer music composition environment. It has been continually refined over 3 years in order to provide a stable and general API. The Player library 2.0 has been completely rewritten, to make the source code publicly available. This library is currently used in different applications : Elody (Grame), PatchWork and OpenMusic (IRCAM), Symbolic Composer (Peter Stone), Java Applets Japer and Pann (Roberto Bresin), Visual Piano (Smart Concept) and Prie (Alfio Fazio)



Source code

The Player library source code is released as a set of C++ classes and C code distributed under the LGPL Licence. It is organized as separate components which could be reused is other context. The code uses a lot of Design Patterns from the catalog defined by Gamma [Gam94] as well as the interface concept from the Java language.


General overview

 


Components

The different components are implemented as patterns of C++ classes using several patterns described in Gamma [Gam94]. The whole Player is built by combining several components which are described in the following pages using the OMT (Object Modeling Technique) notation :

 


State diagrams

Several components have a notion of state :


Classes hierarchy diagrams

Here are several diagrams representing the classes hierarchy : diagram1, diagram2, diagram3, and diagram4.


 

Limitations and improvements

1) Tempo events are not inserted in the score when the player is recording in clock or external synchronization mode.

2) Some of the classes can easily be re-used, although the whole library is probably to "sequencer oriented", and could be generalized. One possible improvement is to detach the whole player lib from the "score concept" which basically suppose that events to be played are contained in a score data structure. It means that some classes are not general enough. A more general concept could be a "event producer " mechanism able to produce events to be played coming either from a pre-calculated data structure (like the score) or from a more dynamic generation principle.

 


 

References