lilypond-user
[Top][All Lists]
Advanced

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

Re: Sorting out annotation interface questions (GSoC)


From: Jeffery Shivers
Subject: Re: Sorting out annotation interface questions (GSoC)
Date: Wed, 6 Jul 2016 18:19:51 -0400

I suggest the distinction between annotation type (critical remark, etc.), edition type (addition, emendation, etc.), and observation type (addition, emendation, etc.). This is a fairly loose naming scheme, but I'll clarify that it's all oriented to the usual annotations interface (so not referring to new hooks independent of annotations yet, though I agree those should/could be available as well at some point).

In context, and including the use of "category" as well:

    \criticalRemark% annotation type
        \with {
            message = "This slur was later added by the composer."
            observation = addition% observation of an addition; not our application of it.
            category = phrasing
    }

    \musicalIssue% annotation type
        \with {
            message = "I added the slur."
            edition = addition% applies our edition
            category = phrasing
    }

Category and observation could both be used for filtering/sorting annotations, so there's that additional benefit of having those distinctions. Again, everything that goes into those lists can be set by the user. Same for "edition", as well as for how the items are uniquely affected (user decides the `foo` edition type will make slurs dashed, noteheads parenthesized, etc.), if at all:

Perhaps `apply-edition` should rather be the property for automated editions, and simply `edition` will *not* automate anything, but will still indicate what the author has done and will be available and sortable as a sort of static property, similar to category and observation. In the critical reports, both `apply-edition` and `edition` could at that point appear as `edition` (if chosen to be printed in the report at all, of course).

Further down the road, we could also implement edition priorities (separately from annotation priority, which is another upcoming feature for general sorting/filtering annotations by priority), where certain individual specified editions can *always* be applied/forced regardless of mode/options. So this also brings up the idea that the printing/exporting of annotations can be themselves sorted/filtered, while the application of their editions (if any) are *independently* filtered/sorted, if desired. This sort of does the same thing as I suggested with edition/apply-edition, but from a different angle. Since the aim is to be as flexible as possible, it may be wise to start with both angles as a possibility from the get-go.

On Mon, Jun 27, 2016 at 7:57 AM, Urs Liska <address@hidden> wrote:
Hi Simon,

thanks for the feedback.


Am 27. Juni 2016 13:21:25 MESZ, schrieb Simon Albrecht <address@hidden>:
>On 27.06.2016 00:55, Urs Liska wrote:
>> \musicalIssue \with {
>>    author = "Urs Liska"
>>    context = "violin 1"
>>    message = "Slur obviously forgotten in original edition"
>>    apply = addition
>> } Slur
>>
>> My question is: is this "application" the same as the type of
>annotation
>> action from the previous issue? Or could it occur that a project
>wants
>> to document types of editorial decisions independently from applying
>> visual indications of that?
>
>A few unsystematic thoughts:
>Well, there are limits to visual indication of critical matters. At
>least in some projects it will be impossible for the score to contain
>(or even hint to) every bit of information present in the Critical
>Report.
>I really think we should allow for great diversity in the possible
>approaches, i.e. editorial policies.

We certainly don't intend to impose editorial policies but to provide the tols to tailor project specific behaviour.

By default annotations dob't have any impact on the layout (which is crucial) but just colorize objects while in draft mode.

Additionally we'll provide generic commands that can be used to visually indicate certain types of editorial action.

For example something like \editorialAddition can be used to indicate something that is missing in the source and has been added by the editor. By default this might make slurs dashed and parenthesize other types of elements. Of course the visual appearance will be configurable so only the semantic command is inserted in the music.

Now annotations *can* trigger the application of such editorial commands (which can also be used independently from annitations).
My question is: are the *type* of decision and the triggering oc commands inherently independent so we should implement both a property forvthe annotation type *and* the applied command or could they be "merged"?

> In some cases it might be good to
>have a simple switch (modernise lyrics or not);
>in other cases everything must be decided on a case-by-case basis, with
>
>no automation being possible;
>and the type of annotations one will have, as well as how to display
>them in both the score and the critical apparatus, will be very
>different depending on the project.

Of course, as commented on above.

>Perhaps that at one time our footnotes engine will be sophisticated
>enough to be used for such purposes, and include the apparatus in the
>actual musical text. It would be good to have hooks for such an
>approach.

Triggering footnotes from annotations is on the GSoC task list. As is the possibility to insert scores in annotations  (to be printed in a footnote for example, or in the LaTeX critical report).

Best
Urs

>
>I’m sorry I don’t have the time to take a deeper dive into this, but I
>really appreciate your efforts!
>
>Best, Simon

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

_______________________________________________
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]