lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Advice on naming and structuring scholarLY commands


From: Urs Liska
Subject: Advice on naming and structuring scholarLY commands
Date: Mon, 11 Jun 2018 11:14:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]