Re: Arpeggio misbehaviour?
Am Sa., 26. Okt. 2019 um 04:45 Uhr schrieb Federico Sarudiansky
:
>
> Hello,
>
> I'm typesetting a work which includes this single measure (here as a MWE) in
> a PianoStaff.
>
> \version "2.19.83"
>
> \score {
> \new PianoStaff {
>\set PianoStaff.connectArpeggios = ##t
><<
> \new Staff \with { \consists "Span_arpeggio_engraver" } \relative c'' {
> \clef treble \time 6/8 b4. 8 \arpeggio r r}
> \new Staff \with { \consists "Span_arpeggio_engraver" } {
><<
>\new Voice { \voiceOne \relative c' {aes4( g8) s4.}}
>\new Voice { \voiceTwo \relative c, { \clef bass \time 6/8 f4. cis'>8 \arpeggio \oneVoice r r }}
>>>
>}
>>>
> }
> }
>
> Without tweaking anything, the arpeggio symbol is mispositioned. Is this a
> bug? I'm missing something? What do you think is the best workaround for
> this? I tried overriding Arpeggio.padding and (somewhat more brute-force)
> NoteColumn.X-offset but I feel there is a better solution for this.
>
> Thanks in advance!
>
> F.
Hi,
it's a weakness, if you'd call it a bug I'd not object...
I think what happens is that the outer Voices have NoteColumns and
AccidentalColumns the inner Voice none of them.
Thus LilyPond seems to think the outer Note/AccidentalColumns can be
placed more left than we would want, disregarding the inner Voice.
(Without the arpeggio, this would be correct.)
As a workaround I'd enter an altered invisible Note in the inner Voice.
\score {
\new PianoStaff {
\set PianoStaff.connectArpeggios = ##t
<<
\new Staff
\relative c'' {
\clef treble \time 6/8 b4. 8 \arpeggio r r
}
\new Staff
{
<<
\new Voice {
\voiceTwo
\relative c, {
\clef bass \time 6/8 f4. 8 \arpeggio \oneVoice r r
}
}
\new Voice {
\voiceOne
\relative c' { aes4( g8) \once \hideNotes gis4.\arpeggio } %% <--
}
>>
}
>>
}
}
Please note I deleted consistings of the "Span_arpeggio_engraver", it
is in PianoStaff per default.
HTH,
Harm
Re: Tweaking glissando timing stems
Am Fr., 25. Okt. 2019 um 22:41 Uhr schrieb Leo Correia de Verdier
:
> I realized that defining the glissando gradient taking the stencil as point
> of departure, rather than the grob properties, makes it work for broken
> glissandi too. It was a quite minimal change.
>
> (gliss-gradient (/ (+ (- (car stil-y-ext) (cdr stil-y-ext)) (*
> half-line-thick 2))
> (+ (- (car stil-x-ext) (cdr stil-x-ext)) (*
> half-line-thick 2))
> (if (> Y-right Y-left) 1 -1)))
Yep, meanwhile I did similar, but relying on the actual
Glissando.thickness. `half-line-thick´ is derived from
staff-symbol-line-thickness, which may result in fishy calculations
for changed thicknesses.
Attached you'll find a heavily revised code, i.e. a lot clean-up, more
respect for user-settings, a plethora of inline comments.
Some TODOs inline, the more severe are displayed.
Atm, I don't know what could be done further with this approach (apart
from said TODOs).
Thus I'll wait for feature-requests and bug-reports ;)
I said "this approach", because technically speaking it's an override,
nothing more.
One could think of others:
(1) Code an engraver to keep track of all those affected items more
easily. NB currently other items like Fingerings, StringNumbers etc
are not included. And what about other spanners like Hairpins or
TextSpanners. Currently not even tested.
(2) Create a new Grob. We already have StemStub and StemTremolo. I
could imagine something like GlisandoStem. Ofcourse this would be the
most general approach. But also the probably most involved and
complicated one.
For now I have to stop thinking/coding, though.
And monday my autumn-break ends :((
Best,
Harm
\version "2.19.83"
%%
%% GLISSANDO WITH STEMS
%%
#(define (glissando-and-stems pad-y)
"Returns the unchanged @code{Glissando}, @code{Stem}s from passed
@code{NoteColumn}s are recreated to start at the glissando-line. @var{pad-y}
may provide a padding-value.
A @code{Flag} is moved to fit again with the new @code{Stem}.
@code{Script} at a passed @code{NoteColumn} is moved to sit at note-head-side.
Inner @code{Beam}s are recreated to be parallel to the glissando-line, unless
an override for @code{Beam.details.beamed-glissando-stem-positions}, expecting
a number-pair, is suppled. This is prefered.
"
;; Glissando has no pointer to the covered NoteColumns, because in most
;; traditional music NoteColumns are *not* skipped.
;; Thus reading those NoteColumns is inconvenient...
(lambda (grob)
(let ((gliss-stil (ly:grob-property grob 'stencil)))
(if (not (ly:stencil? gliss-stil))
;; Warn if no Glissando.stencil is present, do nothing else
(ly:warning "No stencil for ~a found, stopping here" grob)
(let* (
;;
;; some generals
;;
(sys (ly:grob-system grob))
(layout (ly:grob-layout grob))
(blot (ly:output-def-lookup layout 'blot-diameter))
(staff-space (ly:staff-symbol-staff-space grob))
(line-thickness (ly:staff-symbol-line-thickness grob))
(half-line-thick (/ line-thickness 2))
(grob-thickness (ly:grob-property grob 'thickness 1))
(gliss-thick (* line-thickness grob-thickness))
;; We use original not grob here to avoid not catching some
;; elements for broken glissando.
(original (ly:grob-original grob))
(left-bound (ly:spanner-bound original LEFT))
(right-bound (ly:spanner-bound original RIGHT))
(left-bound-when (grob::when left-bound))
(right-bound-when (grob::when right-bound))
;; Glissando-stencil extents
(gliss-stil-x-ext (ly:stencil-extent gliss-stil X))
(gliss-stil-y-ext (ly:stencil-extent gliss-stil Y))
;;
;; Glissando-slope
;;
;; The actual used glissando-gradient (calculated below) is
;; influenced by positive or negative slope.
;;
;; Simple slope could be retrieved by comparing Y-left/right.
;; We need X-left lateron, so we see no real need for
;; simplification here.
(left-bound-info (ly:grob-property grob 'left-bound-info))
(X-left (assoc-get 'X left-bound-info))
(Y-left (assoc-get 'Y left-bound-info))
(right-bound-info (ly:grob-property grob 'right-bound-info))
(X-right (assoc-get 'X
Re: Arpeggio misbehaviour?
Thomas Morley wrote: As a workaround I'd enter an altered invisible Note in the inner Voice. Another way is to apply \once \override Arpeggio.extra-spacing-height = #(cons -inf.0 +inf.0) just before the arpeggioed 8 That corresponds to Valentin's workaround in https://sourceforge.net/p/testlilyissues/issues/601/#a750 Cheers, Robin
Re: Arpeggio misbehaviour?
Thank you Thomas and Robin for the workarounds. I think the beauty of the non-arpeggio case well worth a misbehaviour here, if a short workaround is available and works like in this case. Thanks again. El sáb., 26 oct. 2019 a las 8:03, Robin Bannister () escribió: > Thomas Morley wrote: > > > As a workaround I'd enter an altered invisible Note in the inner Voice. > > > Another way is to apply > > \once \override Arpeggio.extra-spacing-height = #(cons -inf.0 +inf.0) > > just before the arpeggioed 8 > > > That corresponds to Valentin's workaround in > https://sourceforge.net/p/testlilyissues/issues/601/#a750 > > > Cheers, > Robin > > > >
Re: Crossstaff position tolerance
Am Fr., 25. Okt. 2019 um 12:27 Uhr schrieb Andrew Bernard : > > What is the position tolerance distance for cross staff stems to work? Zero? > Or is there some wriggle room? > > I ask because I have a complex (as always) bit of free form music with > different overlapping tuplet ratios in different voices that is just more or > less 'thrown on the page' by the composer for this small section of a dozen > bars, but there are cross staff stems tying staff objects together from time > to time. Perhaps If I could manually offset the stems by some amount I could > get various stems to line up. > > Andrew > Hi Andrew, in music-functions.scm you'll find (define (close-enough? x y) "Values are close enough to ignore the difference" (< (abs (- x y)) 0.0001)) as the distance-tolerance. To push stuff around to get connectable Stems you may use my `pushNC´ posted several times on this list. HTH, Harm
Re: Crossstaff position tolerance
Hi Harm, I think you may have written that for me originally! Now I found i again. Thank you. Andrew On Sun, 27 Oct 2019 at 03:31, Thomas Morley wrote: > > To push stuff around to get connectable Stems you may use my `pushNC´ > posted several times on this list. > >
