` 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-81/README.md b/pr-preview/pr-81/README.md
new file mode 100644
index 0000000..7a23944
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/HEAD b/pr-preview/pr-81/bare_pr_preview/HEAD
new file mode 100644
index 0000000..b870d82
--- /dev/null
+++ b/pr-preview/pr-81/bare_pr_preview/HEAD
@@ -0,0 +1 @@
+ref: refs/heads/main
diff --git a/pr-preview/pr-81/bare_pr_preview/config b/pr-preview/pr-81/bare_pr_preview/config
new file mode 100644
index 0000000..d14c137
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/description b/pr-preview/pr-81/bare_pr_preview/description
new file mode 100755
index 0000000..498b267
--- /dev/null
+++ b/pr-preview/pr-81/bare_pr_preview/description
@@ -0,0 +1 @@
+Unnamed repository; edit this file 'description' to name the repository.
diff --git a/pr-preview/pr-81/bare_pr_preview/hooks/applypatch-msg.sample b/pr-preview/pr-81/bare_pr_preview/hooks/applypatch-msg.sample
new file mode 100755
index 0000000..a5d7b84
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/commit-msg.sample b/pr-preview/pr-81/bare_pr_preview/hooks/commit-msg.sample
new file mode 100755
index 0000000..b58d118
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/fsmonitor-watchman.sample b/pr-preview/pr-81/bare_pr_preview/hooks/fsmonitor-watchman.sample
new file mode 100755
index 0000000..23e856f
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/post-update.sample b/pr-preview/pr-81/bare_pr_preview/hooks/post-update.sample
new file mode 100755
index 0000000..ec17ec1
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/pre-applypatch.sample b/pr-preview/pr-81/bare_pr_preview/hooks/pre-applypatch.sample
new file mode 100755
index 0000000..4142082
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/pre-commit.sample b/pr-preview/pr-81/bare_pr_preview/hooks/pre-commit.sample
new file mode 100755
index 0000000..29ed5ee
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/pre-merge-commit.sample b/pr-preview/pr-81/bare_pr_preview/hooks/pre-merge-commit.sample
new file mode 100755
index 0000000..399eab1
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/pre-push.sample b/pr-preview/pr-81/bare_pr_preview/hooks/pre-push.sample
new file mode 100755
index 0000000..4ce688d
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/pre-rebase.sample b/pr-preview/pr-81/bare_pr_preview/hooks/pre-rebase.sample
new file mode 100755
index 0000000..6cbef5c
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/pre-receive.sample b/pr-preview/pr-81/bare_pr_preview/hooks/pre-receive.sample
new file mode 100755
index 0000000..a1fd29e
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/prepare-commit-msg.sample b/pr-preview/pr-81/bare_pr_preview/hooks/prepare-commit-msg.sample
new file mode 100755
index 0000000..10fa14c
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/push-to-checkout.sample b/pr-preview/pr-81/bare_pr_preview/hooks/push-to-checkout.sample
new file mode 100755
index 0000000..af5a0c0
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/hooks/update.sample b/pr-preview/pr-81/bare_pr_preview/hooks/update.sample
new file mode 100755
index 0000000..c4d426b
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/info/exclude b/pr-preview/pr-81/bare_pr_preview/info/exclude
new file mode 100755
index 0000000..a5196d1
--- /dev/null
+++ b/pr-preview/pr-81/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-81/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.idx b/pr-preview/pr-81/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.idx
new file mode 100644
index 0000000..064be2d
Binary files /dev/null and b/pr-preview/pr-81/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.idx differ
diff --git a/pr-preview/pr-81/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.pack b/pr-preview/pr-81/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.pack
new file mode 100644
index 0000000..d6654af
Binary files /dev/null and b/pr-preview/pr-81/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.pack differ
diff --git a/pr-preview/pr-81/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.rev b/pr-preview/pr-81/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.rev
new file mode 100644
index 0000000..f42a6f6
Binary files /dev/null and b/pr-preview/pr-81/bare_pr_preview/objects/pack/pack-378923358f7fe31a0e073b92765141e67fcb5579.rev differ
diff --git a/pr-preview/pr-81/bare_pr_preview/packed-refs b/pr-preview/pr-81/bare_pr_preview/packed-refs
new file mode 100644
index 0000000..13103b0
--- /dev/null
+++ b/pr-preview/pr-81/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-81/index.html b/pr-preview/pr-81/index.html
new file mode 100644
index 0000000..2817f32
--- /dev/null
+++ b/pr-preview/pr-81/index.html
@@ -0,0 +1,41 @@
+
+
+
+ The Plaine & Easie Code
+
+
+
+Plaine & Easie Music Notation
+
+
+ The Plaine & Easie Code is a library standard that enables entering music incipits in modern or mensural
+ notation.
+
+
+Version 1
+
+
+ Plaine & Easie version 1 is the current accepted version of the specification.
+
+
+Version 2
+
+
+ Plaine & Easie version 2 specification is under preparation. It is due to contain
+ significant backwards-incompatible 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-81/static/img/dc-logo.png b/pr-preview/pr-81/static/img/dc-logo.png
new file mode 100644
index 0000000..c1131c8
Binary files /dev/null and b/pr-preview/pr-81/static/img/dc-logo.png differ
diff --git a/pr-preview/pr-81/static/img/edc-logo.png b/pr-preview/pr-81/static/img/edc-logo.png
new file mode 100644
index 0000000..68753b0
Binary files /dev/null and b/pr-preview/pr-81/static/img/edc-logo.png differ
diff --git a/pr-preview/pr-81/static/js/verovio-rendering.js b/pr-preview/pr-81/static/js/verovio-rendering.js
new file mode 100644
index 0000000..820b8b0
--- /dev/null
+++ b/pr-preview/pr-81/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-81/v1/index.html b/pr-preview/pr-81/v1/index.html
new file mode 100644
index 0000000..74a0807
--- /dev/null
+++ b/pr-preview/pr-81/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-81/v2/guidelines.html b/pr-preview/pr-81/v2/guidelines.html
new file mode 100644
index 0000000..9367363
--- /dev/null
+++ b/pr-preview/pr-81/v2/guidelines.html
@@ -0,0 +1,224 @@
+
+
+
+
+ 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.
+
+
+
+
diff --git a/pr-preview/pr-81/v2/index.html b/pr-preview/pr-81/v2/index.html
new file mode 100644
index 0000000..19039cd
--- /dev/null
+++ b/pr-preview/pr-81/v2/index.html
@@ -0,0 +1,1738 @@
+
+
+
+
+
+ Plaine & Easie Code
+
+
+
+
+
+
+
+
+
+
+ CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
+
+
+
+ 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.
+
+
+ Also available in PDF format.
+
+
+ Adapted from the RISM guidelines.
+
+
+
+
+ Terminology
+
+ - Circle of fifths
+
+ - Transcriber
+ - The person or persons who transcribe the source into Plaine & Easie.
+
+
+
+ The Plaine & Easie Code
+
+
+
+ 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, or
+ + to indicate mensural notation. (See: [[MensuralReference]])
+
+
+ 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.
+
+
+
+
+
+ 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.
+
+
+ A key signature containing a single n character MAY be supplied to indicate a natural key
+ signature. This character MUST NOT be followed by any note names.
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+ 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.
+ If a mensuration sign is specified, the clef MUST specify a + separator to
+ indicate the encoding is in mensural notation.
+
+
+ Encodings MUST NOT mix CWMN and Mensural
+ time signatures.
+
+
+ If an encoding omits a time signature, the encoding MUST be interpreted as CWMN.
+
+
+ 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. For "common" and
+ "alla breve" key signatures, use c and c/, respectively.
+
+
+ CWMN time signatures that indicate alternating
+ measures MAY be indicated by transcribing both. These MUST be separated by a single space 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
+
+
+
+
+ Note Names
+
+ A note name MUST be provided to indicate the pitch class of the encoded note.
+
+
+ Note names MUST be one of the following characters: C, D, E,
+ F, G, A, B.
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+ 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.
+
+
+ For Mensural notation the period character . MAY be used to indicate a dot of division to
+ alter the interpretation of ternary values. Multiple successive dots of division MUST NOT occur.
+
+
+
+
+ Accidentals
+
+
+
+
+ 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)
+
+
+
+
+
+
+
+
+ Chords
+
+
+
+
+ Enter chords from the highest to the lowest note, each one separated by ^.
+
+
+
+
+ Beaming
+
+
+
+
+ Code
+ Remarks
+
+
+
+
+ {beginning of beaming
+
+
+ }end of beaming
+
+
+
+
+
+
+
+ Bar Lines
+
+
+
+
+ Tuplets
+
+
+
+ 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.
+
+
+
+ Other Symbols
+
+
+
+
+ Grace Notes
+
+
+
+
+
+ Trill
+
+ TODO: Expand on trill encoding
+
+
+
+ Fermata
+
+ TODO: Expand on fermata encoding
+
+
+
+ Tremolo, Slash
+
+ Notation abbreviations, such as tremolo, slash, etc., must be written out in full using the actual
+ notation.
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+ 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.
+
+
+
+
+ Field
+ MARC21
+ UNIMARC
+
+
+
+
+ Clef
+ $g$m
+
+ Key Signature
+ $n$n
+
+ Time Signature
+ $o$o
+
+ Musical Notation
+ $p$p
+
+ MARC21 and UNIMARC subfields for Plaine & Easie
+
+
+
+ Single-Line Text
+
+ Plaine & Easie code can be represented in a single, continuous line of text. This line
+ MUST start with a declaration of the clef, key signature, and time signature, and they
+ MUST be in that order. Each of these components are preceded by a delimiter character: %
+ for clef, $ for key signature, and @ for time signature. There
+ MUST NOT be a space between the components. There MUST be a space between these declarations
+ and the notation.
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+ 
+