Sorry, I wasn't paying attention. shortInstrumentName = "ossia" clearly works (instrumentName should work as well!).
Am So., 27. Sept. 2020 um 16:46 Uhr schrieb Martín Rincón Botero < [email protected]>: > 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 < > [email protected]>: > >> 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 > > > > -- > www.martinrinconbotero.com > -- www.martinrinconbotero.com
