` tags within the `notation-code` element are what will be shown to the users. This means you can restrict
+the example being shown to just the elements you are trying to illustrate, while omitting any additional code needed to
+render, but unnecessary for the example.
+ - The `notation-result` `td` must always be blank. The SVG output of the rendering will be placed in this cell.
+
+Any other `` elements within the ` ` can be present, but will be ignored.
+
diff --git a/pr-preview/pr-126/README.md b/pr-preview/pr-126/README.md
new file mode 100644
index 0000000..7a23944
--- /dev/null
+++ b/pr-preview/pr-126/README.md
@@ -0,0 +1,42 @@
+## Plaine & Easie Code Specification
+
+The Plaine & Easie Code is a text-based music notation encoding system, primarily designed to be used
+for encoding small, monophonic extracts from a larger musical composition.
+
+The Plaine & Easie code system was first proposed by Barry S. Brook, with input from several others, in 1964,
+as a means of capturing incipits for more precisely identifying musical compositions in manuscripts. Incipits were
+a means of uniquely identifying compositions that could not otherwise be uniquely identified by the title or composer
+of the work.
+
+Plaine & Easie code was used in the RISM cataloguing systems, first typewritten on index cards, and then in
+software databases. In 2004 the Plaine & Easie code was [adopted](https://www.loc.gov/marc/marbi/2004/2004-05.html) as
+part of the MAchine Readable Catalog (MARC) standard. Currently, the RISM uses Muscat as its cataloguing system which
+has Plaine & Easie support integrated.
+
+RISM now holds well over 1 million incipits encoded using the Plaine & Easie code; a significant corpus of notated music
+and an impressive global effort. These incipits have been the subject of a number of tools, databases,
+and studies, and with an increasing number of software tools and projects using it, further improvements and enhancements
+to the code, and to the documents that describe it, were felt to be necessary. In some areas, the lack of clear specifications,
+or inconsistent behaviours, have made it challenging for ensuring consistency across the whole corpus, which in turn
+made it difficult to build data authoring and validation tools.
+
+This repository hosts two different versions of the Plaine & Easie Code specification. The first, which we are calling
+"Version 1", represents the status of the code as it was until 2022. We have decided to forego any significant changes
+to this version of the specification, as it represents the most widely adopted form of the code, and changes to this
+specification would risk introducing confusion.
+
+The second version, "Version 2", represents work-in-progress for changes to the Plaine & Easie Code. These changes are
+largely based in the goal of making the Plaine & Easie Code more consistent, such that the large existing corpus of
+incipits can be more easily used in notation search, data analysis, and data science.
+
+
+### References
+
+Brook, B., et al. 1964. Notating music with ordinary typewriter characters (A Plaine and Easie code system for Musicke).
+_Fontes Artis Musicae_ 11 (3). pp. 142–159.
+
+Brook, B. 1965. The simplified "Plaine and Easie Code System" for notating music: A proposal for international adoption.
+_Fontes Artis Musicae_ 12 (2/3). pp. 156–160.
+
+MARC Development Office. 2004. Proposal No.: 2004-05, Changes needed to Accommodate RISM Data -- Music Incipits.
+https://www.loc.gov/marc/marbi/2004/2004-05.html
diff --git a/pr-preview/pr-126/bare_pr_preview/HEAD b/pr-preview/pr-126/bare_pr_preview/HEAD
new file mode 100644
index 0000000..b870d82
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/HEAD
@@ -0,0 +1 @@
+ref: refs/heads/main
diff --git a/pr-preview/pr-126/bare_pr_preview/config b/pr-preview/pr-126/bare_pr_preview/config
new file mode 100644
index 0000000..d14c137
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/config
@@ -0,0 +1,6 @@
+[core]
+ repositoryformatversion = 0
+ filemode = true
+ bare = true
+[remote "origin"]
+ url = https://github.com/rossjrw/pr-preview-action
diff --git a/pr-preview/pr-126/bare_pr_preview/description b/pr-preview/pr-126/bare_pr_preview/description
new file mode 100755
index 0000000..498b267
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/description
@@ -0,0 +1 @@
+Unnamed repository; edit this file 'description' to name the repository.
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/applypatch-msg.sample b/pr-preview/pr-126/bare_pr_preview/hooks/applypatch-msg.sample
new file mode 100755
index 0000000..a5d7b84
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/applypatch-msg.sample
@@ -0,0 +1,15 @@
+#!/bin/sh
+#
+# An example hook script to check the commit log message taken by
+# applypatch from an e-mail message.
+#
+# The hook should exit with non-zero status after issuing an
+# appropriate message if it wants to stop the commit. The hook is
+# allowed to edit the commit message file.
+#
+# To enable this hook, rename this file to "applypatch-msg".
+
+. git-sh-setup
+commitmsg="$(git rev-parse --git-path hooks/commit-msg)"
+test -x "$commitmsg" && exec "$commitmsg" ${1+"$@"}
+:
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/commit-msg.sample b/pr-preview/pr-126/bare_pr_preview/hooks/commit-msg.sample
new file mode 100755
index 0000000..b58d118
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/commit-msg.sample
@@ -0,0 +1,24 @@
+#!/bin/sh
+#
+# An example hook script to check the commit log message.
+# Called by "git commit" with one argument, the name of the file
+# that has the commit message. The hook should exit with non-zero
+# status after issuing an appropriate message if it wants to stop the
+# commit. The hook is allowed to edit the commit message file.
+#
+# To enable this hook, rename this file to "commit-msg".
+
+# Uncomment the below to add a Signed-off-by line to the message.
+# Doing this in a hook is a bad idea in general, but the prepare-commit-msg
+# hook is more suited to it.
+#
+# SOB=$(git var GIT_AUTHOR_IDENT | sed -n 's/^\(.*>\).*$/Signed-off-by: \1/p')
+# grep -qs "^$SOB" "$1" || echo "$SOB" >> "$1"
+
+# This example catches duplicate Signed-off-by lines.
+
+test "" = "$(grep '^Signed-off-by: ' "$1" |
+ sort | uniq -c | sed -e '/^[ ]*1[ ]/d')" || {
+ echo >&2 Duplicate Signed-off-by lines.
+ exit 1
+}
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/fsmonitor-watchman.sample b/pr-preview/pr-126/bare_pr_preview/hooks/fsmonitor-watchman.sample
new file mode 100755
index 0000000..23e856f
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/fsmonitor-watchman.sample
@@ -0,0 +1,174 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+use IPC::Open2;
+
+# An example hook script to integrate Watchman
+# (https://facebook.github.io/watchman/) with git to speed up detecting
+# new and modified files.
+#
+# The hook is passed a version (currently 2) and last update token
+# formatted as a string and outputs to stdout a new update token and
+# all files that have been modified since the update token. Paths must
+# be relative to the root of the working tree and separated by a single NUL.
+#
+# To enable this hook, rename this file to "query-watchman" and set
+# 'git config core.fsmonitor .git/hooks/query-watchman'
+#
+my ($version, $last_update_token) = @ARGV;
+
+# Uncomment for debugging
+# print STDERR "$0 $version $last_update_token\n";
+
+# Check the hook interface version
+if ($version ne 2) {
+ die "Unsupported query-fsmonitor hook version '$version'.\n" .
+ "Falling back to scanning...\n";
+}
+
+my $git_work_tree = get_working_dir();
+
+my $retry = 1;
+
+my $json_pkg;
+eval {
+ require JSON::XS;
+ $json_pkg = "JSON::XS";
+ 1;
+} or do {
+ require JSON::PP;
+ $json_pkg = "JSON::PP";
+};
+
+launch_watchman();
+
+sub launch_watchman {
+ my $o = watchman_query();
+ if (is_work_tree_watched($o)) {
+ output_result($o->{clock}, @{$o->{files}});
+ }
+}
+
+sub output_result {
+ my ($clockid, @files) = @_;
+
+ # Uncomment for debugging watchman output
+ # open (my $fh, ">", ".git/watchman-output.out");
+ # binmode $fh, ":utf8";
+ # print $fh "$clockid\n@files\n";
+ # close $fh;
+
+ binmode STDOUT, ":utf8";
+ print $clockid;
+ print "\0";
+ local $, = "\0";
+ print @files;
+}
+
+sub watchman_clock {
+ my $response = qx/watchman clock "$git_work_tree"/;
+ die "Failed to get clock id on '$git_work_tree'.\n" .
+ "Falling back to scanning...\n" if $? != 0;
+
+ return $json_pkg->new->utf8->decode($response);
+}
+
+sub watchman_query {
+ my $pid = open2(\*CHLD_OUT, \*CHLD_IN, 'watchman -j --no-pretty')
+ or die "open2() failed: $!\n" .
+ "Falling back to scanning...\n";
+
+ # In the query expression below we're asking for names of files that
+ # changed since $last_update_token but not from the .git folder.
+ #
+ # To accomplish this, we're using the "since" generator to use the
+ # recency index to select candidate nodes and "fields" to limit the
+ # output to file names only. Then we're using the "expression" term to
+ # further constrain the results.
+ my $last_update_line = "";
+ if (substr($last_update_token, 0, 1) eq "c") {
+ $last_update_token = "\"$last_update_token\"";
+ $last_update_line = qq[\n"since": $last_update_token,];
+ }
+ my $query = <<" END";
+ ["query", "$git_work_tree", {$last_update_line
+ "fields": ["name"],
+ "expression": ["not", ["dirname", ".git"]]
+ }]
+ END
+
+ # Uncomment for debugging the watchman query
+ # open (my $fh, ">", ".git/watchman-query.json");
+ # print $fh $query;
+ # close $fh;
+
+ print CHLD_IN $query;
+ close CHLD_IN;
+ my $response = do {local $/; };
+
+ # Uncomment for debugging the watch response
+ # open ($fh, ">", ".git/watchman-response.json");
+ # print $fh $response;
+ # close $fh;
+
+ die "Watchman: command returned no output.\n" .
+ "Falling back to scanning...\n" if $response eq "";
+ die "Watchman: command returned invalid output: $response\n" .
+ "Falling back to scanning...\n" unless $response =~ /^\{/;
+
+ return $json_pkg->new->utf8->decode($response);
+}
+
+sub is_work_tree_watched {
+ my ($output) = @_;
+ my $error = $output->{error};
+ if ($retry > 0 and $error and $error =~ m/unable to resolve root .* directory (.*) is not watched/) {
+ $retry--;
+ my $response = qx/watchman watch "$git_work_tree"/;
+ die "Failed to make watchman watch '$git_work_tree'.\n" .
+ "Falling back to scanning...\n" if $? != 0;
+ $output = $json_pkg->new->utf8->decode($response);
+ $error = $output->{error};
+ die "Watchman: $error.\n" .
+ "Falling back to scanning...\n" if $error;
+
+ # Uncomment for debugging watchman output
+ # open (my $fh, ">", ".git/watchman-output.out");
+ # close $fh;
+
+ # Watchman will always return all files on the first query so
+ # return the fast "everything is dirty" flag to git and do the
+ # Watchman query just to get it over with now so we won't pay
+ # the cost in git to look up each individual file.
+ my $o = watchman_clock();
+ $error = $output->{error};
+
+ die "Watchman: $error.\n" .
+ "Falling back to scanning...\n" if $error;
+
+ output_result($o->{clock}, ("/"));
+ $last_update_token = $o->{clock};
+
+ eval { launch_watchman() };
+ return 0;
+ }
+
+ die "Watchman: $error.\n" .
+ "Falling back to scanning...\n" if $error;
+
+ return 1;
+}
+
+sub get_working_dir {
+ my $working_dir;
+ if ($^O =~ 'msys' || $^O =~ 'cygwin') {
+ $working_dir = Win32::GetCwd();
+ $working_dir =~ tr/\\/\//;
+ } else {
+ require Cwd;
+ $working_dir = Cwd::cwd();
+ }
+
+ return $working_dir;
+}
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/post-update.sample b/pr-preview/pr-126/bare_pr_preview/hooks/post-update.sample
new file mode 100755
index 0000000..ec17ec1
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/post-update.sample
@@ -0,0 +1,8 @@
+#!/bin/sh
+#
+# An example hook script to prepare a packed repository for use over
+# dumb transports.
+#
+# To enable this hook, rename this file to "post-update".
+
+exec git update-server-info
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/pre-applypatch.sample b/pr-preview/pr-126/bare_pr_preview/hooks/pre-applypatch.sample
new file mode 100755
index 0000000..4142082
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/pre-applypatch.sample
@@ -0,0 +1,14 @@
+#!/bin/sh
+#
+# An example hook script to verify what is about to be committed
+# by applypatch from an e-mail message.
+#
+# The hook should exit with non-zero status after issuing an
+# appropriate message if it wants to stop the commit.
+#
+# To enable this hook, rename this file to "pre-applypatch".
+
+. git-sh-setup
+precommit="$(git rev-parse --git-path hooks/pre-commit)"
+test -x "$precommit" && exec "$precommit" ${1+"$@"}
+:
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/pre-commit.sample b/pr-preview/pr-126/bare_pr_preview/hooks/pre-commit.sample
new file mode 100755
index 0000000..29ed5ee
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/pre-commit.sample
@@ -0,0 +1,49 @@
+#!/bin/sh
+#
+# An example hook script to verify what is about to be committed.
+# Called by "git commit" with no arguments. The hook should
+# exit with non-zero status after issuing an appropriate message if
+# it wants to stop the commit.
+#
+# To enable this hook, rename this file to "pre-commit".
+
+if git rev-parse --verify HEAD >/dev/null 2>&1
+then
+ against=HEAD
+else
+ # Initial commit: diff against an empty tree object
+ against=$(git hash-object -t tree /dev/null)
+fi
+
+# If you want to allow non-ASCII filenames set this variable to true.
+allownonascii=$(git config --type=bool hooks.allownonascii)
+
+# Redirect output to stderr.
+exec 1>&2
+
+# Cross platform projects tend to avoid non-ASCII filenames; prevent
+# them from being added to the repository. We exploit the fact that the
+# printable range starts at the space character and ends with tilde.
+if [ "$allownonascii" != "true" ] &&
+ # Note that the use of brackets around a tr range is ok here, (it's
+ # even required, for portability to Solaris 10's /usr/bin/tr), since
+ # the square bracket bytes happen to fall in the designated range.
+ test $(git diff-index --cached --name-only --diff-filter=A -z $against |
+ LC_ALL=C tr -d '[ -~]\0' | wc -c) != 0
+then
+ cat <<\EOF
+Error: Attempt to add a non-ASCII file name.
+
+This can cause problems if you want to work with people on other platforms.
+
+To be portable it is advisable to rename the file.
+
+If you know what you are doing you can disable this check using:
+
+ git config hooks.allownonascii true
+EOF
+ exit 1
+fi
+
+# If there are whitespace errors, print the offending file names and fail.
+exec git diff-index --check --cached $against --
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/pre-merge-commit.sample b/pr-preview/pr-126/bare_pr_preview/hooks/pre-merge-commit.sample
new file mode 100755
index 0000000..399eab1
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/pre-merge-commit.sample
@@ -0,0 +1,13 @@
+#!/bin/sh
+#
+# An example hook script to verify what is about to be committed.
+# Called by "git merge" with no arguments. The hook should
+# exit with non-zero status after issuing an appropriate message to
+# stderr if it wants to stop the merge commit.
+#
+# To enable this hook, rename this file to "pre-merge-commit".
+
+. git-sh-setup
+test -x "$GIT_DIR/hooks/pre-commit" &&
+ exec "$GIT_DIR/hooks/pre-commit"
+:
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/pre-push.sample b/pr-preview/pr-126/bare_pr_preview/hooks/pre-push.sample
new file mode 100755
index 0000000..4ce688d
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/pre-push.sample
@@ -0,0 +1,53 @@
+#!/bin/sh
+
+# An example hook script to verify what is about to be pushed. Called by "git
+# push" after it has checked the remote status, but before anything has been
+# pushed. If this script exits with a non-zero status nothing will be pushed.
+#
+# This hook is called with the following parameters:
+#
+# $1 -- Name of the remote to which the push is being done
+# $2 -- URL to which the push is being done
+#
+# If pushing without using a named remote those arguments will be equal.
+#
+# Information about the commits which are being pushed is supplied as lines to
+# the standard input in the form:
+#
+#
+#
+# This sample shows how to prevent push of commits where the log message starts
+# with "WIP" (work in progress).
+
+remote="$1"
+url="$2"
+
+zero=$(git hash-object --stdin &2 "Found WIP commit in $local_ref, not pushing"
+ exit 1
+ fi
+ fi
+done
+
+exit 0
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/pre-rebase.sample b/pr-preview/pr-126/bare_pr_preview/hooks/pre-rebase.sample
new file mode 100755
index 0000000..6cbef5c
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/pre-rebase.sample
@@ -0,0 +1,169 @@
+#!/bin/sh
+#
+# Copyright (c) 2006, 2008 Junio C Hamano
+#
+# The "pre-rebase" hook is run just before "git rebase" starts doing
+# its job, and can prevent the command from running by exiting with
+# non-zero status.
+#
+# The hook is called with the following parameters:
+#
+# $1 -- the upstream the series was forked from.
+# $2 -- the branch being rebased (or empty when rebasing the current branch).
+#
+# This sample shows how to prevent topic branches that are already
+# merged to 'next' branch from getting rebased, because allowing it
+# would result in rebasing already published history.
+
+publish=next
+basebranch="$1"
+if test "$#" = 2
+then
+ topic="refs/heads/$2"
+else
+ topic=`git symbolic-ref HEAD` ||
+ exit 0 ;# we do not interrupt rebasing detached HEAD
+fi
+
+case "$topic" in
+refs/heads/??/*)
+ ;;
+*)
+ exit 0 ;# we do not interrupt others.
+ ;;
+esac
+
+# Now we are dealing with a topic branch being rebased
+# on top of master. Is it OK to rebase it?
+
+# Does the topic really exist?
+git show-ref -q "$topic" || {
+ echo >&2 "No such branch $topic"
+ exit 1
+}
+
+# Is topic fully merged to master?
+not_in_master=`git rev-list --pretty=oneline ^master "$topic"`
+if test -z "$not_in_master"
+then
+ echo >&2 "$topic is fully merged to master; better remove it."
+ exit 1 ;# we could allow it, but there is no point.
+fi
+
+# Is topic ever merged to next? If so you should not be rebasing it.
+only_next_1=`git rev-list ^master "^$topic" ${publish} | sort`
+only_next_2=`git rev-list ^master ${publish} | sort`
+if test "$only_next_1" = "$only_next_2"
+then
+ not_in_topic=`git rev-list "^$topic" master`
+ if test -z "$not_in_topic"
+ then
+ echo >&2 "$topic is already up to date with master"
+ exit 1 ;# we could allow it, but there is no point.
+ else
+ exit 0
+ fi
+else
+ not_in_next=`git rev-list --pretty=oneline ^${publish} "$topic"`
+ /usr/bin/perl -e '
+ my $topic = $ARGV[0];
+ my $msg = "* $topic has commits already merged to public branch:\n";
+ my (%not_in_next) = map {
+ /^([0-9a-f]+) /;
+ ($1 => 1);
+ } split(/\n/, $ARGV[1]);
+ for my $elem (map {
+ /^([0-9a-f]+) (.*)$/;
+ [$1 => $2];
+ } split(/\n/, $ARGV[2])) {
+ if (!exists $not_in_next{$elem->[0]}) {
+ if ($msg) {
+ print STDERR $msg;
+ undef $msg;
+ }
+ print STDERR " $elem->[1]\n";
+ }
+ }
+ ' "$topic" "$not_in_next" "$not_in_master"
+ exit 1
+fi
+
+<<\DOC_END
+
+This sample hook safeguards topic branches that have been
+published from being rewound.
+
+The workflow assumed here is:
+
+ * Once a topic branch forks from "master", "master" is never
+ merged into it again (either directly or indirectly).
+
+ * Once a topic branch is fully cooked and merged into "master",
+ it is deleted. If you need to build on top of it to correct
+ earlier mistakes, a new topic branch is created by forking at
+ the tip of the "master". This is not strictly necessary, but
+ it makes it easier to keep your history simple.
+
+ * Whenever you need to test or publish your changes to topic
+ branches, merge them into "next" branch.
+
+The script, being an example, hardcodes the publish branch name
+to be "next", but it is trivial to make it configurable via
+$GIT_DIR/config mechanism.
+
+With this workflow, you would want to know:
+
+(1) ... if a topic branch has ever been merged to "next". Young
+ topic branches can have stupid mistakes you would rather
+ clean up before publishing, and things that have not been
+ merged into other branches can be easily rebased without
+ affecting other people. But once it is published, you would
+ not want to rewind it.
+
+(2) ... if a topic branch has been fully merged to "master".
+ Then you can delete it. More importantly, you should not
+ build on top of it -- other people may already want to
+ change things related to the topic as patches against your
+ "master", so if you need further changes, it is better to
+ fork the topic (perhaps with the same name) afresh from the
+ tip of "master".
+
+Let's look at this example:
+
+ o---o---o---o---o---o---o---o---o---o "next"
+ / / / /
+ / a---a---b A / /
+ / / / /
+ / / c---c---c---c B /
+ / / / \ /
+ / / / b---b C \ /
+ / / / / \ /
+ ---o---o---o---o---o---o---o---o---o---o---o "master"
+
+
+A, B and C are topic branches.
+
+ * A has one fix since it was merged up to "next".
+
+ * B has finished. It has been fully merged up to "master" and "next",
+ and is ready to be deleted.
+
+ * C has not merged to "next" at all.
+
+We would want to allow C to be rebased, refuse A, and encourage
+B to be deleted.
+
+To compute (1):
+
+ git rev-list ^master ^topic next
+ git rev-list ^master next
+
+ if these match, topic has not merged in next at all.
+
+To compute (2):
+
+ git rev-list master..topic
+
+ if this is empty, it is fully merged to "master".
+
+DOC_END
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/pre-receive.sample b/pr-preview/pr-126/bare_pr_preview/hooks/pre-receive.sample
new file mode 100755
index 0000000..a1fd29e
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/pre-receive.sample
@@ -0,0 +1,24 @@
+#!/bin/sh
+#
+# An example hook script to make use of push options.
+# The example simply echoes all push options that start with 'echoback='
+# and rejects all pushes when the "reject" push option is used.
+#
+# To enable this hook, rename this file to "pre-receive".
+
+if test -n "$GIT_PUSH_OPTION_COUNT"
+then
+ i=0
+ while test "$i" -lt "$GIT_PUSH_OPTION_COUNT"
+ do
+ eval "value=\$GIT_PUSH_OPTION_$i"
+ case "$value" in
+ echoback=*)
+ echo "echo from the pre-receive-hook: ${value#*=}" >&2
+ ;;
+ reject)
+ exit 1
+ esac
+ i=$((i + 1))
+ done
+fi
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/prepare-commit-msg.sample b/pr-preview/pr-126/bare_pr_preview/hooks/prepare-commit-msg.sample
new file mode 100755
index 0000000..10fa14c
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/prepare-commit-msg.sample
@@ -0,0 +1,42 @@
+#!/bin/sh
+#
+# An example hook script to prepare the commit log message.
+# Called by "git commit" with the name of the file that has the
+# commit message, followed by the description of the commit
+# message's source. The hook's purpose is to edit the commit
+# message file. If the hook fails with a non-zero status,
+# the commit is aborted.
+#
+# To enable this hook, rename this file to "prepare-commit-msg".
+
+# This hook includes three examples. The first one removes the
+# "# Please enter the commit message..." help message.
+#
+# The second includes the output of "git diff --name-status -r"
+# into the message, just before the "git status" output. It is
+# commented because it doesn't cope with --amend or with squashed
+# commits.
+#
+# The third example adds a Signed-off-by line to the message, that can
+# still be edited. This is rarely a good idea.
+
+COMMIT_MSG_FILE=$1
+COMMIT_SOURCE=$2
+SHA1=$3
+
+/usr/bin/perl -i.bak -ne 'print unless(m/^. Please enter the commit message/..m/^#$/)' "$COMMIT_MSG_FILE"
+
+# case "$COMMIT_SOURCE,$SHA1" in
+# ,|template,)
+# /usr/bin/perl -i.bak -pe '
+# print "\n" . `git diff --cached --name-status -r`
+# if /^#/ && $first++ == 0' "$COMMIT_MSG_FILE" ;;
+# *) ;;
+# esac
+
+# SOB=$(git var GIT_COMMITTER_IDENT | sed -n 's/^\(.*>\).*$/Signed-off-by: \1/p')
+# git interpret-trailers --in-place --trailer "$SOB" "$COMMIT_MSG_FILE"
+# if test -z "$COMMIT_SOURCE"
+# then
+# /usr/bin/perl -i.bak -pe 'print "\n" if !$first_line++' "$COMMIT_MSG_FILE"
+# fi
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/push-to-checkout.sample b/pr-preview/pr-126/bare_pr_preview/hooks/push-to-checkout.sample
new file mode 100755
index 0000000..af5a0c0
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/push-to-checkout.sample
@@ -0,0 +1,78 @@
+#!/bin/sh
+
+# An example hook script to update a checked-out tree on a git push.
+#
+# This hook is invoked by git-receive-pack(1) when it reacts to git
+# push and updates reference(s) in its repository, and when the push
+# tries to update the branch that is currently checked out and the
+# receive.denyCurrentBranch configuration variable is set to
+# updateInstead.
+#
+# By default, such a push is refused if the working tree and the index
+# of the remote repository has any difference from the currently
+# checked out commit; when both the working tree and the index match
+# the current commit, they are updated to match the newly pushed tip
+# of the branch. This hook is to be used to override the default
+# behaviour; however the code below reimplements the default behaviour
+# as a starting point for convenient modification.
+#
+# The hook receives the commit with which the tip of the current
+# branch is going to be updated:
+commit=$1
+
+# It can exit with a non-zero status to refuse the push (when it does
+# so, it must not modify the index or the working tree).
+die () {
+ echo >&2 "$*"
+ exit 1
+}
+
+# Or it can make any necessary changes to the working tree and to the
+# index to bring them to the desired state when the tip of the current
+# branch is updated to the new commit, and exit with a zero status.
+#
+# For example, the hook can simply run git read-tree -u -m HEAD "$1"
+# in order to emulate git fetch that is run in the reverse direction
+# with git push, as the two-tree form of git read-tree -u -m is
+# essentially the same as git switch or git checkout that switches
+# branches while keeping the local changes in the working tree that do
+# not interfere with the difference between the branches.
+
+# The below is a more-or-less exact translation to shell of the C code
+# for the default behaviour for git's push-to-checkout hook defined in
+# the push_to_deploy() function in builtin/receive-pack.c.
+#
+# Note that the hook will be executed from the repository directory,
+# not from the working tree, so if you want to perform operations on
+# the working tree, you will have to adapt your code accordingly, e.g.
+# by adding "cd .." or using relative paths.
+
+if ! git update-index -q --ignore-submodules --refresh
+then
+ die "Up-to-date check failed"
+fi
+
+if ! git diff-files --quiet --ignore-submodules --
+then
+ die "Working directory has unstaged changes"
+fi
+
+# This is a rough translation of:
+#
+# head_has_history() ? "HEAD" : EMPTY_TREE_SHA1_HEX
+if git cat-file -e HEAD 2>/dev/null
+then
+ head=HEAD
+else
+ head=$(git hash-object -t tree --stdin &2
+ exit 1
+}
+
+unset GIT_DIR GIT_WORK_TREE
+cd "$worktree" &&
+
+if grep -q "^diff --git " "$1"
+then
+ validate_patch "$1"
+else
+ validate_cover_letter "$1"
+fi &&
+
+if test "$GIT_SENDEMAIL_FILE_COUNTER" = "$GIT_SENDEMAIL_FILE_TOTAL"
+then
+ git config --unset-all sendemail.validateWorktree &&
+ trap 'git worktree remove -ff "$worktree"' EXIT &&
+ validate_series
+fi
diff --git a/pr-preview/pr-126/bare_pr_preview/hooks/update.sample b/pr-preview/pr-126/bare_pr_preview/hooks/update.sample
new file mode 100755
index 0000000..c4d426b
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/hooks/update.sample
@@ -0,0 +1,128 @@
+#!/bin/sh
+#
+# An example hook script to block unannotated tags from entering.
+# Called by "git receive-pack" with arguments: refname sha1-old sha1-new
+#
+# To enable this hook, rename this file to "update".
+#
+# Config
+# ------
+# hooks.allowunannotated
+# This boolean sets whether unannotated tags will be allowed into the
+# repository. By default they won't be.
+# hooks.allowdeletetag
+# This boolean sets whether deleting tags will be allowed in the
+# repository. By default they won't be.
+# hooks.allowmodifytag
+# This boolean sets whether a tag may be modified after creation. By default
+# it won't be.
+# hooks.allowdeletebranch
+# This boolean sets whether deleting branches will be allowed in the
+# repository. By default they won't be.
+# hooks.denycreatebranch
+# This boolean sets whether remotely creating branches will be denied
+# in the repository. By default this is allowed.
+#
+
+# --- Command line
+refname="$1"
+oldrev="$2"
+newrev="$3"
+
+# --- Safety check
+if [ -z "$GIT_DIR" ]; then
+ echo "Don't run this script from the command line." >&2
+ echo " (if you want, you could supply GIT_DIR then run" >&2
+ echo " $0 )" >&2
+ exit 1
+fi
+
+if [ -z "$refname" -o -z "$oldrev" -o -z "$newrev" ]; then
+ echo "usage: $0 " >&2
+ exit 1
+fi
+
+# --- Config
+allowunannotated=$(git config --type=bool hooks.allowunannotated)
+allowdeletebranch=$(git config --type=bool hooks.allowdeletebranch)
+denycreatebranch=$(git config --type=bool hooks.denycreatebranch)
+allowdeletetag=$(git config --type=bool hooks.allowdeletetag)
+allowmodifytag=$(git config --type=bool hooks.allowmodifytag)
+
+# check for no description
+projectdesc=$(sed -e '1q' "$GIT_DIR/description")
+case "$projectdesc" in
+"Unnamed repository"* | "")
+ echo "*** Project description file hasn't been set" >&2
+ exit 1
+ ;;
+esac
+
+# --- Check types
+# if $newrev is 0000...0000, it's a commit to delete a ref.
+zero=$(git hash-object --stdin &2
+ echo "*** Use 'git tag [ -a | -s ]' for tags you want to propagate." >&2
+ exit 1
+ fi
+ ;;
+ refs/tags/*,delete)
+ # delete tag
+ if [ "$allowdeletetag" != "true" ]; then
+ echo "*** Deleting a tag is not allowed in this repository" >&2
+ exit 1
+ fi
+ ;;
+ refs/tags/*,tag)
+ # annotated tag
+ if [ "$allowmodifytag" != "true" ] && git rev-parse $refname > /dev/null 2>&1
+ then
+ echo "*** Tag '$refname' already exists." >&2
+ echo "*** Modifying a tag is not allowed in this repository." >&2
+ exit 1
+ fi
+ ;;
+ refs/heads/*,commit)
+ # branch
+ if [ "$oldrev" = "$zero" -a "$denycreatebranch" = "true" ]; then
+ echo "*** Creating a branch is not allowed in this repository" >&2
+ exit 1
+ fi
+ ;;
+ refs/heads/*,delete)
+ # delete branch
+ if [ "$allowdeletebranch" != "true" ]; then
+ echo "*** Deleting a branch is not allowed in this repository" >&2
+ exit 1
+ fi
+ ;;
+ refs/remotes/*,commit)
+ # tracking branch
+ ;;
+ refs/remotes/*,delete)
+ # delete tracking branch
+ if [ "$allowdeletebranch" != "true" ]; then
+ echo "*** Deleting a tracking branch is not allowed in this repository" >&2
+ exit 1
+ fi
+ ;;
+ *)
+ # Anything else (is there anything else?)
+ echo "*** Update hook: unknown type of update to ref $refname of type $newrev_type" >&2
+ exit 1
+ ;;
+esac
+
+# --- Finished
+exit 0
diff --git a/pr-preview/pr-126/bare_pr_preview/info/exclude b/pr-preview/pr-126/bare_pr_preview/info/exclude
new file mode 100755
index 0000000..a5196d1
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/info/exclude
@@ -0,0 +1,6 @@
+# git ls-files --others --exclude-from=.git/info/exclude
+# Lines that start with '#' are comments.
+# For a project mostly in C, the following would be a good set of
+# exclude patterns (uncomment them if you want to use them):
+# *.[oa]
+# *~
diff --git a/pr-preview/pr-126/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.idx b/pr-preview/pr-126/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.idx
new file mode 100644
index 0000000..064be2d
Binary files /dev/null and b/pr-preview/pr-126/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.idx differ
diff --git a/pr-preview/pr-126/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.pack b/pr-preview/pr-126/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.pack
new file mode 100644
index 0000000..d6654af
Binary files /dev/null and b/pr-preview/pr-126/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.pack differ
diff --git a/pr-preview/pr-126/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.rev b/pr-preview/pr-126/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.rev
new file mode 100644
index 0000000..f42a6f6
Binary files /dev/null and b/pr-preview/pr-126/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.rev differ
diff --git a/pr-preview/pr-126/bare_pr_preview/packed-refs b/pr-preview/pr-126/bare_pr_preview/packed-refs
new file mode 100644
index 0000000..13103b0
--- /dev/null
+++ b/pr-preview/pr-126/bare_pr_preview/packed-refs
@@ -0,0 +1,30 @@
+# pack-refs with: peeled fully-peeled sorted
+5167fb64eed94956ee828ff354b51ef7806fdb04 refs/heads/example-preview
+288b93b57b27b83abc37ff50d0ad9bb700bbeed3 refs/heads/gh-pages
+ac89ba39103a4cf56a22d338d5c64c1aef0cfa92 refs/heads/jekyll-docs
+e50528e2e93a625266959a4f6e739b2d15409ffb refs/heads/main
+ca3a91c34f603e4cf06a58338ffa0dcb32c39bb3 refs/heads/parametrise-pr-values
+f5db5c92badaca355476a4831dd122195ab29956 refs/tags/v0.0.0
+55df7d7c97c37ddfcad91d8da3700c1c80913ead refs/tags/v0.0.1
+30a02270046756a3e8bcad2923fddbfab73783be refs/tags/v0.0.2
+f31d5aa7b364955ea86228b9dcd346dc3f29c408 refs/tags/v1
+fca13e940d9437bb975801f2c4005734ce2eefcb refs/tags/v1.0
+fca13e940d9437bb975801f2c4005734ce2eefcb refs/tags/v1.0.0
+98706dff8eaffcef39fbd5c5cadd2c6339bbd60b refs/tags/v1.1
+591779e70aba2ce461521af517b269dac0221c77 refs/tags/v1.1.0
+98706dff8eaffcef39fbd5c5cadd2c6339bbd60b refs/tags/v1.1.1
+eac2838daf487e8f054a4bc10dc957431cd6270b refs/tags/v1.2
+eac2838daf487e8f054a4bc10dc957431cd6270b refs/tags/v1.2.0
+699c12bae12472ca7f43d0654858b16c3e60dab9 refs/tags/v1.3
+9dac5c4777c535516ebf819f93aeadac70f66488 refs/tags/v1.3.0
+2a652922e9b9c53e7e5ea62fa38da744de09043c refs/tags/v1.3.1
+699c12bae12472ca7f43d0654858b16c3e60dab9 refs/tags/v1.3.2
+f31d5aa7b364955ea86228b9dcd346dc3f29c408 refs/tags/v1.4
+022361539c71c58a7141d4fe8c3e0e4a1c34f9c5 refs/tags/v1.4.0
+60ad6fc41be190767f6c3cc5d87c0a4dc03e3022 refs/tags/v1.4.1
+70d0e7a39b1712a874aeba33b936c6fdf795617a refs/tags/v1.4.2
+b3a95bc3cdbc27d8941e9b74c5c294c9c9fcb12b refs/tags/v1.4.3
+183082fd714654433c8e2f6daedbfb4f20f2a94a refs/tags/v1.4.4
+7df1ee45a802b8bc8dca1845a5241d118c610810 refs/tags/v1.4.5
+4668d7cb417ce7067b0b59bc152b1ae1513010de refs/tags/v1.4.6
+f31d5aa7b364955ea86228b9dcd346dc3f29c408 refs/tags/v1.4.7
diff --git a/pr-preview/pr-126/index.html b/pr-preview/pr-126/index.html
new file mode 100644
index 0000000..b6f5718
--- /dev/null
+++ b/pr-preview/pr-126/index.html
@@ -0,0 +1,63 @@
+
+
+
+ The Plaine & Easie Code
+
+
+
+
+ 
+
+
+
+ The Plaine & Easie Code is a music notation encoding system
+ designed for the capture of melodic incipits: Short fragments of
+ music notation that help to identify the musical work.
+
+
+ Version 1
+
+
+ Plaine & Easie version 1 is the
+ currently accepted version of the specification.
+
+
+ Version 2
+
+
+ Plaine & Easie version 2
+ specification is under preparation. It is due to contain significant
+ changes, and should not be used until it is finalized.
+
+
+
+ Encoding guidelines for Plaine
+ & Easie are also in preparation.
+
+
+
+ Developed and maintained by the RISM Editorial Center and the RISM
+ Digital Center.
+
+
+
diff --git a/pr-preview/pr-126/static/img/dc-logo.png b/pr-preview/pr-126/static/img/dc-logo.png
new file mode 100644
index 0000000..c1131c8
Binary files /dev/null and b/pr-preview/pr-126/static/img/dc-logo.png differ
diff --git a/pr-preview/pr-126/static/img/edc-logo.png b/pr-preview/pr-126/static/img/edc-logo.png
new file mode 100644
index 0000000..68753b0
Binary files /dev/null and b/pr-preview/pr-126/static/img/edc-logo.png differ
diff --git a/pr-preview/pr-126/static/img/pae-logo.svg b/pr-preview/pr-126/static/img/pae-logo.svg
new file mode 100644
index 0000000..fb7076b
--- /dev/null
+++ b/pr-preview/pr-126/static/img/pae-logo.svg
@@ -0,0 +1,17 @@
+
+
diff --git a/pr-preview/pr-126/static/js/verovio-rendering.js b/pr-preview/pr-126/static/js/verovio-rendering.js
new file mode 100644
index 0000000..820b8b0
--- /dev/null
+++ b/pr-preview/pr-126/static/js/verovio-rendering.js
@@ -0,0 +1,52 @@
+document.addEventListener("DOMContentLoaded", (event) => {
+ verovio.module.onRuntimeInitialized = async _ => {
+ let tk = new verovio.toolkit();
+ tk.setOptions({
+ footer: 'none',
+ header: 'none',
+ breaks: 'auto',
+ pageMarginTop: 15,
+ pageMarginBottom: 15,
+ spacingSystem: 2,
+ pageMarginLeft: 0,
+ pageMarginRight: 0,
+ scale: 50,
+ adjustPageHeight: true,
+ adjustPageWidth: true,
+ svgHtml5: true,
+ // svgFormatRaw: true,
+ svgRemoveXlink: true,
+ // svgViewBox: true,
+ inputFrom: "pae"
+ });
+
+ let notationExamples = document.querySelectorAll("tr.notation-example");
+
+ if (notationExamples !== null)
+ {
+ for (let row of notationExamples)
+ {
+ let verovioSvg = "";
+
+ for (let column of row.children)
+ {
+
+ if (column && column.classList.contains("notation-code"))
+ {
+ let paeCode = column.querySelector("script").textContent;
+ let loadSuccess = tk.loadData(JSON.stringify(JSON.parse(paeCode)));
+
+ if (loadSuccess)
+ {
+ verovioSvg = tk.renderToSVG();
+ }
+ }
+ else if (column.classList.contains("notation-result"))
+ {
+ column.innerHTML = verovioSvg;
+ }
+ }
+ }
+ }
+ }
+});
diff --git a/pr-preview/pr-126/v1/index.html b/pr-preview/pr-126/v1/index.html
new file mode 100644
index 0000000..74a0807
--- /dev/null
+++ b/pr-preview/pr-126/v1/index.html
@@ -0,0 +1,1591 @@
+
+
+
+
+ Plaine & Easie Code
+
+
+
+
+
+
+
+
+ CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
+
+
+
+ This document serves as both a specification and as a source of examples, and is largely a verbatim copy
+ of the existing specification hosted by the International Association of Music Libraries. We are aware
+ of a number of areas where the examples could be more extensive, or the specification could be made more
+ precise. The hope is to address these in Version 2 of the Plaine & Easie specification, and to add supporting
+ materials to accompany it.
+
+
+ The Plaine & Easie Code is a library standard that enables entering music incipits in modern or mensural
+ notation.
+
+
+ This version of the code is maintained by the International Association of Music Libraries, Archives and
+ Documentation Centres (IAML) and the Répertoire International des Sources Musicales (RISM) for use as an
+ exchange format in the library environment. Observations or queries may be addressed to Massimo
+ Gentili-Tedeschi or Balázs Mikusi. A tutorial is available
+ here.
+
+
+ Last update to the code: 28 June 2019
+
+
+ Also available in PDF format.
+
+
+ Adapted from the RISM guidelines. Corresponds to UNIMARC 036 and
+ MARC21 031 fields.
+
+
+
+
+ General Principles
+
+ Music incipits help identify works and facilitate the comparison of historical musical sources.
+
+
+ Which music incipits to enter depends on the kind of music. Best practice for instrumental music is to enter
+ incipits for the violin or the highest part. For vocal music, enter the highest voice plus the first violin or
+ the highest instrumental part.
+
+
+ The incipit should be neither too long nor too short, and make as much musical sense as possible. It should
+ contain at least 3 bars or 10 non-repeated notes.
+
+
+ The code should be written on a single line. When using MARC-format subfields, omit the special characters that
+ precede the encoded notes.
+
+
+
+
+ The Plaine & Easie Code
+
+ Clef
+
+
+ The clef code is preceded by % and is three characters long.
+
+
+ The first character specifies the clef shape.
+
+
+
+ The second character is - to indicate modern notation or + to indicate mensural
+ notation.
+
+
+ The third character (numerals 1-5) indicates the position of the clef on the staff, starting from the bottom
+ line.
+
+
+ If the music is written for a transposing instrument, notate the incipit at sounding pitch.
+
+
+
+
+ Key Signature
+
+
+ Begin this field with the character $; if there are no sharps or flats in the key signature,
+ the $ is omitted.
+
+
+ The symbol x indicates sharp keys and b flat keys. The symbol is followed by the
+ capital letters that indicate the altered notes.
+
+
+
+
+ Time Signature
+
+
+ The time signature is preceded by @ and indicates the time value or the mensuration sign of the
+ incipit. If the incipit has no time signature, the @ is omitted.
+
+
+ Fractional or numeric values are transcribed as fractions and mensuration signs are transcribed with a
+ lowercase letter, if necessary followed by / or .:
+
+
+
+
+ Musical Notation
+
+
+ Octave Symbol
+
+ Apostrophes are used for the octaves c4 and above, while commas are used for the octaves c3 and below.
+
+
+
+
+
+ Rhythmic Values
+
+
+ Periods are used for dotted notes. Multiple periods can be added to a note.
+
+
+
+
+ Accidentals
+
+
+
+ Note Names
+ C, D, E, F, G, A, B
+
+
+ Grace Notes
+
+
+
+ Rests
+ Rests for single notes are indicated by - (a minus sign).
+
+
+
+ Code
+ Name
+
+
+
+
+ -single-note rest (preceded by rhythmic value like note names)
+
+
+ =measure rest (followed by number of measures and a bar line)
+
+
+
+
+
+
+
+
+ Bar (measure) Lines
+
+
+
+
+ Other Symbols
+
+
+
+ Beaming
+
+
+
+ Code
+ Note
+
+
+
+
+ {beginning of beaming
+
+
+ }end of beaming
+
+
+
+
+
+
+
+ Special Rhythmic Groupings
+
+
+
+ Code
+ Name
+
+
+
+
+ (beginning of special group
+
+
+ )end of special group
+
+
+
+
+ Before ( you must indicate the total value of the group.
+
+
+ After ( you must indicate the rhythmic value of the first note, even if it is equal to that
+ of the group.
+
+
+ Before ) you must indicate the number of notes of the group, preceded by ;.
+
+
+
+ The triplet is a special case; strictly speaking, it should be coded as follows:
+
+
+ 8(6ABC;3) or 8({6ABC};3)
+
+
+ Instead, the following shortcut is permitted:
+
+
+ (6ABC) or ({6ABC})
+
+
+ The rhythmic value inside the parentheses is required.
+
+
+
+ Shortcuts
+
+ Repeated figures
+
+
+
+ Code
+ Name
+
+
+
+
+ !beginning and end of passage
+
+
+ frepetition indication of the notes that appear within !...!
+
+
+
+
+ The group will be repeated as many times as the f appears after the second
+ !. Repetition is possible only within the same measure.
+
+
+
+
+ Repeated measures
+
+ The symbol i repeats the last measure. It must always be included within bar lines.
+
+
+
+
+ Rhythmic sequence
+
+ When the same rhythmic sequence is repeated, the sequence of rhythmic values can be stated once
+ before the note names.
+
+
+
+
+
+ Change of Clef, Key Signature, Time Signature
+
+ Use % to change the clef, $ to change the key, and @ to change
+ the time signature. Follow this with the new indication (clef, key, or time), followed by a space.
+
+
+ The introductory characters are mandatory.
+
+
+
+
+ Abbreviations
+
+ Notation abbreviations, such as tremolo, slash, etc., must be written out in full using the actual
+ notation.
+
+
+
+
+ Chords
+
+ Enter chords from the highest to the lowest note, each one separated by ^.
+
+
+
+
+
+ Coded Validity Note
+
+
+ A one-character coded validity note can be introduced by a ~ at the end of the code.
+
+
+ Accepted characters are:
+
+ ?: a mistake in the incipit has not been corrected+: a mistake in the incipit has been correctedt: incipit has been transcribed into modern notation
+
+
+ These characters may be explained in a note (UNIMARC 036 $q — MARC21 031 $q).
+
+
+
+
+ Representations
+
+ There are several ways in which Plaine & Easie code can be expressed. The choice of representation depends
+ on the environment in which you are using Plaine & Easie code, and the support of your software tools.
+
+
+ MARC21 and UNIMARC
+
+ The most common use of Plaine & Easie code is as part of a MARC (MAchine Readable Catalogue)
+ record or UNIMARC (UNIversal MARC). The 031 MARC field is used to record incipits for
+ bibliographic catalogues. For UNIMARC the 036 field is similarly used.
+
+
+ In MARC and UNIMARC records, the Plaine & Easie notation components are separated out into subfields.
+ The specifics of this encoding are given in the MARC
+ documentation, or in the
+ UNIMARC documentation.
+
+
+
+ Single-Line Text
+
+ Plaine & Easie code can be represented in a single, continuous line of text by using
+ the field delimiters for each notation component: % for clef,
+ $ for key signature, and @ for time signature. These components
+ are given at the beginning of the line, and separated by a space with the notation data.
+
+
+
+
+ Multi-Line Text with Field Delimiters
+
+ This format puts each component on its own line, separated by a newline character \n, and
+ with the component field preceded by a @ symbol and followed by a colon :.
+ There are five such fields: @clef, @keysig, @timesig,
+ @key, and @data.
+
+
+
+
+ JavaScript Object Notation (JSON)
+
+ JavaScript Object Notation (JSON) is a key-value format that is easy to process in web browsers. Some
+ tools may support Plaine & Easie encoding using JSON. The same field names as the multi-line format are
+ used, but the preceding @ is dropped. Fields are separated by a comma.
+
+
+
+
+
+
diff --git a/pr-preview/pr-126/v2/changes.html b/pr-preview/pr-126/v2/changes.html
new file mode 100644
index 0000000..e332bc4
--- /dev/null
+++ b/pr-preview/pr-126/v2/changes.html
@@ -0,0 +1,208 @@
+
+
+
+
+ Plaine & Easie Version 2 Change Log
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+ Breaking Changes
+
+ Clef is a required field
+
+ 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.
+
+
+
+ Encoding of fermatas
+
+ 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.
+
+
+
+ Order of elements within a note
+
+
+ Neume Notation
+
+ 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.
+
+
+
+ Changed tie to underscore
+
+ 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.
+
+
+
+ Removal of Coded Validity Note
+
+ 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.
+
+
+
+ Alternating Time Signatures
+
+ 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,
+ |.
+
+
+
+ Mensural Notation
+
+ 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.
+
+
+
+
+ New Features
+
+ Introduction of JSON as a representation format
+
+ JavaScript Object Notation (JSON) is now an accepted
+ representation format for the Plaine & Easie Code.
+
+
+
+
+ Clarifications
+
+ Order of elements within a note
+
+
+
+
diff --git a/pr-preview/pr-126/v2/guidelines.html b/pr-preview/pr-126/v2/guidelines.html
new file mode 100644
index 0000000..8bd3b70
--- /dev/null
+++ b/pr-preview/pr-126/v2/guidelines.html
@@ -0,0 +1,332 @@
+
+
+
+
+ Plaine & Easie Encoding Guidelines
+
+
+
+
+
+
+
+
+ CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
+
+
+
+
+
+ Introduction
+
+
+ These cataloging guidelines are written as an accompaniment to
+ the Plaine & Easie Code (PAEC) specification. In previous
+ editions of the specifications, the formal description of the
+ code, and the guidelines for its interpretation, were given as a
+ single document. Although convenient as a reference, it also
+ posed significant challenges for the interpretation of what was
+ actually required, and what was recommended.
+ In the new edition of the PAEC, the specification document
+ provides a formal description of a valid PAEC encoding, while
+ this document will provide recommendations on the application of
+ the code to incipit capture.
+
+
+
+ Considerations for Incipit Capture
+
+
+ The thematic index derives its superiority over non-thematic
+ lists be cause it can not only arrange a body of music in a
+ systematic order, but it provides, at the same time,
+ positive identification in a minimum of space and symbols.
+ It does so by the use of the "incipit," or musical citation
+ of the opening notes. For most music, an incipit of no more
+ than a dozen pitches is required. When rhythmic values
+ accompany the pitches, the incipit's "uniqueness quotient"
+ is astonishingly high.
+
+
+
+ A musical work, printed or manuscript, may be identified by
+ composer, title, opus number, key, instrumentation, movement
+ headings, first line of text, date, publisher, dedicatee,
+ plate number, etc. No one of these, indeed no combination of
+ these, can provide as certain an identification as an
+ incipit. For example, an anonymous 15th-century Latin motet
+ may also appear as a French chanson entitled "L'amant
+ douloureux." A composer may write a dozen trio sonatas in D
+ major, three of them with the same tempo sequence. A concert
+ aria found in a library in Vienna, in the key of F, may turn
+ up in Prague in the key of G, and with added horn parts. Two
+ printings of a set of quartets may be given different plate
+ numbers by the same publisher. Two publications of the same
+ opera, in different cities, may bear different titles, and
+ dedications to different patrons. Finally, a set of six
+ symphonies may be published in Amsterdam with one opus
+ number, in Offenbach with another, and in London within a
+ series of Periodical Overtures without any at all, and under
+ another composer's name.
+
+
+
+ By contrast, the presence of the incipit avoids confusion.
+ Identification is certain. Even transposed works can be
+ readily identified in properly organized incipit files. In
+ dealing with anonymi and with works of disputed authorship,
+ the incipit becomes indispensable-as a catalog without them
+ will readily demonstrate. In short, the collection,
+ classification, transposition, and lexicographical ordering
+ of the incipits into thematic catalogs have enabled scholars
+ to solve a myriad of otherwise insoluble problems, and have
+ provided musicians, librarians, students, biographers, and
+ program annotators with an invaluable reference tool.
+
+
+
+
+ The cataloging of musical incipits in RISM is primarily intended
+ for the purposes of identification and disambiguation, where all
+ other bibliographic means of doing so are not sufficient to
+ uniquely identify a musical piece.
+
+
+ The most important component of incipit cataloging is the
+ capture of identifiable musical material. This will, in most
+ cases, be the opening measures of a piece. It may, occasionally,
+ be the entrance of a melodic instrument when the opening of the
+ piece starts with otherwise ambiguous accompaniment, such as a
+ ground bass. In rare instances, it may be the entrance of a
+ theme that is many measures in.
+
+
+ In all cases, the encoder of the incipit must keep in mind the
+ primary motivations of identification and disambiguation when
+ choosing the musical content to capture as the incipit. It does
+ not serve the users of the catalog to encode a unique part of a
+ musical work when all other instances of the incipit in the
+ catalog identify the opening measures. The uniqueness of the
+ cataloging simply means that the incipit will not group with
+ like, and it will thus be "lost" in the larger catalog.
+
+
+ The capture of melodic and rhythmic qualities is of primary
+ importance. Considerations of visual appearance, phrasing,
+ polyphony, or other special indications are of secondary
+ importance, or should be ignored altogether, when capturing
+ incipits. While it may seem important to capture for any single
+ given source, it can also pose significant challenges to
+ positive identification or disambiguation when compared to all
+ other sources. Other means of capture, such as analytical notes
+ fields, may be a more suitable mechanism for accurately
+ describing these features.
+
+
+
+ The Plaine & Easie Code
+
+ From the beginning, the PAEC was purpose-built for the capture
+ of identifying incipits. It could be written by hand, or typed
+ on a standard mechanical typewriter. Unlike other codes, the
+ goal of the PAEC was to be simple. Indeed, the first version of
+ the PAEC, issued in 1964, was subsequently simplified in 1965,
+ to "make the code more usable on an international basis."
+ (Brook, Fontes, 1965). The current PAEC specification is based
+ primarily on this simplified version.
+
+
+ In the intervening years since the introduction of the PAEC, a
+ number of changes and additional features have been introduced.
+ In some cases these additions have significantly improved the
+ coding scheme; in other cases the additions have ultimately
+ distracted from the central purpose of the PAEC when put into
+ practice. The reasons for these changes are not always known.
+ They may have been in response to a specific need, or they may
+ have been added as a "nice-to-have" without an identified use
+ case. Whatever the reason, they have been available and widely
+ adopted and standardized, making it difficult to introduce
+ retrospective changes to the coding system to address problems
+ and clarify ambiguities. With no clear versioning scheme in
+ place, the previous version is now no longer updated, and is now
+ known as "Version 1".
+
+
+ The new version, Version 2, contains several
+ backwards-incompatible changes from Version 1. It is not the
+ case that incipits in Version 1 need to be "upgraded," nor is it
+ a problem to have software or other standards support PAEC
+ Version 1. It is simply a way to differentiate the two versions.
+ In most cases, unless the version of the incipit is plainly
+ stated as being Version 2, it should be assumed that it is
+ supposed to conform to Version 1 of the specification.
+
+
+ Version 2
+
+ The goals of the effort behind Version 2 were to clarify
+ ambiguities in the previous specification, and to make the
+ PAEC more suitable for machine processing of incipits. Since
+ the previous version was developed before the World Wide
+ Web, and even before there was software available to render
+ the code into a graphical representation, several parts of
+ the specification existed that made it difficult to
+ unambiguously and reliably process the data into the
+ notation it was intended to represent.
+
+
+ Version 2 of the specification is written to make the
+ requirements of the encoding system clear, to help software
+ developers to build applications that can process the data
+ in a uniform way. The requirements are given using
+ [RFC2119], which provide keywords, such as "MUST" and "MAY",
+ to indicate required or optional features, respectively.
+ Most of the sections in the specification have also been
+ expanded to include an actual description of the code, as
+ well as illustrative examples.
+
+
+
+ Maintenance
+
+ This version of the code is maintained by the International
+ Association of Music Libraries, Archives and Documentation
+ Centres (IAML) and the Répertoire International des Sources
+ Musicales (RISM) for use as an exchange format in the
+ library environment.
+
+
+
+
+ General Guidelines for Incipit Capture
+
+ Music incipits help identify works and facilitate the comparison
+ of historical musical sources.
+
+
+ Which music incipits to enter depends on the kind of music. Best
+ practice for instrumental music is to enter incipits for the
+ violin or the highest part. For vocal music, enter the highest
+ voice plus the first violin or the highest instrumental part.
+
+
+ The incipit should be neither too long nor too short, and make
+ as much musical sense as possible. It should contain at least 3
+ bars or 10 non-repeated notes.
+
+
+ If the music is written for a transposing instrument, notate the
+ incipit at sounding pitch.
+
+
+ Tremolo, Slash
+
+ Notation abbreviations, such as tremolo, slash, etc., must
+ be written out in full using the actual notation.
+
+
+
+
+
+
diff --git a/pr-preview/pr-126/v2/index.html b/pr-preview/pr-126/v2/index.html
new file mode 100644
index 0000000..57bad86
--- /dev/null
+++ b/pr-preview/pr-126/v2/index.html
@@ -0,0 +1,2392 @@
+
+
+
+
+
+ Plaine & Easie Code
+
+
+
+
+
+
+
+
+
+
+ CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
+
+
+
+ The Plaine & Easie Code is a music notation encoding system
+ designed for the capture of melodic incipits: Short fragments of
+ music notation that help to identify the musical work.
+
+
+
+ Introduction
+
+ The Plaine & Easie Code was first defined in 1964 by Barry S. Brook and Murray Gould
+ [[BrookGould1964]][[Brook1965]]. Perhaps the most important design feature of this system
+ was that it could represent music notation with "ordinary" typewriter characters, to be
+ put on index cards to build a thematic index to accompany bibliographic source descriptions.
+
+
+ The specifics of the code system have changed over time, but, until the present specification,
+ the changes have not been clearly versioned. Features have been added to the Plaine & Easie
+ Code and the expected publication medium has shifted from index cards to computer systems. These
+ changes have resulted in incipits that may have conformed to the specifications at the time, but
+ which are now at odds with current practices and methods.
+
+
+ The present specifications seeks to establish a clearly defined "Version 2"
+ of the Plaine & Easie Code. This is an attempt to distinguish it from "Version 1" of the Code,
+ which is now fixed at its last revision date. Incipits encoded to the specifications
+ given in Version 1 are still valid, and will continue to be.
+
+
+ Version 2 of the Plaine & Easie Code is written in a specification language that attempts
+ to clearly communicate the normative requirements of the Code. This is a recognition that the
+ a significant "audience" for the code is data processing systems, and by extension, the
+ programmers that create them. This audience needs clear definitions of the code so that it
+ can be accurately and uniformly processed for search, retrieval, automated comparison,
+ and notation display.
+
+
+ At the same time, however, it must be recognized that the core of this code must remain "Plaine"
+ and "Easie" to facilitate easy capture of musical notation by catalogers. Although now couched
+ in normative language, the present specification does not deviate far from the earlier
+ specifications—indeed, some changes that are introduced in this new version are drawn from
+ the original papers by Brook and Gould. In this way, the present specification is an
+ attempt to "pave the cowpaths";
+ that is, to normalize and standardize existing practices.
+
+
+ Catalogers who are familiar with Version 1 of the Plaine & Easie Code may wish to consult
+ the Change Log to see what has changed in Version 2.
+
+
+ The Plaine & Easie Code is maintained by the Digial and Editorial Centers of the
+ Répertoire International des Sources Musicales (RISM), and by the International Association of Music
+ Libraries, Archives and Documentation Centres (IAML) for use as an exchange format in the library environment.
+
+
+
+
+
+ Terminology
+
+ - Circle of fifths
+
+ - Transcriber
+ - The person or persons who transcribe the source into Plaine & Easie.
+ - Logical Unit
+ - A logical unit of notation data consists of one or more characters that represent a single musical notation
+ figure.
+
+
+
+
+
+ Staff Definitions
+
+ The clef, key signature, and time signature of an incipit is defined separately from the
+ Musical Notation of the incipit. These properties affect the whole staff.
+
+
+
+
+ Clef
+
+ Every encoding MUST include a clef.
+
+
+ The clef code MUST be three characters long. The first character specifies the clef shape and MUST
+ be one of the values G, g (octave G), C, or F.
+
+
+ The second character MUST be one of the characters - to indicate modern notation,
+ * to indicate mensural notation, or : to indicate neume notation. Each
+ of these notations impose different interpretations on the music notation in the incipit.
+
+
+ The third character MUST be a numeric value in the range 1-5, and indicates the reference staff line
+ for the clef starting from the bottom.
+
+
+
+ The clef indications imply the octave in which each note on the staff will sound and
+ its visual placement on the staff. The following table gives the indicative octave and note
+ for the bottom and top lines of each staff.
+
+
+
+ Shape and Line
+ Bottom Line Octave and Note
+ Top Line Octave and Note
+
+
+
+
+ G-2'E (E4)''F (F5)
+
+ F-4,,G (G2),A (A3)
+
+ g-2,E (E3)'F (F4)
+
+ C-3,F (F3)'G (G4)
+
+
+
+
+
+ Key Signature
+
+ An encoding MAY include a key signature.
+
+
+ The character x indicates sharp keys and b flat keys. These characters MUST be
+ followed by a list of Note Names that indicate the altered notes.
+
+
+ The list of note names in a key signature SHOULD follow the circle of fifths ordering. Missing
+ accidentals in this list SHOULD be supplied by the transcriber. Note names MUST NOT be repeated.
+
+
+ All notes given in the key signature MUST be interpreted as having their sounding pitch altered
+ accordingly. In cases where a note in a key signature is further altered by use of an
+ accidental, directly on the note, the written pitch and
+ sounding pitch indicated by the accidental will take precedence.
+
+
+ A key signature MAY contain note names within square brackets [] to indicate that the
+ note names are not in the original source and have been supplied by the transcriber. Consecutively
+ supplied note names MUST be within a single set of brackets. A key signature MAY contain more than one
+ set of non-consecutive bracket groups.
+
+
+ A key signature containing a single n character MAY be supplied to indicate a natural key
+ signature, i.e., C Major or A minor. This character MUST NOT be followed by any note names.
+
+
+
+ For neume notation, the key signature MUST be omitted. Any alterations to individual pitches MUST
+ be encoded as accidentals.
+
+
+
+
+
+ Time Signature
+
+ An encoding MAY include a time signature.
+
+
+ There are two main categories of time signature forms, Common Western Music Notation
+ (CWMN) and Mensural.
+
+
+ For neume notation, the time signature MUST be omitted.
+
+
+ CWMN and Mensural time signatures MUST NOT
+ be mixed on the same staff.
+
+
+ CWMN time signatures are expressed as one number
+ above another. These numbers MUST be separated by a / character. Any positive digit MAY
+ be used, but encoders SHOULD use commonly accepted values where possible. The c
+ ("common", or 4/4) and c/ ("alla breve", or 2/4) characters
+ MAY be used.
+
+
+ CWMN time signatures that indicate alternating
+ measures MAY be indicated by transcribing both. These MUST be separated by a vertical bar
+ | character.
+
+
+ For mensuration signs, the c and o characters indicate tempus
+ imperfectus and tempus perfectus, respectively. The . character indicates
+ "major" prolation; omitting . indicates "minor" prolation. A / character may
+ follow the tempus character to indicate diminution.
+
+
+ A mensuration sign MAY include a numerical component as a proportion or augmentation,
+ indicating Modus cum tempore. These numerals MUST be either a 3 or 2.
+ These numbers MAY be combined and separated by a /.
+
+
+
+
+
+ Musical Notation
+
+
+ Structure
+
+ The Musical Notation section of an encoding is given as a single line of characters representing
+ a staff of musical notation. Notes and rests are the most basic logical unit
+ of notation representation, composed of one or more characters that specify different attributes
+ of a note or rest symbol. Complex notational figures, such as chords, beams, or tuplets, serve
+ to group notes and rests. Ornaments alter the performance of a note, a rest, or
+ groups thereof. Other staff and measure symbols can control the definition of the staff
+ itself: bar lines, cross-measure rests, or a change of clef, key signature, or time signature.
+
+
+ Many characters representing a musical note are optional—the only required character is the
+ note name. Where one or more characters for a note occurs, they MUST occur in the following order:
+
+
+
+ Note Feature
+ Characters
+ Requirement
+
+
+
+
+ Octave
+ [,']Optional
+
+
+ Duration / Duration Dot
+ [0-9][.]Optional
+
+
+ Accidental
+ [xb]Optional
+
+
+ Note Name
+ [A-G]Required
+
+
+ Order of characters representing a note
+
+
+ Logical units MAY be nested to represent complex notational features; for example, a beam will
+ contain two or more notes, or tuplet may be composed of two or more chords. All logical units
+ of the same kind MUST be closed before a new one is started (i.e., no nested groups of the same kind).
+
+
+
+ Many logical units use the same character(s) to represent the same musical concept. Both notes and rests,
+ for example, make use of the same duration character(s).
+
+
+ There MUST be no spaces within the Musical Notation section. The only time a space MAY occur is to separate
+ a change of Clef, Key Signature, or Time Signature.
+
+
+
+ Notes and Rests
+
+ Durations
+
+ Note durations MUST be represented by integer values in the range 0-9. The corresponding
+ note value for each number is given in [[[#note-duration-map]]].
+
+
+ Duration values MUST be interpreted differently if the encoding is in
+ CWMN or Mensural notation. Mensural notation
+ MUST NOT use durations of 3, 5, or 7.
+
+
+ Notes in neume notation MUST NOT be given a duration value.
+
+
+
+
+ Duration
+ Notation
+ CWMN
+ Mensural
+
+
+
+
+
+
+ 0
+
+ Longa
+
+
+
+
+ 9
+
+ Breve
+
+
+
+
+ 1
+
+ Whole note
+ Semibreve
+
+
+
+
+ 2
+
+ Half note
+ Minim
+
+
+
+
+ 4
+
+ Quarter note / crochet
+ Semiminim
+
+
+
+
+ 8
+
+ Eighth note / quaver
+ Fusa
+
+
+
+
+ 6
+
+ 16th note / semiquaver
+ Semifusa
+
+
+
+
+ 3
+
+ 32nd note / demisemiquaver
+ -
+
+
+
+
+ 5
+
+ 64th note / hemidemisemiquaver
+ -
+
+
+
+
+ 7
+
+ 128th note
+ -
+
+
+
+ Note duration value mapping, ordered from longest to shortest note value.
+
+
+ The duration value for a given note MAY be omitted. If the duration is omitted, the last specified
+ duration is used for all following notes.
+
+
+ An encoding MAY omit all duration indications. If no duration is supplied on any note, all
+ notes are assumed to have a duration value of 4 (quarter note / crochet / semiminim).
+
+
+ For CWMN the period character . MAY be used to indicate a dot of augmentation,
+ extending the duration of the note by half again the indicated duration value. This character MUST be
+ appended to the duration value. Multiple dots MAY be used, with each successive dot indicating that
+ the duration is extended by half again.
+
+
+
+
+ Note Names
+
+ A note name MUST be provided to indicate the pitch class of the note.
+
+
+ Note names MUST be one of the following characters:
+ C, D, E, F,
+ G, A, B.
+
+
+ All letters MUST be uppercase; lowercase letters MUST NOT be used.
+
+
+
+
+ Octaves
+
+ Octaves in Plaine & Easie are enumerated according to [[ScientificPitch]]. The boundary note
+ between octaves is C.
+
+
+ Octaves MUST be indicated using the apostrophe ' for octave C4 and above, and the comma
+ , for octaves C3 and below. These characters are repeated to indicate successively
+ higher or lower octaves: '' indicates C5, ''' indicates C6, ,,
+ indicates C2, and so on.
+
+
+ The number of apostrophes MUST NOT exceed four, corresponding to C7. The number of commas MUST NOT
+ exceed three, corresponding to C1.
+
+
+ The octave indication for a given note MAY be omitted. If the octave is omitted, the last specified
+ octave indication is used for all following notes.
+
+
+ An encoding MAY omit all octave indications. If no octave is supplied on any note, all notes are
+ assumed to be in octave C4.
+
+
+
+
+ Accidentals
+
+ An accidental MAY be used to alter the written and sounding pitch of a note. Accidentals MUST
+ be one of the values given in [[[#accidental-map]]].
+
+
+
+
+ Accidental
+ Notation
+ Remarks
+
+
+
+
+
+
+ x
+
+ sharp
+
+
+
+
+ b
+
+ flat
+
+
+
+
+ xx
+
+ double-sharp
+
+
+
+
+ bb
+
+ double-flat
+
+
+
+
+ n
+
+ natural
+
+
+
+
+ Accidental values
+
+
+ The sounding pitch of a note MAY be altered by both a key signature or an accidental. In the case of
+ a note being altered by both, the alteration of the accidental MUST be interpreted as an alteration
+ of the pitch in the key signature.
+
+
+ A note altered by an accidental SHOULD NOT be altered subsequent times within the same bar. The
+ alteration to the sounding pitch of the note is continued on subsequent notes with the same name
+ until the next Bar Line.
+
+
+ Accidentals MUST be interpreted by their written value, and MUST NOT be interpreted by their values
+ relative to each other.
+
+
+
+
+ Single Rests
+
+ Rests for single notes MUST be indicated by a hyphen/minus character -. This character
+ MAY be preceded by a duration value giving the musical duration of the rest.
+ If the duration is omitted, the last specified duration is used. If no duration is supplied in the
+ encoding a default duration of 4 is assumed.
+
+
+
+
+
+ Groups
+
+
+ Ties
+
+ Tied notes MUST be indicated with an underscore character _.
+ Ties MUST occur between successive notes with the same pitch and octave.
+ A tie MUST NOT occur between a note and a rest.
+
+
+ The underscore character MUST occur on the first note of the tie.
+
+
+ Tied notes MAY occur over bar lines.
+
+
+ The underscore character MUST NOT be used to indicate slurs, phrase
+ marks, or ligatures.
+
+
+
+
+
+ Ligatures
+
+ Todo.
+
+
+
+ Beams
+
+ Beamed notes are encoded using braces {}.
+
+
+ Beam groups MUST start with an opening brace {, and
+ MUST end with a closing brace, }. Nested beam groups
+ MUST NOT occur, except as part of an Appogiatura Group.
+
+
+ Notes with duration values of 0, 1, 2,
+ 4, and 9 MUST NOT occur within
+ a beam group. Notes with other duration values MAY occur within
+ a beam group.
+
+
+ Beam groups SHOULD NOT occur in Mensural encodings.
+
+
+
+
+
+ Tuplets
+
+ A tuplet group MUST begin with a duration value to indicate the duration
+ of the tuplet group.
+
+
+ All musical symbols MAY occur within a tuplet group. The members of the tuplet
+ group MUST be enclosed within parentheses ().
+
+
+ The duration value MUST be provided for the first note or rest after the
+ opening parenthesis (.
+
+
+ A semicolon ; and a non-negative integer MAY immediately precede
+ the closing parenthesis of a tuplet group. This number indicates the number of
+ beat divisions in the group; that is, the number of beats that occur within
+ the tuplet in the space of the given duration value. If a number is not
+ given, a value of 3 is the default.
+
+
+ Since the default number of beats in the tuplet is 3, these two
+ encodings of a triplet are considered to be equivalent:
+
+
+
+
+
+ Chords
+
+
+
+
+ Enter chords from the highest to the lowest note, each one separated by ^.
+
+
+
+
+
+ Ornaments
+
+ Trills
+
+ The lower-case character t is used to indicate
+ a trilled note. The t MUST immediately follow the
+ note name.
+
+
+
+
+ Fermatas
+
+ The lower-case character p is used to indicate
+ a fermata on a note. The p MUST follow the note name.
+ If there is also a Trill, the p MUST follow
+ the trill character.
+
+
+
+
+ Grace Notes
+
+ There are two types of grace note: Acciaccatura and appogiatura.
+
+
+ For a single acciaccatura the lower-case character g
+ MUST be used. This character MUST precede the note name, and MUST
+ also precede all other attributes of the note. Consecutive single
+ acciaccatura MUST NOT occur.
+
+
+ For a single appogiatura note, the lower-case character q
+ MUST be used. This character MUST precede the note name, and MUST
+ also precede all other optional attributes of the note.
+
+
+ Consecutive appogiatura notes SHOULD be encoded using an
+ Appogiatura Group. Consecutive single appogiatura SHOULD NOT occur.
+
+
+
+ Appogiatura Groups
+
+ For multiple consecutive appogiatura notes, the appogiatura group SHOULD
+ be used. The lower-case characters qq MUST be given as the first
+ characters before the first note of the group, and the lower-case character
+ r MUST be the last character in the final note of the group.
+ There MUST be more than one note in a appogiatura group.
+
+
+ The r character MUST follow the closing beam character
+ that is part of the appogiatura group.
+
+
+ An appogiatura group with beams MAY occur within a non-appogiatura
+ beam.
+
+
+
+
+
+
+ Measure and Staff Symbols
+
+ Bar Lines
+
+ Bar lines MUST be indicated using one of the code options given in [[[#barlines-spec]]].
+
+
+ Bar lines SHOULD be inserted at intervals that correspond to the current time signature.
+
+
+ Neume and Mensural notations SHOULD NOT use bar lines.
+
+
+
+
+ Code
+ Notation
+ Remarks
+
+
+
+
+
+
+ /
+
+ Single bar line
+
+
+
+
+ //
+
+ Double bar line
+
+
+
+
+ //:
+
+ Double bar line with repeat sign on the right
+
+
+
+
+ ://
+
+ Double bar line with repeat sign on the left
+
+
+
+
+ ://:
+
+ Double bar line with repeat sign on the left and on the right
+
+
+
+ Types of bar lines
+
+
+
+
+ Measure Rests
+
+ Measure rests MUST be indicated by an equal sign character =. This character MUST be
+ followed by a non-negative integer indicating the number of measures for which this rest applies,
+ unless the measure rest only applies to a single measure. In this case, the number MAY be omitted.
+
+
+ Measure rests MUST be followed by a bar line character.
+
+
+ Measure rests MUST NOT be used with Mensural notation, due to the general absence of measures in
+ this system of notation.
+
+
+ Measure rests MAY indicate the number of measures that are being skipped in the
+ original source before the musical content being captured by the incipit, regardless of whether
+ these measures in the original source contain musical content.
+
+
+
+
+ Changes to Staff Definitions
+
+ Clefs, key signatures, and time signatures MAY be changed within an incipit.
+
+
+ The percent character % MUST be used to indicate a clef change. A clef change MAY occur
+ anywhere
+ within the music notation section. This character MUST be followed by a clef definition according
+ to the specifications given in the Clef section.
+
+
+ The dollar character $ MUST be used to indicate a key signature change. A key signature
+ change MAY appear anywhere in the music notation, but SHOULD appear immediately following a
+ bar line. This character MUST be followed by a key signature definition according to the
+ specifications given in the Key Signature section.
+
+
+
+ The at sign character @ MUST be used to indicate a time signature change. A time signature
+ change MAY appear anywhere in the music notation, but SHOULD appear immediately following a
+ bar line. This character MUST be followed by a time signature definition according to the
+ specifications given in the Time Signature section.
+
+
+ For any change of clef, key signature, time signature, or combination thereof, the change indication
+ MUST be separated from the notation that follows by a single space character. In the case of multiple
+ changes at once (for example, a key and a time signature change) the individual change indications
+ MUST NOT be separated by a space.
+
+
+
+
+
+ Shortcuts
+
+ Repeat group
+
+ If one or notes or rests are repeated several times, a repeat group
+ MAY be used.
+
+
+ A repeat group is only valid within a single measure.
+
+
+ To use a repeat group, mark the beginning and the end of the group with
+ an exclamation mark character !. The lower-case character
+ f MUST immediately follow the ending !, and
+ MUST occur the number of times the figure should be repeated. The
+ f MUST be specified at least once.
+
+
+
+
+ Repeated measures
+
+ If one or more whole measures are repeated, a measure
+ repeat MAY be used.
+
+
+ The measure to be repeated MUST end with a bar line. The lower-case
+ character i MUST occur immediately after this bar line,
+ and MUST be immediately followed by another bar line. There MUST NOT
+ be any other characters between the two bar lines.
+
+
+ Any type of bar line MAY be used to begin or end a measure repeat group.
+
+
+ Measure repeats SHOULD NOT be used with Mensural notation.
+
+
+
+
+ Rhythmic sequence
+
+ When the same rhythmic sequence is repeated, the sequence of rhythmic values can be stated once
+ before the note names.
+
+
+
+
+
+
+ Representation Formats
+
+ The original expression of the Plaine & Easie Code was intended for physical
+ media such as an index card, or a printed book. In the intervening years, usage of the
+ Plaine & Easie Code has shifted to use within a digital context, such as online
+ library catalogs and on the World Wide Web.
+
+
+ This section provides the specification of the acceptable representations of the Plaine &
+ Easie Code. It is expected that these representations—with the possible exception of
+ "single-line text"—are constructed and used by automated tools and not written "by hand."
+
+
+ Character Encodings
+
+ All characters used in the Plaine & Easie Code MUST be within the [[ASCII]]
+ code range. Plaine & Easie MAY be transmitted as part of another encoding standard,
+ such as UTF-8, as long as the characters used within the encoding itself do not
+ fall outside of the ASCII range.
+
+
+ Depending on the application, some ASCII characters MAY be encoded in another
+ way; for example, Plaine & Easie Code could be embedded in HTML where some
+ characters are replaced by Named
+ character references.
+
+
+
+
+ MARC21 and UNIMARC
+
+ The Plaine & Easie code is accepted as a format within a MARC (MAchine Readable Catalogue)
+ or UNIMARC (UNIversal MARC) record. The specifics of each system are given in the [[MARC21]]
+ documentation or in the [[UNIMARC]] documentation. The 031 MARC21 field is used
+ to record incipits, while UNIMARC uses the 036 field. The subfields used by these
+ formats for Plaine & Easie Code is given in [[[#marc21-unimarc-subfields]]].
+
+
+ In both systems, the $2 subfield indicates the coding system used for the
+ incipit. This code MUST be pe2 for Version 2 of the Plaine & Easie Code.
+
+
+
+
+
+ Field
+ MARC21
+ UNIMARC
+
+
+
+
+ Clef
+ $g$m
+
+ Key Signature
+ $n$n
+
+ Time Signature
+ $o$o
+
+ Musical Notation
+ $p$p
+
+ Source
+ $2$2
+
+
+ MARC21 and UNIMARC subfields for the Plaine & Easie Code
+
+
+
+ Multi-Line Text with Field Delimiters
+
+ The Plaine & Easie Code MAY be represented in a multi-line text format.
+
+
+ Each field MUST be separated by a newline character \n.
+
+
+ Each field MUST begin with a field identifier. This identifier consists of an at sign
+ character @, followed by a field name. The field identifier MUST end with
+ a colon character :.
+
+
+ The field name MUST be one of the following: clef, keysig, timesig,
+ key, data, or version.
+
+
+ The field value MUST immediately follow the colon in the field identifier. The field value MUST NOT
+ contain any characters that are not part of the value itself; for example, the value must not be
+ enclosed in quotation marks.
+
+
+ There MUST be at least two fields in the encoding: clef and data.
+
+
+ The version field MAY be included. The value of the version field
+ MUST be pe2 for incipits that conform to Version 2 of the specification. If a
+ version field is not specified, the incipit SHOULD be interpreted as conforming
+ to Version 1 of the specification.
+
+
+
+
+ JavaScript Object Notation (JSON)
+
+ Plaine & Easie Code MAY be represented as JavaScript Object Notation
+ ([[JSON]]). All JSON encodings of the Plaine & Easie Code MUST be valid
+ JSON.
+
+
+ The keys in the JSON MUST be one of the following: clef,
+ keysig, timesig, key,
+ data, or version. Unlike the multi-line text
+ representation, they MUST NOT begin with an at sign character @.
+
+
+ There MUST be at least two keys in the encoding: clef and data.
+
+
+ The version key MAY be included. The value of the version key
+ MUST be pe2 for incipits that conform to Version 2 of the specification. If a
+ version key is not specified, the incipit SHOULD be interpreted as conforming
+ to Version 1 of the specification.
+
+
+
+
+ Single-Line Text
+
+ Plaine & Easie code MAY be represented in a single, continuous line of text.
+
+
+ This line MUST start with the string ;pe2 for incipits that
+ conform to Version 2 of the specification.
+
+
+ Following the version declaration, the line MUST contain with a declaration of the clef.
+ The format of the clef declaration follows the same format for an inline change of clef;
+ that is, the clef declaration MUST start with the percent character %.
+
+
+ The line of text SHOULD specify a key signature and a time signature. This also
+ follows the same format for an inline change of key and time signatures.
+
+ The clef, key signature, and time signature declarations MUST NOT themselves be
+ separated by a space character.
+
+
+ The clef, key signature and time signature MUST be separated from the rest of the music
+ notation by a single space character.
+
+
+ The rest of the line of text follows the format for the music notation section of the code.
+ Further changes to the clef, key signature, and time signature are permitted as normal.
+
+
+
+
+
+
+
+ Changes
+
+ A list of substantive changes between Version 1 and Version 2 of the Plaine & Easie Code
+ can be found in the Change Log.
+
+
+
+
+
+
+
+ 
+