lilypond-user
[Top][All Lists]
Advanced

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

Re: Advice on naming and structuring scholarLY commands


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

Hi Elaine,

I was off my PC over the weekend, so I'll only now reply to your post.


Am 16.06.2018 um 03:21 schrieb Flaming Hakama by Elaine:

---------- Forwarded message ---------
From: Urs Liska <address@hidden>
Date: Fri, 15 Jun 2018 09:28:05 +0200
Subject: Re: Advice on naming and structuring scholarLY command

Hi Elaine,


Am 15.06.2018 um 02:21 schrieb Flaming Hakama by Elaine:

Actually I think  \edmark and \edMarkup (or something along these lines) might be the best compromise between the generality of the command, expressiveness and practicality.

Urs


My $0.02 is that you should spell out \editorialMark.

\edMark is not expressive enough.

We're not in an 8.3 epoch, there is no cost to a few extra letters to say what you really mean. 

OK, good point.
But (also in light of your other post on this thread) it "mark" really what it is?
I think I'd really be fine with \editorialXXX, but while we're at it we should really pick the right term, isn't it?

From my (limited) understanding of English a mark is not what we're encoding here. A mark would be a single item that describes or that points to something.
What we have *is* a descriptive element, but it is not that our command inserts an "item that describes something" but our command itself describes something that is actually included in it. We encode some music, e.g. { s2 } and describe it as being a "gap" with the attribute of its reason being damage by ink spill, for example. Or we can say that in { c8 [ d e f ] } the Beam "is" an editor's addition.

Would it be correct to say that we "mark up" some music? From Merriam-Webster's definition this is totally alien (https://www.merriam-webster.com/dictionary/markup), but isn't this exactly the meaning of "markup language"?

If that's correct I think that \editorialMarkup would be fine.

What do you think?

Urs


Thanks for your interest in my opinion on this topic.

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.



It seems that, in order to use \editorialMark, you need to identify a segment of music, which is then addressed with annotations and alternatives.

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.



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".




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.


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 ...




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.

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.


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




HTH,

Elaine Alt
415 . 341 .4954                                           "Confusion is highly underrated"
address@hidden
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



 


_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user


reply via email to

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