Logo Search packages:      
Sourcecode: rosegarden version File versions  Download package

Rosegarden global design


Rosegarden is split into 3 main parts:


The base library holds all of the fundamental "music handling" structures, of which the primary ones are Event, Segment, Track, Instrument and Composition. It also contains a selection of utility and helper classes of a kind that is not specific to any particular GUI.

This design came about at a time when Rosegarden had been through several toolkit experiments, and did not want to chain itself to any one GUI toolkit. We wanted to be able to take the core of Rosegarden and build a new application around it simply and easily, and so the base library is built around the STL, and Qt and KDE classes were not allowed here. In practice, we and Qt share the same fate now, and we have been allowing Qt classes in the base library whenever that represented the most pragmatic and expedient solution to a problem.

The keyword for the basic structures in use is "flexibility". Our Event objects can be extended arbitrarily for the convenience of GUI or performance code without having to change their declaration or modify anything in the base library. And most of our assumptions about the use of the container classes can be violated without disastrous side-effects.

Music Structures

See also http://rosegardenmusic.com/wiki/dev:units.txt for an explanation of the units we use for time and pitch values. See http://rosegardenmusic.com/wiki/dev:creating_events.txt for an explanation of how to create new Events and add properties to them.

The base directory also contains various music-related helper classes:

The NotationTypes classes also define important constants for the names of common properties in Events. For example, the Note class contains Note::EventType, which is the type of a note Event, and Note::EventRestType, the type of a rest Event; and Key contains Key::EventType, the type of a key change Event, KeyPropertyName, the name of the property that defines the key change, and a set of the valid strings for key changes.


The GUI directory builds into a Qt application that follows a document/view model. The document (class RosegardenDocument, which wraps a Composition (along with several other related classes)) can have several views (class RosegardenMainViewWidget), although at the moment only a single one is used.

This view is the TrackEditor, which shows all the Composition's Segments organized in Tracks. Each Segment can be edited in several ways, as notation, on a piano roll matrix, or via the raw event list.

All editor views are derived from EditViewBase. EditViewBase is the class dealing with the edition per se of the events. It uses several components:

LayoutEngine no longer seems to be relevant. The following documentation needs to be updated by someone who really understands how everything works on the far side of the Thorn restructuring. Readers should understand this documentation might not reflect reality very well.

There are currently two editor views:

some of this is still true, some of it isn't

The editing process works as follows:

[NOTE : in the following, we're talking both about events as UI events or user events (mouse button clicks, mouse move, keystrokes, etc...) and Events (our basic music element). To help lift the ambiguity, "events" is for UI events, Events is for Event.]

  1. The canvas view gets the user events (see NotationCanvasView::contentsMousePressEvent(QMouseEvent*) for an example). It locates where the event occured in terms of musical element: which note or staff line the user clicked on, which pitch and time this corresponds to, that kind of stuff. (In the Notation and Matrix views, the LinedStaff calculates mappings between coordinates and staff lines: the former is especially complicated because of its support for page layout.)
  2. The canvas view transmits this kind of info as a signal, which is connected to a slot in the parent EditView.
  3. The EditView delegates action to the current tool.
  4. The tool performs the actual job (inserting or deleting a note, etc...).

Since this action is usually complex (merely inserting a note requires dealing with the surrounding Events, rests or notes), it does it through a SegmentHelper (for instance, base/SegmentNotationHelper) which "wraps" the complexity into simple calls and performs all the hidden tasks.

The EditView also maintains (obviously) its visual appearance with the layout classes, applying them when appropriate.


The Sequencer interfaces directly with ALSA and provides MIDI "play" and "record" ports which can be connected to other MIDI clients (MIDI IN and OUT hardware ports or ALSA synth devices) using any ALSA MIDI Connection Manager. The Sequencer also supports playing and recording of Audio sample files using Jack

The GUI and Sequencer were originally implemented as separate processes communicating using the KDE DCOP communication framework, but they have now been restructured into separate threads of a single process. The original design still explains some of the structure of these classes, however. Generally, the DCOP functions that the GUI used to call in the sequencer are now simple public functions of RosegardenSequencer that are described in the RosegardenSequencerIface parent class (this class is retained purely for descriptive purposes); calls that the sequencer used to make back to the GUI have mostly been replaced by polling from the GUI to sequencer.

The main operations invoked from the GUI involve starting and stopping the Sequencer, playing and recording, fast forwarding and rewinding. Once a play or record cycle is enabled it's the Sequencer that does most of the hard work. Events are read from (or written to, when recording) a set of mmapped files shared between the threads.

The Sequencer makes use of two libraries libRosegardenSequencer and libRosegardenSound:

The main Sequencer state machine is a good starting point and clearly visible at the bottom of rosegarden/sequencer/main.cpp.

Generated by  Doxygen 1.6.0   Back to index