Hi all,
I've started some serious work on the scholarLY package
(https://github.com/openlilylib/scholarly) and will presumably have a
bunch of questions over the next few weeks, both on design/interface,
and implementation.
[For all users of scholarLY: I also expect that this *may* end up in
breaking changes. I hope to avoid that but it's possible that
substantial enhancements can't be accommodated with the existing interface.]
One thing I'm going to add is the ability to encode variants of various
kinds (some examples: readings of different sources; original text vs.
regularized/corrected/edited text; substitutions/deletions (i.e. the
writer of the source edited the text)). The model for this are the
respective sections of the MEI specification
(http://music-encoding.org/guidelines/v3/content/critapp.html,
http://music-encoding.org/guidelines/v3/content/edittrans.html),
although I have come to the conclusion that it's not worth implementing
it as an exact match.
As a first step I've identified the overall structure this should get:
* There are unary commands to mark up a music expression as an
editorial element like (MEI:) <sic>/<corr>, <reg>/<orig> etc. These
may or may not (at the discretion of the editor) produce some visual
highlighting (e.g. printing errors in the source in red).
* There is a choice (or variant) command that can wrap multiple of the
unary commands and the editor can decide which ones to engrave (e.g.
always the corrected text, always the original etc.)
* (I'm not fully clear yet how that will relate to the existing
annotations. Probably it will be possible to use such a choice as
the "target" of an annotation *or* include annotation(s) within the
alternatives. I'll discuss this a little bit at the end, but this
should actually be discussed in a separate thread)
###
My question for today is: both the choice and the unary commands can
have a number of types, and I'm not sure if it's better to provide
individual commands for each of them or a structure where the type is
given as a key. To clarify I'll show the options, first for the choice
command:
\choice <choice-type> (<attributes>) {
<alternative-one>
<alternative-two>
...
}
<choice-type> would be a keyword out of the list of supported choice
types (so far
[source|abbreviation|correction|regularization|substitution] or
reasonable shorthands).
<attributes> is an optional \with {} block where information such as
responsibility for the decision or comments can be included.
<alternative...> is a list of music expressions that stand for the
alternatives. In the example above this would expect the two being of
certain types, but that is handled below with the unary commands.
1)
Is \choice an appropriate name (it's the name used in MEI)? An
alternative would be \variant
2)
From the perspective of the user entering the stuff it would be nicer
and cleaner to not use \choice <choice-type> but have dedicated commands
like \correction \regularization etc. Internally these would be wrappers
to a generic command. But I'd like to have some feedback about whether
this would be inappropriately "polluting" the namespace (since I'm not
doing this for a private project but for a general-purpose library).
###
For the unary commands it's the same question. They could be encoded like
\toBeFoundGenericName sic (<attributes>) { <original-erroneous-content> }
\toBeFoundGenericName unclear (<attributes>) { <dubious-text> }
etc.
or there could be dedicated commands
\sic { c' }
\corr { cis' }
Of course this would be nicer to enter but also clutter the namespace
with a dozen or more commands which may even be pretty prone to clashing
with either future LilyPond keywords or existing users' functions. If
going for the MEI namings that would be:
* \abbr
* \expan
* \cpMark (indications like percent repeats, textual indicators for
copied content etc.)
* \sic
* \corr
* \gap
* \unclear
* \reg (regularized text)
* \orig
* \add
* \del
* \restore
* \handShift
###
Summarizing I'll give a concrete example in both ways:
{
\choice correction \with {
author = UL
cert = high
comment = "This is obviously wrong, cf. flute 2"
} {
\edit sic { c' } % \edit is a first shot at a generic name
\edit corr { cis' }
}
}
{
\correction \with {
resp = UL
cert = high
comment = "This is obviously wrong, cf. flute 2"
} {
\sic { c' }
\corr { cis' }
}
}
There are cases where simpler encoding is sufficient too (just to give
some more context):
% Just *stating* a correction (can be highlighted visually)
\relative {
c' d e \corr { fis } | g1
}
% Concise encoding of a variant (the writer of the source has replaced a \p
with a \f),
% giving the option to choose which variant is rendered
\relative {
% would generally be configured in global place:
\setOption scholarly.variants.render.substitution add
c' d e \substitution { \del \p \add \f } | g1
}
###
Encoding such variants of course has implications for how annotations
are handled, and it will add functionality I have always missed. A
"traditional" annotation might look like this:
{
\criticalRemark \with {
author = UL
message = "Original edition erroneously prints c' \\natural"
} Accidental
cis'
}
With the encoding of variants this might be extended to:
{
\criticalRemark \with {
author = UL
message = "Original edition erroneously prints c' \\natural"
} Accidental
\correction { \sic c' \corr cis' }
}
This would be the easiest integration where \correction (or \choice)
simply evaluates to a single music expression that is then annotated.
However, it might make more sense to integrate the \choice part in the
annotation mechanism, to say e.g.
{
\criticalRemark \with {
author = UL
message = "c' \\natural in OE surely erroneous, cf. flute 2"
item = Accidental
choice = \with {
type = correction
sic = { c' }
corr = { cis' }
}
}
or the other way round (integrate the annotation feature in the choice,
create an annotation when 'annotation-type' is given):
{
\correction \with {
annotation-type = critical-remark
author = UL
item = Accidental
message = "c' \\natural in OE surely erroneous, cf. flute 2"
} {
\sic { c' }
\corr { cis' }
}
}
}
To be thought through (but definitely in its own thread) is the issue
that annotations currently insert a \once \override, but should actually
be able to affect a SequentialMusic expression as well. And of course
all these new twists should also still be compatible with elements that
have to be \tweak-ed.
I'd be happy about any constructive feedback.
Urs
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
