Information is communicated to FOMUS through the definition of “objects” (i.e., in a .fms file or in a programming environment like Lisp or SAL).
Examples of objects are parts, instruments, notes, measures and the score itself, which must all be defined to give FOMUS a complete set of instructions for notating a score.
Object definitions may contain one or more “settings” which directly affect how the objects are processed or interpreted.
Examples of settings are
beat, which determines how note events are spelled rhythmically, and
determines what key signature appears in a measure. Object definitions may also contain parameters (e.g.,
that aren't actually settings (settings have a specially defined behavior, as explained below)
but are instead part of the structural makeup of the object itself.
One of the most important of these parameters is
If an object is defined with a unique ID, other objects can then use that ID to refer to it.
If two objects of the same class are defined with the same ID, the later definition replaces the earlier one
(more specifically, the old one still exists but can't be referred to anymore since it's ID has been moved to another object).
FOMUS's objects are arranged hierarchically and “contain” other objects or refer to other objects in some way
(e.g., parts refer to instruments via the
inst parameter or
instruments can optionally contain one or more percussion instruments using the
When one object contains or refers to another, you must either use an ID or define the sub-object inline inside the parent object.
id parameter is mandatory when defining an object at the “top level” (i.e., when an object is not part of or embedded in another object).
Settings in “container” objects (like parts or measures) generally affect everything that's contained in that object.
If you set the
keysig setting in a measure, for example, it only affects that measure. If you set
in a part, though, it affects all measures in that part (unless overriden by another
keysig setting in an individual measure).
In the same way, setting
keysig in the score object affects all parts and measures in the entire score.
Setting values are thus inherited in smaller objects from larger ones.
Many settings can be set in any object class while some can only be set in specific places (e.g., the score).
The Settings section of the reference contains information on how individual settings may be used and which objects they may
Following is a complete list of FOMUS's object classes and their parameters:
fomusexternal is created.
measdefsand events in that part including measures, notes, rests and marks. Settings in the
instobject it is associated with also affect the part and everything inside it.
Parts generally appear in the score in the same order that they are defined in. If the
layout setting is defined,
the order and grouping changes according to the layout
(though parts based on the same instrument still appear in their defined order).
If percussion instruments are used, the clef for the instrument should be set to ‘percussion’. A pre-defined instrument with ID ‘percussion’
exists with appropriate settings for use as a template.
inst-defsso that you can reuse it. The setting
inst-defsfunctions as a library of predefined instruments. Add your own instruments to this library by placing a line like ‘inst-defs += (<id: inst1 ...> <id: inst2 ...> ...)’ in your
namesetting) can also appear in the score wherever a change occurs. By changing the settings in percussion instruments and moving them around between different instruments, it is easy to change how percussion parts appear in the score and how they are divided up among players.
If you find yourself defining a percussion instrument from scratch over and over, it might be useful to add your definition to
percinst-defs so that you can reuse it.
percinst-defs functions as a library of predefined percussion instruments.
Add your own instruments to this library by placing a line like ‘percinst-defs += (<id: percinst1 ...> <id: percinst2 ...> ...)’
partmaps, each of which contains a reference to a part or metapart. Partmaps contain instructions for copying events from metaparts to actual parts.
At a certain point in FOMUS's processing, metapart events are copied into their proper parts and the metaparts themselves are destroyed. The instructions for copying events are contained in the metapart and partmap settings. Each partmap basically contains a reference to one part/metapart and describes how note events are distributed (and possibly transposed or doubled).
Metaparts currently don't have instruments associated with them (this might change in future releases).
Metapart settings only affect measures and note events up until when they are copied
to their new locations, at which point the settings of the new part/instrument take effect.
measdefis a definition for a measure event or group of measure events. The difference between a measure definition and a measure event is that the latter has a time and duration, appears in the score and may inherit settings from the former, while the former is just a collection of settings and values. When you create a measure event, you may refer to a
measdefwhich contains all of the settings for that measure.
Measure definitions are mostly useful in .fms files where they are used to avoid redundancy when defining measure events.
The typical usage is to define a few
measdefs at the top of the file and refer to them by ID when creating new measures.
In most other environments it's easier to include all of the settings inside the measure itself rather than bother with defining measure definitions separately.
A keyboard instrument might, for example, contain two
staff objects, each of which
clef objects, one treble and one bass. The settings in the four clef objects
would then influence how they are chosen and how notes should be laid out on either staff.
See MIDI Import Examples for examples of using import objects.
See TODO for examples of using export objects.
from-voice, which designates the voice or voices events are being copied from and
to-voice, which designates the voice or voices events are being copied to. Multiple partmaps can copy the same events to multiple places. They can also transpose note events and do other simple modifications as they are being copied.