> I understand your concern with using "Mark" as the basis of the name,
> since while this \editorialMark will often (or always?) include a mark that
> appears on the page, it also contains musical alternatives, so it is not
> merely a type of Mark.
>
>
> Not *alternatives*, basically an individual segment of music.
>
I guess I didn't fully understand the variations aspect of this.
What are the circumstances when you would want to have a variation?
I assumed they would be treated as alternatives (each edition might include
the original, or a variation). But maybe, variations are included in
addition to the original, like in footnotes, or and appendix?
>
> So, here is a basic question that I think has import to this discussion:
> Can the musical segments addressed by \editorialMark be nested and/or
> overlapping?
>
>
> Technically (as music-functions) they can be nested but not overlapping.
> Conceptually it should be possible to have overlapping findings, but I
> don't plan to try supporting this. I think users would have to work around
> with adjacent segments.
>
I guess that this concern of mine was motivated by the (mis-)conception
that the variations were alternatives. Which is to say, if the musical
segments were not disjoint, then the resolution of alternatives would get
tricky, as different \editorialMark segments might have conflicting
alternatives.
>
> If yes, they can be nested and/or overlapping, then each \editorialMark
> could map to a single annotation/comment/remark. In which case, the
> concept of \editorialMark as describing the specific mark makes sense, and
> the musical segment is simply the entity on which the \editorialMark
> operates.
>
> If this is the case, possibly better names might be \editorialRemark or
> \annotation.
>
>
> We already have these, in the existing scholarLY annotations
> \criticalRemark, \musicalIssue etc. These "point" to a specific element
> (through a \tweak or \once \override) and "attach" an annotation to this.
> In the sense of "I want to say something about this score element", not
> "this 'is' something".
>
I guess the distinction I was teasing out was whether the \editorialMark
referred to one editorial concept, versus a container for several. Sounds
like it is for a single concept.
As such, it doesn't seem like there is a point in making a distinction
between whether the "score element" is actually applies to a single
note--an accidental, dynamic or articulation--versus when the "score
element" spans a bunch of notes--like a slur or dynamic spanners, or
ottava, etc.
>
> However, if the musical segments addressed by \editorialMark-s must be
> distinct from one another, then we might have several marks/topics/comments
> in a single musical segment. In that case, maybe the command should be
> named after the identification of this musical segment?
>
>
> Basically this is what I would like to achieve. I want to encode the
> information that
>
> - this beam "is" an addition by the editor
> - these four notes "are" illegible
> - this measure "is" a gap because of damage
>
> This would call for a bunch of commands like \editorialAddition,
> \illegible, \gap etc.
>
> However, this would "pollute" the namespace with numerous names, many of
> whom being pretty generic (gap, add, del, corr etc.), which is why I am
> looking for a generic "wrapper" command that is specified by its first
> argument.
>
>
That sounds like the right concept--a function that requires a first
argument describing the type of entity.
>
> Based on some of the earlier posts, it seems like one of the outcomes of
> this command is to attach unique IDs to the start and end of this musical
> segment. If this is true, then maybe the command should be named with
> regard to the fact that its main job is to identify and tag this musical
> segment, to which the editorial remarks and the alternatives will apply.
>
> If that is the case, maybe the command should be named something like
> \identifyEditorialSegment or \editorialTag.
>
>
> Maybe (probably) I'll drop the idea of tagging both the beginning and end
> of the segment, but I think this description is going into the right
> direction ...
>
In any case, my concern about this is not relevant since these segments are
not alternatives.
And semantically, the \editorialMark is more about the remark than the
specifics of what it attaches to.
>
> I don't really like these initial suggestions for this second conception
> of the command, but I'd like to get clarity on what the essential
> requirements are for any such usage. (Do you need to have alternatives?
> Do you need to have editorial marks?)
>
>
> There need not be alternatives. The command in question encodes *one*
> finding, which may include a single musical element or a (sequential) music
> expression. If the editor wants to encode alternatives (for example the
> original vs. the corrected text) there is (going to be) an additional
> command that wraps them and decides which one to use for the current
> engraving.
>
Hmmm, maybe the issue of conflicting variations does creep in here, if
there are segments of nested \editorialMarks.
For example, If you had one \editorialMark for a slur added in one edition,
and then another \editorialMark for an accidental omitted in another
edition among the notes under the slur, could you produce an edition with
both the slur and the accidental? Seems like in order to do that, you
would need to ensure that the \editorialMark for the inner segment would
have to be applied after the outer one.
Also, it does seem to me like these are alternatives. Not in the sense of
volta alternatives, where multiple "endings" are printed, but in the sense
that only one of the variations will be printed.
>
> There need not be editorial marks. The *basic* task of the command is to
> encode a certain segment of music "as" something, for example:
>
> { c' d' \corr { e' d' } | c'1 }
>
> which would encode the information that this half measure has been
> corrected from faulty text in the source.
> An editorial mark *can* be generated by this command, which would then
> attach an annotation to the first element of the music expression (the e').
>
> My understanding is that the command "marks up" or "tags" the music
> expression. It doesn't add a mark to the music, and it doesn't "describe"
> it, rather it "names" it. Another option would be to say it "labels" it.
>
> The problem seems to be that while all these four are valid they conflict
> with existing uses of the words.
>
> My personal favourite would be \editorialMarkup because in my
> understanding this is exactly the use of the term in "markup language".
>
> The above example would roughly map to HTML like this:
>
> Some words <span class="corr">have been corrected</span> from obvious
> errors.
>
> where "span" would be the entity we're searching a correspondence for.
>
> { c' d' \editorialMarkup corr { e' d' } | c'1 }
>
> -- which finally brings me to the idea of using "span" - since that is so
> semantically open:
>
> { c' d' \span corr { e' d' } | c'1 }
>
> This would open the thing up from the more narrow perspective of scholarly
> editing to the more general idea of semantic encoding of music. There could
> then be a provision for users to add their own "classes" in the future.
>
I'd agree that this syntax makes the most sense:
{ c' d' \editorialMarkup corr { e' d' } | c'1 }
Although I would still argue for complete words, rather than abbreviations,
for the first argument.
Like the \consists discussion, I think that getting clearer on the actual
workings of the command may help inform an appropriate name.
Indeed, and I do want to get this one right before going further. While the
\consists case is clearly more important we have an important advantage
*here*: we build upon an empty space and don't discuss changing syntax that
has been around for decades.
Best
Urs
Elaine Alt
415 . 341 .4954 "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
