pedal decorations

[andrewbernard]

New function for adding arbitrary cautionary text to pedal brackets and optionally continuation arrows on the right hand side.

[uliska]

Thank you for the contribution. Indeed I think this can be a very useful tool for many (mostly contemporary) piano scores.

There's one thing I would actually wish (but that doesn't prevent merging the PR). The styling of the LHS should not be hardcoded. That is, the actual use of a box (and it's padding) and the text font should not be hardcoded. I can't say out of my hat how I'd like to have it configurable, but in some way it should be configurable.

[andrewbernard]

Hi Urs,

Thought you may say that!

I figured that with the code available people could modify the text formatting for their own purposes, me having provided the ‘hard part’ of the work. But of course that’s not very flexible. Possibly we could pass a markup as the first argument. The people can put whatever they require. I will have a go at that.

If you look at the example the way I deal with different text is just to provide wrappers around the function call. This also gets around the annoying issue that you cannot have an optional argument (use arrows or not?) as the last argument. [I know I could put the optional arrows first, but that just does not feel right to me!]

Andrew

From: Urs Liska [mailto:notifications@github.com] Sent: Sunday, 20 November 2016 9:56 AM To: openlilylib/snippets snippets@noreply.github.com Cc: Andrew Bernard andrew.bernard@gmail.com; Author author@noreply.github.com Subject: Re: [openlilylib/snippets] pedal decorations (#156)

Thank you for the contribution. Indeed I think this can be a very useful tool for many (mostly contemporary) piano scores.

There's one thing I would actually wish (but that doesn't prevent merging the PR). The styling of the LHS should not be hardcoded. That is, the actual use of a box (and it's padding) and the text font should not be hardcoded. I can't say out of my hat how I'd like to have it configurable, but in some way it should be configurable.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/openlilylib/snippets/pull/156#issuecomment-261745338 , or mute the thread https://github.com/notifications/unsubscribe-auth/AD0u-8Op8Iot1sxYIrdXs7CCPk6JLN0Yks5q_35vgaJpZM4K3O6S . https://github.com/notifications/beacon/AD0u--C0YQKkzyXQnfjhjTn71eGPji8uks5q_35vgaJpZM4K3O6S.gif

[uliska]

The point is that with the includable nature of OLL it's not actually viable to manually change the code. Of course users can do that but it's very much against the design.

If it's possible to discern markup from a plain string that would be an approach: when given a string create the markup as per the current implementation, otherwise jusz use the argument.

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

[andrewbernard]

On 20 November 2016 at 21:27, Urs Liska notifications@github.com wrote:

The point is that with the includable nature of OLL it's not actually viable to manually change the code. Of course users can do that but it's very much against the design.

​Agreed. ​

If it's possible to discern markup from a plain string that would be an approach: when given a string create the markup as per the current implementation, otherwise jusz use the argument.

​ I think that can be done.

​Andrew

[uliska]

I just did a short test. Consider

\version "2.19.51"

#(define (string-or-markup? obj)
   (cond
    ((markup? obj) #t)
    ((string? obj) #t)
    (else #f)))

test =
#(define-void-function (arg) (string-or-markup?)
   (if (string? arg)
       (display "string\n")
       (display "markup\n")))

\test  "sdf"
\test \markup "sdf"
\test \markup \bold "sdf"
``

Based on this it is possible to decide how to build the pedal mark