|
| From: | Martín Rincón Botero |
| Subject: | Re: Align above "current" staff |
| Date: | Sun, 27 Sep 2020 16:50:45 +0200 |
Dear Aaron,this is, as usual, excellent. Thank you very much! I was reading Elaine Gould's book regarding ossias and two things would improve this snippet: Naming the ossia staff "ossia" (adding instrumentName = "ossia" to \context { \Staff ...} doesn't work) and joining both systems with dashed bar lines except for the first barline of the system (putting \new StaffGroup \with { \override SpanBar.glyph-name = #"!" \remove System_start_delimiter_engraver } before << \new OssiaStaff... >> doesn't work either). What am I missing?Best regards,Martín.Am So., 27. Sept. 2020 um 13:26 Uhr schrieb Aaron Hill <lilypond@hillvisions.com>:On 2020-09-27 3:23 am, Martín Rincón Botero wrote:
> I hope this message lands in the right 2018 thread. I find an ossia
> function very worth the work! I tried several things yesterday but
> none of them really worked. I amended a few details to Urs/David's
> code (a couple of \with attributes) but there are still some minor
> issues (other than this big 13 years old bug
> https://gitlab.com/lilypond/lilypond/-/issues/127).
>
> When I look at the code (see below) I would expect this to happen:
> \ossia {%ossiamusic} {%music}. What happens is the opposite. This is
> trivial, since the only thing you have to tell the user is that the
> normal music goes before the ossia music, but it makes me wonder why
> anyways... Other minor issues are that the ossia music doesn't inherit
> the clef from the normal music, and that placing all this inside a
> \relative is not reliable (the first note of whichever of both
> components might be in an unexpected octave). Does Urs, who started
> working on this, or David (or anyone :-)) have any idea on how to
> solve these minor issues? Here the amended code with an example that
> demonstrate them:
>
> [ . . . ]
Firstly let me be clear that I have not chased down all information
relating to this thread, so I very well might be missing important
details.
I can see no reason why the order of arguments could not be swapped so
that the ossia-music comes first. This is very useful as it clarifies
why \relative works the way it does. The ossia-music _expression_ gets
processed before the remaining music. The first "c" in the remaining
music follows the final "e" in the ossia-music, not the "g" is the
preceding music.
Regarding clefs, I have a patched version of \ossia that attempts to
match the current clef settings by mimicking how \clef works:
%%%%
\version "2.20.0"
\layout {
\context {
\Staff
\name OssiaStaff
\alias Staff
\remove "Time_signature_engraver"
\magnifyStaff #2/3
\hide Clef
firstClef = ##f
}
\inherit-acceptability OssiaStaff Staff
}
ossia =
#(define-music-function
(ossia-music music)
(ly:music? ly:music?)
(let ((staff-name #f)
(clef-props '(clefGlyph
middleCClefPosition
clefPosition
clefTransposition
clefTranspositionStyle)))
(define (initialize context)
(set! staff-name
(ly:context-id (ly:context-find context 'Staff)))
(set! clef-props
(map (lambda (prop)
(cons prop (ly:context-property context prop)))
clef-props)))
(define (update context)
(ly:context-set-property! context
'alignAboveContext staff-name)
(for-each (lambda (prop)
(ly:context-set-property! context
(car prop) (cdr prop)))
clef-props)
(ly:set-middle-C! context))
#{ \applyContext #initialize
<< \new OssiaStaff
\with #(ly:make-context-mod `((apply ,update)))
{ #ossia-music }
#music >> #}))
\new Staff = "viola" \relative {
\clef alto
c'4 d e g
\ossia { e^"Treble clef? No, it's alto now." d f e }
{ c^"c'? Yes, because \\relative says so." b c d }
c b c2
}
%%%%
Note that I went ahead and defined an OssiaStaff context so that
properties relating to it are not buried within the \ossia function.
Also a little refactoring should make the function's logic a little
easier to follow.
-- Aaron Hill
--
| [Prev in Thread] | Current Thread | [Next in Thread] |