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 ...
[image: 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 ...
[image: 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 <li...@openlilylib.org> 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
> > lilypond-user@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> _______________________________________________
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
