lilypond-user
[Top][All Lists]
Advanced

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

Re: Letters as Left hand fingering


From: David Kastrup
Subject: Re: Letters as Left hand fingering
Date: Wed, 16 May 2012 12:23:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Thomas Morley <address@hidden> writes:

> 2012/5/15 Pierre Perol-Schneider <address@hidden>:
>> Hi Group,
>>
>> Sometimes I need to put a letter in front of a number as a fingering.
>> Is there any possibility to declare "m" (for ex;) as a number so that I
>> could code <a-m1> as a fingering ?
>
> Hi Pierre,
>
> I'm not aware of any method to do it with that easy syntax: <a-m1>
>
> But you may want to try:
>
> \version "2.15.36"
>
> letter =
> #(define-music-function (parser location l fingering)(string? ly:music?)
> (let* ((music (make-music 'FingeringEvent))
>       (finger (ly:music-property fingering 'digit))
>       (n (number->string finger)))
> #{
>         \tweak #'text #(markup #:concat (;#:fontsize 6
>                                #:normal-text l n))-$music
> #}))
>
> \relative c' {
>         <a-\letter x -1
>          cis-\letter y -2
>          e-\letter z -3>
> }

Now _this_ one has potential to profit from parser improvements:

\version "2.15.36"

#(define (fingering-event? m) (and (ly:music? m)
                                   (music-is-of-type? m 'fingering-event)))

letter =
#(define-event-function (parser location l fingering)
    (string? fingering-event?)
  (let* ((finger (ly:music-property fingering 'digit))
         (n (number->string finger)))
   #{
     -\tweak #'text
     \markup \concat \fontsize #6 \normal-text { #l #n }
     #fingering
   #}))

\relative c' {
        <a\letter x-1
         cis\letter y-2
         e\letter z-3>
}

First we define our own predicate for recognizing and accepting _only_
fingering events (this works fine even though -1 does look like an
integer, and indeed our predicate is called with -1, too, to see whether
that would be an acceptable interpretation as well).

Because we are now guaranteed to have the right kind of event, we need
not create a new event.  Instead we just tweak the existing one.  The
function we define can be an event function, so one does not need to use
- before calling \letter.  The value for the #'text property can
_directly_ be specified using \markup, no need to use a Scheme
contraption.  The difference between #fingering and $fingering is
subtle: the latter will create a full copy of the event, the first not.
In this case, we don't need a copy.

#{ - ...

creates a post-event rather than a full music event.  So here is quite a
bit of potential for creating a smoother experience.  Now of course one
can streamline the user interface a bit by making individual commands
for individual letters:

\version "2.15.36"

#(define (fingering-event? m) (and (ly:music? m)
                                   (music-is-of-type? m 'fingering-event)))

letter =
#(define-event-function (parser location l fingering)
    (string? fingering-event?)
  (let* ((finger (ly:music-property fingering 'digit))
         (n (number->string finger)))
   #{
     -\tweak #'text
     \markup \concat \fontsize #6 \normal-text { #l #n }
     #fingering
   #}))

defineletter =
#(define-scheme-function (parser location l) (string?)
  (define-event-function (parser location fingering) (fingering-event?)
   #{ -\letter #l #fingering #}))

X = \defineletter x
Y = \defineletter y
Z = \defineletter z

\relative c' {
        <a\X-1
         cis\Y-2
         e\Z-3>
}

As I said: it is not like things have gotten significantly easier.  But
you get a _lot_ more of power and expressivity without programming
complexity spiraling out of control.

User-definable predicates allow ruling out a lot of strange error
conditions right in the parser.  #{ #} works for more things than it
did.  Function arguments can usually interchangeably be specified in
either LilyPond or Scheme syntax.  Argument ambiguities are resolved by
actually running predicates on several interpretations of the argument.

Now _this_ is actually a nice case for supporting future developments
financially.

-- 
David Kastrup




reply via email to

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