Menu ▾ ▴

#4645 Use a MelismaEvent for \melisma

Accepted
nobody
None
Enhancement
2015-10-27
2015-10-26
Simon Albrecht
No

Currently, \melisma and \melismaEnd are defined (in ly/declarations-init.ly) as:

:::Scheme
melisma = #(context-spec-music (make-property-set 'melismaBusy #t) 'Bottom)
melismaEnd = #(context-spec-music (make-property-unset 'melismaBusy) 'Bottom)

whereas slurs, ligatures and beams use events and the respective melismaBusyProperties are set ‘behind the scenes’. The difference is that \melisma[End] are thus executed at the next timestep, while the events belonging to other melisma-related objects happen at the timestep of the note to which they are attached.

The inconsistency alone would not matter, but it does provide an ‘unnecessary’ difficulty: one must remember to always have \melisma last, i.e. after all post-events. This is more difficult with e.g.

"(" = \melisma
")" = \melismaEnd

applied, which is an important feature in producing different editions (following different conventions of notating melismata) from the same source. For example, { c8([ d)] } is valid and common coding AFAICS, but with the above redefinition it doesn’t work (Error: unexpected post-event).

Discussion

  • Simon Albrecht

    Simon Albrecht - 2015-10-27
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -6,33 +6,11 @@
 melismaEnd = #(context-spec-music (make-property-unset 'melismaBusy) 'Bottom)
 ~~~~

-whereas slurs, ligatures and beams use events and the respective `melismaBusyProperties` are set ‘behind the scenes’. A crucial difference is that \melisma[End] are thus executed at the _next_ timestep, while the events belonging to other melisma-related objects happen at the timestep of the note to which they are attached.
+whereas slurs, ligatures and beams use events and the respective `melismaBusyProperties` are set ‘behind the scenes’. The difference is that \melisma[End] are thus executed at the _next_ timestep, while the events belonging to other melisma-related objects happen at the timestep of the note to which they are attached.

-There may not be many use cases where this makes a difference, but it has the following two downsides (apart from the inconsistency I see):
-
-1– One must remember to always have \melisma last, i.e. after all post-events. This is more difficult with e.g.
+The inconsistency alone would not matter, but it does provide an ‘unnecessary’ difficulty: one must remember to always have \melisma last, i.e. after all post-events. This is more difficult with e.g.

     "(" = \melisma
     ")" = \melismaEnd

 applied, which is an important feature in producing different editions (following different conventions of notating melismata) from the same source. For example, `{ c8([ d)] }` is valid and common coding AFAICS, but with the above redefinition it doesn’t work (Error: unexpected post-event).
-
-2– It is not possible to redefine \melisma so that it enables automatic beaming for the duration of the melisma. The following:
-
-~~~~
-:::Scheme
-melisma =
-#(context-spec-music (make-sequential-music
-                      (list (make-property-set 'melismaBusy #t)
-                        (make-property-set 'autoBeaming #t)))
-   'Bottom)
-melismaEnd =
-#(context-spec-music (make-sequential-music
-                      (list (make-property-unset 'melismaBusy)
-                        (make-property-set 'autoBeaming #f)))
-   'Bottom)
-~~~~
-
-amongst other malfunctions (which I don’t understand yet) doesn’t beam the first note of the melisma (and will continue autoBeaming until the first note after the melisma).
-
-This is certainly of low priority, but I think it’s not invalid.
     

  • Simon Albrecht

    Simon Albrecht - 2015-10-27

    I cancelled the second topic from this issue, because 1) I underestimated (of course, sorry) the complications which arise and 2) it’s another issue.

     

  • Simon Albrecht

    Simon Albrecht - 2015-10-27

    And I raised https://sourceforge.net/p/forge/site-support/11453/ on behalf of the mess in the diff above (first comment).