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.
Notably, 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, 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 for indicating 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 also meant that
parsing the code was a bit more difficult, since it created
ambiguities between a single `q`, or a single appogiatura
notes, or a group of notes.
In Version 2 the start of an appogiatura group is now
signalled 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.