CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
This document is a companion to the Plaine & Easie Version 2 specifications. It describes the major differences between Version 1 and Version 2, including those that introduce compatibility issues between the two versions.
It is now an error to have a Plaine & Easie Code document without also specifying a clef. This change was introduced because the clef specifies the line on the staff on which the note should be drawn, and without a clef this is ambiguous.
The lower-case character p was introduced to
indicate fermatas, replacing the previous practice of
enclosing the note in parentheses, (). This
change was introduced because the parentheses were already
in use as the enclosing characters for a rhythmic group
(i.e., tuplets), and there was no need to indicate more than
one note for a fermata.
Previously, neume notation was indicated with the special
duration of 7.. This introduced an arbitrary
restriction on coding dotted 128th notes, while also making
it unclear whether neume notation could be mixed with other
types of notation.
Version 2 introduces the : character in the
clef to indicated that it is neume notation, following the
same pattern established by Mensural notation.
Previously, the plus character + was used to
indicate that two notes were tied. This created some
problems when using the Plaine & Easie Code in a web
environment, where the +
symbol caused problems when it was instead interpreted as a
space.
In addition to changing to an underscore, ties are now encoded without specifying the end pitch name. This was introduced to eliminate occurrences of a tie where the start and end pitch names differ.
The first version of the Plaine & Easie Code also used the underscore for tied notes. This was changed in subsequent revisions, but is now reverted to its original character.
The previous version of the Plaine & Easie Code had a provision for a "coded validity note" that indicated whether corrections had or had not been applied, or that the incipit was transcribed into modern notation.
In Version 2 this has been removed. It was not deemed expressive enough to be useful (it did not specify which corrections had, or had not, been introduced). An evaluation of the usage of this field showed no consistent application of this field, so it was removed in favor of putting any explanatory notes in a notes field.
Previously, alternating time signatures were separated by a space character. This caused some ambiguities since the space character was used as a separator for clef, key, and time changes inline.
In Version 2 this has been changed to a vertical bar,
|.
Previously, chords were encoded by individually marking
each member of a chord with a ^. This made parsing
difficult as chords were determined only after the first note was
encountered. As well, there were no rules forbidding changing
durations on members of a chord, nor were there specifications for
encoding tied chords.
In Version 2, chords are encoded between ^ and
> characters. Changes to duration within a chord
are forbidden, and the encoding of tied chords is specified.
Previously, the + character was used in clefs
to indicate the staff should be rendered in mensural notation.
Due to the same problems in encoding that had us remove it for ties,
the + character was replaced with a *
character in the clef to indicate mensural notation.
Previously the characters qq were used to start
an appogiatura (a.k.a grace note) group. However, this was
the only instance in the Plaine & Easie Code where two
characters were used to start a group. It made
parsing the code more difficult, since it created
ambiguities between a single appoggiatura note, `q` and
a group of notes.
In Version 2 the start of an appoggiatura group is now
signaled by the lower-case letter y. It is
still ended by the lower-case letter r.
JavaScript Object Notation (JSON) is now an accepted representation format for the Plaine & Easie Code.
The ability to explicitly state key and / or mode in Plaine & Easie was not included in Version 2.
The status of this ability was unclear. MARC21 ($r) and UNIMARC permit the encoding
of key and mode, and indeed the MARC21 documentation states that the format of this field comes
from the Plaine & Easie Code. However, the latest updates to Version 1 of the Code did not
actually specify this format.
The ability to encode the key or mode of a piece was available in the initial versions of the Plaine & Easie Code, but the format of this field was not strictly defined.
It was decided to not formalize this field in Version 2 of the Code. The judgement of a major or a minor key is not strictly necessary for capturing the notation of an incipit, and instead is something that should be captured in an explanatory note or a dedicated cataloguing field. The application of this field, particularly in the capture of non-CWMN music, would also require expanding the format and validation of the values beyond a simple rubric.
The effect of this change may be that the subfield remains available in MARC21 and UNIMARC, but the format is no longer defined in reference to the Plaine & Easie Code.