lilypond-user
[Top][All Lists]
Advanced

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

Re: Define new articulation with markup or path (instead of glyph)


From: Trevor Bača
Subject: Re: Define new articulation with markup or path (instead of glyph)
Date: Wed, 17 Oct 2018 20:13:17 -0500

Hi Urs,

I went through this a couple of months ago, and it *seems* possible to use markups (and paths) as legitimately new articulations (maybe -- and happily -- in contradiction to the assumption in your original post, if I'm reading correctly).

Here's the pattern as a MWE:

%%% BEGIN NOVEL ARTICULATION USING MARKUP %%%

baca-damp-markup =
    \markup
    \scale #'(0.75 . 0.75)
    \combine
    \bold
    \override #'(font-name . "Times") "O"
    \path #0.15
    #'(
        (moveto -.4 .7)
        (rlineto 2.4 0)
        (closepath)
        (moveto .8 -.5)
        (rlineto 0 2.4)
        )

#(append! default-script-alist
   (list
    `("bacadamp"
       . (
           (stencil . ,ly:text-interface::print)
           (text . ,baca-damp-markup)
           (avoid-slur . around)
           (padding . 0.20)
           (script-priority . 125)
           (side-relative-direction . ,DOWN)
           (skyline-horizontal-padding . 0.20)
           ;;(toward-stem-shift . 0.5)
           ))))

baca-damp = #(make-articulation "bacadamp")

\layout {
    \context {
        \Score
        scriptDefinitions = #default-script-alist
    }
}

%%% END %%%


You can then write ...

\new Staff { c'4 \baca-damp }

... and get ...

novel-articulation.png

... as output.

To note:

1. Apologies for not yet crediting the various posts in the archives that made this possible; it was a weekend or two of reading through various breadcrumbs on the list that made the pattern possible.

2. The baca- prefix is a namespacing convention since I'm always mixing with modules in Python. Replace as necessary if the snippet works for you.

3. Wrt to your three initial criteria, the example above demonstrates #1 ("no postfix operator"). Because the symbol created is a legit script, overrides like "\override Script.staff-padding = 5" do work. So maybe this helps meet your #2 ("common vertical baseline"). I'm not certain about your #3 ("pushes notecolumns to obtain the necessary space"). But some testing seems to show that *if you explicitly specify the font of markup* then Lily can find a stencil (and move note columns).

%%% BEGIN WIDE EXAMPLE %%%

estr-markup =
    \markup
    \override #'(font-name . "Times")
    "ESTREMAMENTE"

#(append! default-script-alist
   (list
    `("articestr"
       . (
           (stencil . ,ly:text-interface::print)
           (text . ,estr-markup)
           (avoid-slur . around)
           (padding . 0.20)
           (script-priority . 125)
           (side-relative-direction . ,DOWN)
           (skyline-horizontal-padding . 0.20)
           ;;(toward-stem-shift . 0.5)
           ))))

estr = #(make-articulation "articestr")

\layout {
    \context {
        \Score
        scriptDefinitions = #default-script-alist
    }
}

%%% END %%%


Then ...

\new Staff {

    c'4
    d'4
    \estr
    e'4
    f'4

}

... gives ...

wide-articulation.png

... as output.

Note that if you use "bald" markup (without a font override) Lily finds no stencil and produces no output for the articulation.

Trevor.
 


On Sat, Oct 13, 2018 at 3:07 AM Urs Liska <address@hidden> wrote:
Hi Aaron,

althought this has long left the original thread's purpose I find this
extremely interesting. Would you be interested in adding some content to
https://scheme-book.ursliska.de, maybe somewhere below
https://scheme-book.ursliska.de/scheme/lists/? There is always need for
explanations that go to substantially more length than the concise Guile
manual.

Best
Urs


Am 13.10.2018 um 10:03 schrieb Aaron Hill:
> On 2018-10-13 12:29 am, Aaron Hill wrote:
>> According to the docs [1], assoc-set! (and family) may modify the
>> original alist.  So whether a copy is made or not depends on an
>> implementation detail.  Near as I can tell, the original alist is
>> modified in-place when the key is found within.  But when the key is
>> new, the result of using acons to append the new key/value to the head
>> of the list results in a copy being returned.
>>
>> [1]:
>> https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Adding-or-Setting-Alist-Entries.html#Adding-or-Setting-Alist-Entries
>>
>
> Nope, I'm wrong about copying.  acons (and therefore assoc-set!) does
> not copy (shallow or deep).  Consider the following:
>
> guile> (define a '((one . 1) (two . 2)))
> guile> (define b (assoc-set! a 'three 3))
> guile> a
> ((one . 1) (two . 2))
> guile> b
> ((three . 3) (one . 1) (two . 2))
> guile> (define c (assoc-set! a 'three 3))
> guile> c
> ((three . 3) (one . 1) (two . 2))
> guile> (eq? b c)
> #f
> guile> (equal? b c)
> #t
> guile> (eq? a (cdr b))
> #t
> guile> (eq? (cdr b) (cdr c))
> #t
> guile> (set! a (assoc-set! a 'two 2.2))
> guile> a
> ((one . 1) (two . 2.2))
> guile> b
> ((three . 3) (one . 1) (two . 2.2))
> guile> c
> ((three . 3) (one . 1) (two . 2.2))
>
> While "b" and "c" are unique as far as the initial node in their
> respective lists (because acons returns a new list), they share the
> remainder with the same nodes within the original list.  So,
> modification to the list that "a" references will propagate to "b" and
> "c".
>
> Upon reflection, this all makes sense.  So, one should probably be
> explicit about copying and use list-copy (shallow) or copy-tree
> (deep), as needed.
>
> -- Aaron Hill
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user


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