Re: Proposal: Changing tremolo beam gap implementation

[Torsten Hämmerle]

Thomas Morley-2 wrote
> https://sourceforge.net/p/testlilyissues/issues/704/#64b9
> has an image of the relevant Gould-page.
> 
> ölkjh
> 
> 
> […]
> 
> Though, I'll not start the work if Torsten will present a proper fix
> within the next two weeks.
> 
> […]
> 
> Torsten, what do you think?

Hi Harm,

I'll go for a "proper" implementation within the following days.

A switch between "as if the semibreves were stemmed" and freely floating
centred beams will also be provided.
Probably even between minims (half notes), as in the first example shown in
the scan (Elaine Gould, Behind Bars):

 

I like your idea of having a separate user-settable gap for floating beams.
I'm using the term "floating tremolo beams" because, as we have seen, even
stemmed notes can have freely floating beams.
They should, imho, properly align with the stave lines (todo).


*Current status*

This is what your example looks like at the moment with all the fixes
switched off:
 
Apart from the negotiable vertical position of the beams, it is pretty much
mimicking what you've done using your custom stencil.

Cheers,
Torsten

Harm-ex-trem-impl1.png
  




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Proposal: Changing tremolo beam gap implementation

[Torsten Hämmerle]

Thomas Morley-2 wrote
> see my code at
> https://lists.gnu.org/archive/html/lilypond-user/2020-04/msg00160.html
> 
> It's ofcourse a workaround, but usable, afaict.


Hi Harm,

It's good to have a workaround for the time being.
The reason why I haven't finished the "strange gap behaviour" issue 5868 yet
is because it is very much linked to the old issue 318 dealing with sloped
and centred whole-note tremolos, more or less just as you've implemented it
in your custom stencil fix.


By the way, as to your question (in the comments of your coding):


   ;; Beam
   ;; TODO where does this magic number, 0.81, comes from?

This magic number is nothing but the *standard beam translation* (i.e. the
vertical shift from beam to beam) and is a combination of standard beam
thickness (0.48) and standard line thickness (0.1), taking into account the
sit/straddle/hang beam placement rules.

For up to 3 beams, the standard beam translation basically is
0.5 * (2 + line-thickness - beam-thickness) = 0.5 * (2 + 0.1 - 0.48) =
*0.81*

Using this translation between beams will allow the upper beam to hang from
a stave line, the middle beam to straddle, and the lower beam to sit on a
stave line.


Further issues

I'm also trying to be prepared (code-wise) for the following (new) features,
partly already in the testing phase:

* slope damping (your slope is not damped, and I think even freely floating
beams in whole-note tremolos should not become too steep, they're no
glissandi.

* implement a proper sit/straddle/hang placement of freely floating beams. 
That seems to be more important than "exact" vertical centering between the
left and right notes/chords.

* keep away from ledger lines (just a little bit)

* (still to be done in my version) note-column shift as you did it,
especially needed if there are accidentals and dots.

* Alternative "Beam as if they were stemmed" approach as suggested by Elaine
Gould.

* Possibility of three or more note tremolos (never seen one in real life,
but, obviously, they do exist according to Gould)


Cheers,
Torsten





--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Instructing fretboard-diagram-verbose to space frets proportionally rather than equadistantly

[Torsten Hämmerle]

I like the idea and have of having naturally spaced frets in fret diagrams.

As Aaron has already pointed out, the current implementation always uses

  fret-distance * fret

for positioning objects and calculating the length of the strings.
fret-distance is the distance between frets and fret is the fret number.

I've now replaced all these cases by a function

  (fret-position fret)

that will calculate the actual (non-linear) position depending on the fret
number (fret is an argument passed over to the function).

The calculations are based on the assumption that each bar represents a
half-tone step.
Using exponential functions, the "fret number" can even take any
intermediate value so that all placements of objects (dots, barrés, capos,
etc.) in between fretbars will smoothly adapt to the nonlinear scale. 

There's a new Boolean detail *property* called *proportional-frets* that can
be set if you want proportionally spaced frets.  The default setting is
"false" and the new fret-position function will behave just as linear as it
has always done.

Here's a short example of what the result looks like.


 

I think I'll open up an issue and upload this patch.
It should be available soon in LilyPond 2.21.1, I guess.

Cheerio,
Torsten

Fret-diagram-proportional.png

  




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Your Bespoke Lilypond Environment

[Torsten Hämmerle]

cgilmore wrote
> What's your DX?

My DX is a 1985 Yamaha DX7, but I hardly use it anymore.

As far as LilyPond is concerned, I'm mostly using Frescobaldi as a DX
(Direct Exchange, i.e. replacement?) for jEdit and emacs.
I'm not a military guy at all (neither physically nor mentally), but I spent
most of my life in close vicinity of the U.S. Army Europe Headquarters.  I
think I've never heard "DX" in the meaning of "replacement" from
non-military people, so I guess it's military slang (is it?).
Or did you, by any chance, mean something completely different, at all?

And the moral of the story is …
… sometimes, an abbreviation can be the beginning of a long journey ...

Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: German bar lines documentation

[Torsten Hämmerle]

Noeck wrote
> [...] verwendet werden, dass sich genauso wie […]


Hi Joram,

No problems as to the bar lines, but it definitely has to be "*das*", not
"*dass*".

I'd also prefer "sich /genau so/ wie […] verhält" over "sich /genauso/ wie
[…] verhält" in this case.

Cheers,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Proposal: Changing tremolo beam gap implementation

[Torsten Hämmerle]

Noeck wrote
> You always show notes with the same pitch. It might
> make sense to look at slanted beams, too. But as there is no problem
> currently, I would not expect one due to the gap change.

Musically, two-note tremolos with twice the same note don't make any sense
at all, but for demonstrating the gap size behaviour, I nevertheless chose
these configurations.
And it was only by chance that I became aware of the unexpected gap size
implementation when experimenting with whole-note tremolos.


Noeck wrote
> Btw, how do you produce such a tremolo?
> I know these (depending on the notehead), but how to attach one beam and
> not the others?

These configurations with one beam attached came quite handy for the gap
comparisons (and you 
noticed the incorrect full beam in my example image, so it is good for
testing, too).

In your example, the black noteheads could be mistaken as quavers without
floating beams, but minims usually use full beams for tremolos.

But you can set the number of floating beams (i.e. gapped beams) using the
gap-count property:

%%
{
  \repeat tremolo 8 { e''32 f'' }
  \override Beam.gap-count = #1
  \repeat tremolo 8 { e''32 f'' }
  \override Beam.gap-count = #2
  \repeat tremolo 8 { e''32 f'' }
  \override Beam.gap-count = #3
  \repeat tremolo 8 { e''32 f'' }
}
%%

 

Cheers,
Torsten

tremolo-gap-count.png
  




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Proposal: Changing tremolo beam gap implementation

[Torsten Hämmerle]

Noeck wrote
> I would also expect the "gap" to be the free space between stem and beam.

Hi Joram,

Thank you, then we seem to have a common understanding of "gap", even if the
current tremolo beam gap implementation behaves differently.



Noeck wrote
> In your attached image, I wonder if you have drawn the upper beam from
> the inner edge of the stem only for demonstration reasons, what a gap=0
> would be. The stems and beams have slightly rounded corners, haven't
> they? So if the beam touches the stem, it should overlap to avoid little
> notches where they touch.
> In other words, while currently gap=0 is a valid choice, with your
> proposed gap definition, gap should either be >0 or -stem-thickness but
> not 0, right?

Yes, you are right about the rounded corners, and even if a zero gap does
not make much sense, it should be handled in a reasonable way.
My example image was purely focusing on the size of the gap and wasn't fully
functional yet.

*Intended implementation*
The full-size stems will, as usual, run through from the very left to the
very right.
In the special case of gap = 0, the beams will also run completely through
the stems.
Only for non-zero gaps, the gap will start at the inside of stems so that
the effective free space will be as wide as the gap property suggests.

I've attached an example image showing gap = 0 and gap = 0.13 (i.e. the stem
width):

 

As you can see, a gap of 0 will not suffer from rounded beam corners, but a
gap > 0 will actually have the expected width.
In other words, if gap > 0, the shortened tremolo beam start will be shifted
by stem-width + gap compared to a standard stem. 

Cheers and thanks for the hint,
Torsten

tremolo-zero-gap.png
  




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Minimal horizontal space for melismata

[Torsten Hämmerle]

Peter Crighton wrote
> Side question: Is there a shorter/nicer way to hide/omit all those things
> in the RhythmicStaff?

Hi Peter,

For rhythmic alignment without noteheads, beams, accidentals, etc. consuming
space, the relatively new
*  NullVoice*
has been invented.

This, however, still doesn't quite solve your problem yet as other elements
still take up horizontal space.

I've come to a solution that works with your example, but, I'll have to
admit that if it had been "i -- met" instead of "a -- met", a tiny gap after
the slim letter "i" still couldn't have been avoided that way.


In addition to using NullVoice, I've set proportionalNotationDuration on
Staff level to a high value to achieve narrow spacing.

And I've set ChordName.X-extent to zero.  There's the danger of overlapping
chord names, though.



\version "2.20.0"

Chords = \chordmode {
  f16*7 a16*3:m
}
Lyric = \lyricmode {
  Lo -- rem ip -- sum do -- lor sit a -- met.
}
Melody = {
  c16 c c c c c c c( a) a
}
<<
  \new ChordNames \chordmode {
\Chords
  }
  \new Lyrics
  \new RhythmicStaff {
\new NullVoice = "melody" {
  \Melody
}
  }
  \context Lyrics {
\lyricsto "melody" {
  \Lyric
}
  }
>>
\layout {
  \context {
\Score
proportionalNotationDuration = #(ly:make-moment 100)
  }
  \context {
\ChordNames
\override ChordName.X-extent = #'(0 . 0)
  }
  \context {
\Lyrics
\override LyricText.self-alignment-X = #LEFT
  }
  \context {
\RhythmicStaff
\override StaffSymbol.line-count = 0
\omit TimeSignature
\omit BarLine
  }
}


And that's how it looks like:
 


It's not perfect, but in rare cases with narrow one-character syllables, you
still might enter specific alternatives using \tag.

HTH,
Torsten

lorem-ipsum-narrow.png
  




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Proposal: Changing tremolo beam gap implementation

[Torsten Hämmerle]

Thomas Morley-2 wrote
> [...] attempting to make whole-note-tremolo-beams avoid possible Dots to
> the
> left and possible Accidentals to the right.


Yes, that would certainly be the next step.  Avoiding dots and accidentals.

Cheers,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Proposal: Changing tremolo beam gap implementation

[Torsten Hämmerle]

Hello all,

Looking more deeply into Harm's strange whole-note tremolo beam gap
behaviour, I've stumbled over the current gap implementation:

It's probably rather academic, but my understanding of "gap size" is the
actual gap size (white space) between two objects.

Looking at the current implementation and playing around with stem
thickness, however, it becomes obvious that the gap is, other than expected,
not the free space between stem and beam:  It it is measured from the outer
side of the stems and not from the inner side of the stems.

The following illustration will compare the current behaviour to what I
would expect, varying the beam thicknesses from 0 via standard up to
exaggerated values in order to make the effect clearly visible:

 

*What do you think?*
Wouldn't it be better to have "gap" actually mean "free space"?
Before opening an issue and uploading a patch, I'd rather ask for opinions.

Thanks in advance,
Torsten

tremolo-gap-comp.png
  




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: An exciting new release… of Sibelius!!!

[Torsten Hämmerle]

Very nice.

But I'm a bit disappointed that, obviously, there's still no solution for
the long-standing issue "tuplets across bar lines", which has never been a
problem for LilyPond, but Sibelius/Finale still can't handle this without
trickery and tweaking.

No need for glee, but, from time to time, it can be quite interesting to
compare LilyPond to "professional" (i.e. commercial) software.

Cheers,
Torsten





--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Strange gap-behaviour with whole-note tremolo Beams

[Torsten Hämmerle]

Thomas Morley-2 wrote
> I have no clue why this happens and where those added values came from.
> 
> Any insights?


Hi Harm,


Believe it or not, this strange (and certainly unintended) effect is caused
by the thickness of the invisible stems!

The beam shortening will actually depend on the beam thickness, as the beams
will start at the left side of the left beam and end at the right side of
the right beam.
For further investigation, I've added a layout block to your example:


%%
\layout {
  \context {
\Voice
\override Stem.thickness = #100   % standard: 1.3
  }
}
%%

Obviously, the beam shortening deviations will start even earlier when using
stem thickness 0 and they will start later as the stem thickness increases.
When setting the stem thickness to approximately 50 or above, the stem
shortening deviations will vanish in all of your test cases (I hope the
table will be correctly displayed in raw format):



So I guess this unintended dependency on invisible beam thicknesses comes
from within the C++ code will have to be corrected there.

I'll open up a tracker issue and see what I can do about it.

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: version 2.18.2 - incorrect bar numbers with full measure rests

[Torsten Hämmerle]

Eby Mani wrote
> My understanding of "full measure rests" is, it covers the full measure
> based on the time signature. Thus R1 is sufficient for a measure that is
> in 4/2 time.


Hi Ebi,

What you are saying is true (in most cases) for the graphical representation
in the output, but, as Michael pointed out, in LilyPond, the full measure
rests need to coded using their actual duration.

For example, a full measure rest in 3/4 has to be coded as R2., but it will
be printed as a semibreve full measure rest rather than a dotted minim rest. 
A full measure rest in 2/4 has to be coded as R2, but it will be printed as
a semibreve full measure rest rather than a minim rest..

Just as an F sharp in the key of G major will be printed as an F (without
accidental, due to the general key signature), but it has nevertheless to be
coded as fis (or fs or whatever, depending on the input language).


When it comes to breve rests (as in your 4/2 example), the printed full
measure rest symbol, however, will usually be a breve rest according to
common standards (cf. Gould, "Behind Bars", and others).

All in all, LilyPond's output behaves according to common engraving
standards, but a full measure rest has to be coded using its actual
duration.
In general, one can say: LilyPond's input is focused on musical content, not
on its graphical representation.

The Documentation (Notation Reference) clearly states: /"The duration of
full-measure rests is identical to the duration notation used for notes."/ 

A similar case are multi-measure rests. In 4/4, 8 full-measure rests will
always be coded as R1*8, because that's the musical content, independent of
the intended graphical representation:
Whether the printed output shows a classical double-long rest symbol or a
just a contemporary "general rest bar" merely depends on the engraving
options - if you, for instance, use
  \override MultiMeasureRest.expand-limit = #5, 
everything above 5 measures will be printed as a simple bar rather than
classical rest symbols.

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: version 2.18.2 - incorrect bar numbers with full measure rests

[Torsten Hämmerle]

Hi eby,

I don't get your point - all I can see is:
two full-measure rests, and after these two measures, the third measure,
consequently, is bar number 3.
Why should it be 5?

I you had provided your sample code, it'd probably be easier to understand
what you had in mind.
Is it about the breve rests?
Did your use R\breve or R1*2?  Still, a measure is a measure...

Cheers,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Unexpected "Merge_rests_engraver" behavior

[Torsten Hämmerle]

Павел Буданов-2 wrote
> See the vertical position of multimeasure rest.
> 
> ```lilypond
> \version "2.19.83"
> [...]

Hi Pavel,

Yes, that's a bug, but it has been fixed in 2.19.84 and current stable
2.20.0 is OK, too.

Regards,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: In TabVoice - how to avoid: "programming error: side-axis not set for grob StrokeFinger"

[Torsten Hämmerle]

Werner LEMBERG wrote
> Interesting.  Is it documented somewhere that the order of `\consists`
> calls is relevant (sometimes)?

Hi Werner,

I couldn't find anything about that in the documentation.

When experimenting with Voice and TabVoice, I noticed that Voice worked
without a problem and, most notably, the fingering routines were called
before the script routines.


In *ly/engraver-init.ly*, the Voice context definition contains a comment:

[…]
  \consists "Auto_beam_engraver"
  \consists "Grace_auto_beam_engraver"

  %% must come before Script_column_engraver.
  \consists "New_fingering_engraver"

  \consists "Chord_tremolo_engraver"
  \consists "Double_percent_repeat_engraver"
[…]


TabVoice, finally, is based on Voice but with New_fingerning_engraver
removed (but Script_column_engraver still being there).
When appending it again by using "\consists…", the order is messed up.



Werner LEMBERG wrote
> Or maybe there is a bug somewhere?  I think not having to think about
> the order would be quite beneficial.

I totally agree there, but the New_fingering_engraver has been designed that
way and it's complicated enough.  It'd be great of course if someone had a
good idea how to get rid of these dependencies.

Regards,
Torsten 






--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: In TabVoice - how to avoid: "programming error: side-axis not set for grob StrokeFinger"

[Torsten Hämmerle]

Thomas Morley-2 wrote
> Any hints why this error is generated and how to avoid?


Hi Harm,

Unfortunately, applying \consists "New_fingering_engraver" does not quite do
the trick yet, because there's a problem of sequence: it needs to come
*before* Script_column_engraver, that's why just appending it at the end
will not work.

In order to avoid this problem of sequence, I've first removed
Script_column_engraver and appended it again /after/ New_fingering_engraver.
Looks funny but actually solves the problem.

Alternatively, you could just completely \remove the Script_column_engraver
if you don't need it.

%
\version "2.20.0"

\layout {
  \context {
\TabVoice
\remove "Script_column_engraver"
\consists "New_fingering_engraver"  % *before* Script_column_engraver!
\consists "Script_column_engraver"
  }
}

\new TabVoice 
  { b-\rightHandFinger 1 -"foo" } 
%

That way, all the side-axis properties needed will have been set.

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Lilypond in Windows shows version 0.4

[Torsten Hämmerle]

Mark Mathias-2 wrote
> The 2.20.0 version is listed in Frescobaldi's preferences with a correct
> full path, but there is a red "no go" symbol to the left of the line.
> [...]
> Here's the path I've specified: C:\Program Files (x86)\LilyPond
> 2.20.0\usr\bin\lilypond
> 
> I must still have something wrong...

Hi Mark,

Yes, you're right: you must have something wrong… ;)

Obviously, there's an error in the specified lilypond binary, I've just
checked it by playing around with one of my paths.  Frescobaldi will display
a no entry sign on the left if the path/file specification is invalid.
In your case, it looks as if the "*.exe*" suffix was missing.
If you want to avoid typing errors, you can use the "open file dialog" icon
on the right of the LilyPond Command field and click your way through to
lilypond*.exe*.

As soon as the specified LilyPond Command (i.e. the lilypond.exe binary with
a fully specified path) is OK, the no entry icon will immediately be
replaced by a lovely little water lily icon and I'm sure your Frescobaldi
will then be able to launch the corresponding LilyPond version without any
further ado.

HTH and good luck,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Lilypond in Windows shows version 0.4

[Torsten Hämmerle]

Hi Mark,

Frescobaldi is able to handle several LilyPond versions at the same time.

*Edit --> Preferences
LilyPond Preferences
*

The path I'm using for 2.20, for instance, is:
C:\Program Files (x86)\LilyPond\2.20.0\usr\bin\lilypond.exe
plus "Include in automatic version selection" checked.
(in Windows 10)

There you can the full path to the various lilypond executable files and
there's a tickbox "automatically choose LilyPond version from the source
file" so that Frescobaldi will pick the most suitable version depending on
your \version statement.
And you can set one LilyPond version as a default.

It's a good idea to incorporate the LilyPond version somewhere into the
path.
That way, Frescobaldi is quite good at handling different LilyPond versions
in parallel.

Are your LilyPond Preference settings resp. "LilyPond versions to use"
entries OK?

HTH,
Torsten

PS: 0.4 is either prehistoric or some 2015ish LibreOffice OOo-lilypond 0.4
version.



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: generating simple leadsheet with chords and empty staff

[Torsten Hämmerle]

Rob Torop wrote
>- Is there a way to avoid needing to put the repeating 12 bars of
> silent
>rests in the melody - clearly it's not a good way to do it
>- Can this be done more concisely?


Hi Rob,


First of all, there's no need for
   \repeat unfold 12 { s1 }
It's much simpler to write s1*12

Apart from that, and I suppose that's what you wanted, you can get by just
having to declare \chordmusic and use this definition both in ChordNames and
in Staff:

\chordmode cannot only be used for printing ChordNames, because "inside",
it's ordinary music, that also can be put into an ordinary Staff.
*And here's the trick*: If you use NullVoice, \chordmusic is just used for
rhythmic alignment and will not print any music.


%%
\version "2.18.2"

chordmusic = \chordmode {
\repeat percent 4 { f1:7 }\break
\repeat percent 2 { bes1:7} \repeat percent 2 { f1:7} \break
\repeat percent 2 { c1:7}   \repeat percent 2 { f1:7} 
}

\score {
  << 
\new ChordNames { \chordmusic }
\new Staff \new NullVoice { \chordmusic }
  >>

  \layout {
indent = #0
\context {
\ChordNames
\consists "Percent_repeat_engraver"
\override PercentRepeat.extra-offset = #'(0 . 1)
 
}   
  }
}
%%


HTH,
Torsten


PS: \relative around \chordmode does not make much sense here




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: default stem directions

[Torsten Hämmerle]

Rick Kimpel-2 wrote
> I am trying to learn how to change the default stem directions.
> […]
> ...without having to do all the \stemUp \stemDown stuff.
> I'm ok with the manual beaming.

Hi Rick,

You could set up a custom function.
A simplistic example (see below) will read the 'default direction.
As you have already noticed, the default stem direction will be #UP for note
heads below the middle stave line and #DOWN otherwise.

Obviously, you'd like to have it the other way round. The custom function
will give back #DOWN if the default direction is #UP, and #DOWN otherwise).

%%
\version "2.19.83" 

#(define (custom-stemdir)
   (lambda (grob)
 (let ((defdir (ly:grob-property grob 'default-direction)))
   (if (= defdir UP) DOWN UP

\score { 
  \new Staff 
  \with { \override StaffSymbol.line-count =  #1 } 
  { 
\clef percussion 
\numericTimeSignature 
\autoBeamOff 
\relative c' {
  <>^"default"
  b8 c4 c8 b8[ b] b c |
  <>^"custom"
  \override Stem.direction = #(custom-stemdir)
  b8 c4 c8 b8[ b] b c |
} 
  } 
} 
%%

 

HTH,
Torsten
custom-stemdir.png
  



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Unicode code points

[Torsten Hämmerle]

Freeman Gilmore wrote
> That is interesting, it is in the Private Use Area of Unicode, same area
> as
> Bravura.

Yup. In Emmentaler, there is one big exception I forgot to mention (but this
has nothing to do with accidentals):

The dynamic characters (f, m, p, etc.) are part of Emmentaler's text
encoding and can be found in their "proper" places (just as ordinary text)
so that you can use them directly by typing something like
  \markup { \dynamic sms }

The other glyphs are considered non-standard and therefore, all of them have
been stowed away into the Private Use Area, just one after the other. Mostly
encoding vector after encoding vector, sorted in alphabetical order (by
glyph name) or, more precisely, just as they are generated in
metafont/metapost:
  rests, accidentals, dots, arrowheads, scripts, trills, clefs, etc., etc.

Every time a new glyph joins the party, they all get shifted around from
release to release.
The accidentals in 2.20 will have moved compared to 2.18.2, because new rest
symbols (256th, 512th, 1024th rests!) have been shoved in in front of the
accidentals.  This way, the sharp glyph will have moved from U+E110 to
U+E113.  And that's just one out of many examples.

Cheers,
Torsten














--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: Unicode code points

[Torsten Hämmerle]

As far as I know, some special implementations are using SMuFL fonts, most
notably Dorico's Bravura.  These implementations will definitely use
explicit code points.

But LilyPond's makam.ly is making use of Emmentaler (Feta) glyphs, and, as
David pointed out, may change their code points each time a new glyphs is
inserted somewhere.

As Emmentaler is constantly growing, you'll probably find the accidentals in
a different place depending on the LilyPond release you're using.
For that reason, directly specifying code points is quite a bad idea and
that's why you'll have to use glyph names (like
accidentals.sharp.slashslashslash.stem).

If you still need to know the specific Emmentaler code points regardless of
this, you can have a look into the Emmentaler-20.otf font file (using
*FontForge*, for instance).  All the accidental glyphs available can be
found in LilyPond's Notation Reference Manual, Appendix "A.8 The Emmentaler
font", section  "Accidental glyphs"

 
.

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: box-stencil (was: Drawing boxes around grobs)

[Torsten Hämmerle]

Hello Paolo,

Yes, indeed, this is the crux with italic fonts… It's hard (to say the
least) to automatically determine whether or not the additional space
inserted after "mf" is needed. Even in hot-metal typesetting the typesetter
has to decide when to insert such an "italic correction".

The only feasible way out I can think of at the moment is creating new
special padded dynamics rather than overwriting the original definitions and
then deliberately choosing one or the other depending on the context, e.g.
\mfbox as a padded version tailored for boxing and standard \mf in
combination with follow-up hairpins.
Or finding a compromise plus applying some box-padding so that one and the
same re-defined \mf will work reasonably well in all circumstances.

Cheers,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: box-stencil (was: Drawing boxes around grobs)

[Torsten Hämmerle]

Paolo Prete-3 wrote
> I just checked that this unwanted behavior happens in the
> default make-stencil-boxer function too.

Ciao Paolo,

Unfortunately, this is a common problem with (mostly) italic fonts:
When looking at the dynamic f in FontForge, you'll see that the glyph is
sticking out of its left and right boundaries.

 

This exaclty matches the physical design of traditional lead type:

 


A *pragmatic solution* to your problem would be to re-define the dynamics
definitions concerned, simply adding a wee bit of space to the left and to
the right, as in

  mf = #(make-dynamic-script (markup #:line (#:hspace 0.2 "mf" #:hspace
0.5)))

This will make your output look like


 

HTH,
Torsten

italic-box-overshoot.png
  
italic-box-overshoot-dynamics.png

  



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: bar number on choir staff group and piano staff group

[Torsten Hämmerle]

Hello Ming,

It is sufficient to include the Bar_number_engraver into the \with statement
of the upper Staff of the PianoStaff, as in



bar-number-staffgroup.png
  

ChoirStaff does not need special treatment in this case:  it is the
uppermost stave so that the standard bar number on Score level will be OK.

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

Re: caesura or other ornamentation ?.

[Torsten Hämmerle]

Following Aaron's formidable example, I've done some minor modifications.
Just a matter of taste, of course…:

- straight lines (flags.ugrace) to more resemble the original symbols and
make them more distinguishable from a caesura.

- "downgraded" the syntax to make it all work with the current stable
version 2.18.2, too (# in front of the musicglyph names and \combine instead
of the new \overlay command.

- turn instead of trill as a basis, simply because it will stay closer to
the notehead without having to tweak outside-staff-priority. If there's a
concurring text script like "the shake turned", this text will be placed
between the notehead and a trill, but a turn will stay with its notehead.


%
\version "2.18.2"

forefall-markup = \markup \rotate #'-15 \musicglyph #"flags.ugrace"
forefall = #(let ((m (make-articulation "turn")))
  (set! (ly:music-property m 'tweaks)
(acons 'stencil (lambda (grob)
(grob-interpret-markup grob forefall-markup))
  (ly:music-property m 'tweaks)))
  m)
backfall-markup = \markup \rotate #'-65 \musicglyph #"flags.ugrace"
backfall = #(let ((m (make-articulation "turn")))
  (set! (ly:music-property m 'tweaks)
(acons 'stencil (lambda (grob)
(grob-interpret-markup grob backfall-markup))
  (ly:music-property m 'tweaks)))
  m)

shakeTurned-markup = \markup \combine 
  \lower #'0.75 \rotate #'205 \scale #'(1 . 1.25) \musicglyph
#"ties.lyric.default"
  \combine
  \rotate #'-15 \musicglyph #"flags.ugrace"
  \lower #'0.5 \rotate #'-15 \musicglyph #"flags.ugrace"

shakeTurned = #(let ((m (make-articulation "turn")))
  (set! (ly:music-property m 'tweaks)
(acons 'stencil (lambda (grob)
(grob-interpret-markup grob shakeTurned-markup ))
  (ly:music-property m 'tweaks)))
  m)

\relative {
  \omit Staff.Clef
  \omit Staff.TimeSignature
  \override Staff.TextScript.staff-padding = #4
  \cadenzaOn
  <>^"Forefall"
  s4 g'\forefall s8 \bar "|" s8 f16[ g8.] s4 \bar "||"
  <>^"Backfall"
  s4 g\backfall s8 \bar "|" s8 a16[ g8.] s4 \bar "||"
  <>^"Turn"
  s4 g\turn s8 \bar "|" s8 g16[ a32 g f16 g] s8 \bar "||"
  <>^"the shake turned"
  s4 g\shakeTurned s8 \bar "|" s8 a16[ g a g] fis[ g8.] s8\bar "||"
}
%

OfTheGraces.png
  

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Metronome marks above piano staff of vocal score?

[Torsten Hämmerle]

Steven Smith wrote
> Is there a a way to have the metronome mark created by "\tempo 4=80" 
> appear next to the piano staff as well as above the top staff of a 
> SATB/Piano score? 

Hi Steven,


The metronome marks are being created by the Metronome_mark_engraver. This
engraver, by default, "lives" in the Score context, i.e. the metronome marks
will be displayed just once above the score, not within the stave lines.

The easiest solution to your problem probably is to just include this
engraver in the upper piano stave so that metronome marks will be displayed
there, too:


%
\version "2.18.2"

 <<
   \new ChoirStaff <<
 \new Staff { \tempo 4 = 80 R1 }
 \new Staff { \tempo 4 = 80 R1 }
   >>
   \new PianoStaff <<
 \new Staff \with { \consists "Metronome_mark_engraver" } { \tempo 4 =
80 R1 }
 \new Staff { \tempo 4 = 80 R1 }
   >>
 >>
%

MetronomeMark_SATB_Piano.png
 
 

By the way, rehearsal marks (created by the Rehearsal_mark_engraver) are a
similar case.

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: caesura or other ornamentation ?.

[Torsten Hämmerle]

As "Insert Image" doesn't seem to have worked, here's a PNG file (hopefully)
prelleur_treatise_ornaments_1731.png

  

Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: caesura or other ornamentation ?.

[Torsten Hämmerle]

Hi Eby et al.,

In Peter Prelleur's 1731 treatise "The Modern Musick-Master", there are some
hints about keyboard ornamentation in the section "Of the Graces:". And, lo
and behold, that seems to clarify the issue, indeed:

 

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Harp glissandi

[Torsten Hämmerle]

Sorry,

I should have mentioned that the coordinates of the rotational centre are
relative to the Glissando extents.

x coordinate 0 means its centre, -1 means its left end and 1 means its right
end:



\version "2.19.82"
{
  \override Glissando.rotation = #'(30 0 0)
  <>^"centre"
  c''4 \glissando s s c''
  \override Glissando.rotation = #'(30 -1 0)
  <>^"left"
  c''4 \glissando s s c''
  \override Glissando.rotation = #'(30 1 0)
  <>^"right"
  c''4 \glissando s s c''
}



 

By rotating around the left end, the vertical starting point will be
retained.
Rotating around the right end, the vertical ending point will be retained.
No matter how long the particular glissando actually is.

HTH,
Torsten





--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Harp glissandi

[Torsten Hämmerle]

Rachel Knight wrote
> The glissando now look right except that it starts below the note instead
> of touching it. How would I fix the vertical aspect after rotating it? The
> angle is right in the first screenshot, but the placement is only correct
> in the original (screenshot 2).


Hi Rachel,

The rotation property takes three arguments:
1. the angle
2. rotation centre (x coordinate)
3. rotation centre (y coordinate)

Most of the placement issues can be resolved by varying the centre of
rotation (i.e. the 2nd and 3rd argument).

If his fails, you still can freely shift around the squiggly line by
  \override Glissando.extra-offset = #'(0 . 1)
In this example, the squiggly line will be moved up by 1 staff-space.

HTH,
Torsten





--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Comparison of Musescore, Sibelius and Dorico -- would like to add Lilypond

[Torsten Hämmerle]

Shane Brandes wrote
> What do they mean by jazz articulations?

Hi Shane,

I guess they mean doits, falls, shakes, bends…

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Section labels

[Torsten Hämmerle]

Hi Sean,

A "section label" is called RehearsalMark in LilyPond.
These rehearsal marks are (by default) the capital letters A, B, C, …, but
they can be changed into consecutive numbers (1, 2, 3,...) or bar numbers.
With a box, a circle, or nothing around.

Cf.  Rehearsal marks

  

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Bug? \clef makes Staff disappear

[Torsten Hämmerle]

David Kastrup wrote
> If you want a Staff, create it rather than rely on somebody else doing
> that, maybe.

That is basically what I thought (and wrote), too.
But, admittedly, these shortcuts used to work in prior releases and even can
be found in the Notation Reference Manual:

http://lilypond.org/doc/v2.19/Documentation/notation/displaying-chords
(scroll to "Simple lead sheet").

Fortunately (or should I say /incidentally/), this example still works
because of the additional \addlyrics line.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Bug? \clef makes Staff disappear

[Torsten Hämmerle]

Hi Malte,

You'll have to introduce a \new Staff.
Otherwise, the \relative clause (pun, pun…) will just be parallel music in
ChordNames mode and in ChordNames, there are no clefs.

It really starts getting funny if you change the c' into a d' (the c' just
didn't show up somewhere because it did not change the C major chord):

%%
<<
  \chords { c }
  \relative { \clef bass d' }
>> 
%%


Initiating a \new Staff makes LilyPond aware of the fact that there actually
/is/ a new Staff:

%%
<<
  \chords { c }
  \new Staff \relative { \clef bass d' }
>> 
%%

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Score and parts with global variable

[Torsten Hämmerle]

Andrew Bernard wrote
> I am unable to understand why the \global information does not print four
> times. How does this work? The template by the way does not give example
> code for the \global variable.

Hi Andrew,

Whether the \global information is printed four times or not solely depends
on the actual contents of the \global variable. Being used to
single-instrument music, you might not be fully aware of the difference
between \Score and \Staff level (if you only have one \Staff, you won't
notice a difference).

TimeSignature, MetronomeMark, RehearsalMark, etc., are defined on \Score
level and that's the reason why they are not being printed four times: they
just go on top of the score.
Nevertheless they should be included in all the staves because they are
needed in the individual parts and it is easy to find errors (if these
events do not happen simultaneously, you will be able to immediately
recognize it in the score).

If, however, the \global variable contains TextScripts, just to name an
example, these TextScripts will actually be printed four times, because
TextScript is defined on \Staff level.


BTW: I usually specify instrumentName/shortInstrumentName in the \score
block. They often need some markup tweaking, the appropriate indent value of
the score plays a role, I don't have to hassle with too many \tags and,
finally, they are not needed at all in the parts.
In the parts, the instrument will go into the instrument header property
instead.
But, as always, there are many ways to go...

HTH,
Torsten





--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Temporary pedal bar

[Torsten Hämmerle]

Gert Koetsier wrote
> How can I add a temporary pedal bar

Hi Gert,

I suppose you're talking about a temporary stave.
The following snippet should solve your problem:
Adding an extra staff

  

You can create additional staves anywhere by just adding a \new Staff in a
(temporary) parallel context (i.e. in << >>).

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Omitting specific symbols from key signatures

[Torsten Hämmerle]

Just for the files:

Forget all about music functions and a-posteriori manipulations of scales,
there is an disturbingly simple solution:

(link to my corresponding dev-list posting:)
How to set up a key signature definition

  

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: chord duration

[Torsten Hämmerle]

Gianmaria Lari wrote
> Ciao Torsten,
> 
> I'm sorry, I don't understand. Why I would like to display twice a chord
> if
> I write c4~4 ? Maybe could you write a simple example (if possible!).

Ah, yes, right, Gianmaria!

I only was thinking of chord changes in general, but now I see that it's
primarily about the tie.
And, I agree, there is no reason why one would want to display a tied-over
chord name.
Except, perhaps after line breaks (cf. accidentals). 

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Omitting specific symbols from key signatures

[Torsten Hämmerle]

Adam Good-3 wrote
> Are you on the dev list? If you'd be willing to help me out some more I
> can
> send you a couple of files that are under development and we can address
> specifically the two makams that have this issue.


Yes, I'm on the dev list.
And I'll appreciate a co-operation regarding makam issues.
After all, you and Hans can provide valuable practical examples, and one
important point after finally having added my new accidental glyphs, all the
non-standard accidental combinations in key signatures music currently
suffer from several spacing problems, because currently, for obvious
reasons, the focus had been solely on standard western accidentals.

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: chord duration

[Torsten Hämmerle]

Gianmaria Lari wrote
> But I was wondering why it should not work my
> obvious solution :)

Ciao Gianmanria,

Probably because your obvious solution isn't that obvious from a technical
point of view.
In this simple example, it is totally clear that we only want to see
changes.
But just imagine the beginning of a new section (rehearsal mark, repeat
volta bracket, Coda, etc.) where we definitely *want* to clearly re-instate
the Chord name for several reasons.

I think it is necessary to deliberately set chordChanges to ##t or ##f in
many cases.

Besides, I'll opt for ##t as the default setting.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Omitting specific symbols from key signatures

[Torsten Hämmerle]

Adam Good-3 wrote
> Thank you Torsten, unfortunately this doesn't satisfy the criteria of #3
> request, working across transpositions. If I ask for:
> \key c \KeySig
> 
> ...it prints a ces in the key signature. […]

Hi Adam,

Yes, unfortunately, my trickery only works for keys with a "sharp" tonic. In
other cases, e.g. starting with a C, the artificially lowered first step in
the scale will get a flat in the key signature, which is not what you asked
for…


The consequence of all this simply is that we need a *flexible* key
signature dynamically reacting on the current tonic:
If the tonic does not take any accidental (as in your C example), do
nothing.
If, however, the tonic has an accidental (no matter if it's a sharp, a flat,
a semi-sharp or whatever) just leave it away.

So, we can't get away with just specifying a fixed, well defined key
signature, but we have to look for the current tonic and, if there's an
accidental in the key sig, remove it.

Unfortunately, the grob does not know the tonic and we have to read it from
the context.
To make it even worse, everything may change if we apply transposition.

So, based on the naturalize-pitch snipped, I've defined a \makamKey function
that reads all the music and eventually kicks out tonic accidentals from the
key signature (i.e. pitch-alist).
That way, a fis or bes tonic will never be displayed in the key signature
but will be printed each time as an individual accidental.
But a c tonic, for instance, will have no influence on the key signature
(i.e. no superfluous unwanted accidentals).

%%%
\version "2.18.2"

#(define (makam-alist tonic alist)
   (let ((tonic-step (ly:pitch-notename tonic))
 (tonic-alt (ly:pitch-alteration tonic)))
 (if (eqv? tonic-alt 0)
 alist
 (filter (lambda (s) (not (eqv? tonic-step (car s
 alist

#(define (makam-key music)
   (let ((es (ly:music-property music 'elements))
 (e (ly:music-property music 'element))
 (tonic (ly:music-property music 'tonic))
 (pitch-alist (ly:music-property music 'pitch-alist)))
 (if (pair? es)
 (ly:music-set-property!
  music 'elements
  (map makam-key es)))
 (if (ly:music? e)
 (ly:music-set-property!
  music 'element
  (makam-key e)))
 (if (pair? pitch-alist)
 (ly:music-set-property!
  music 'pitch-alist (makam-alist tonic pitch-alist)))
 music))

makamKey =
#(define-music-function (parser location m)
   (ly:music?)
   (makam-key m))

testmusic = \makamKey \relative c' {
  \key fis \locrian fis4 g a b c d e fis
}

{ \testmusic }
\transpose fis c \testmusic
\transpose fis dis \testmusic
\transpose fis bes, \testmusic


 

HTH,
Torsten

a



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Omitting specific symbols from key signatures

[Torsten Hämmerle]

Hi Adam,

the KeySig you've defined is nothing but \locrian.

If you don't want the F# to be shown (that's the tonic in F# locrian), you
just need to define a ,FLAT for step 0 (the tonic), because this will lower
the tonic and thus eliminate the F# from your key signature.
That way, the F# will not be printed in the key signature, but it will show
up each time as an accidental in the music:

%
\version "2.18.2"
KeySig = #`((0 . ,FLAT)(1 . ,FLAT)(2 . ,FLAT)(3 . 0)(4 . ,FLAT)(5 . ,FLAT)(6
. ,FLAT))

\relative c' {
  \key fis \KeySig
  fis4 g a b c d e fis
}
%


An alternative solution without defining a custom key signature would be
abusing the \lydian mode and setting the tonic a half step lower: ;)

%
\relative c' {
  \key f \lydian
  fis4 g a b c d e fis
}
%

(This works because our custom key signature now has flats everywhere except
on step 3 and this is basically a shifted lydian mode which has just a sharp
on step 3).
Yes, that's confusing, but, after all, you can add a comment. That's the
good thing about text-based formats.

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Usage of ly:stencil-fonts ??

[Torsten Hämmerle]

Hi Harm,

All these numbers are quite confusing at first glance. And at second and
third glance, too.
But they are nothing but conversion factors to switch units.
And, unfortunately, LilyPond basically uses three concurrent units in
parallel:

- LilyPond units in staff-spaces
- Pango units in mm
- Typographic units in pt


This said, I'll try to derive all the values you have found using the
example of a standard 20-pt-staff with the corresponding standard text font
size of 11pt.
I will use a ridiculous number of decimal places to make it easier to
compare the results to your scheme output. 

As LilyPond is a European program, there are no inches to be seen and we'll
only use mm (millimetres).
Both mm and pt are always absolute units (as printed on the final sheet),
whereas a staff-space (let's call it 1sp) is always relative (depending on
the current staff-size).



pt value: conversion between pt and sp

The 'pt values are the conversion factor from pt to staff-spaces:
A 5-line 20-pt staff is 4sp high ==> 20pt = 4sp, in other words: 

1pt = 0.2sp (resp: 'pt = 0.2)

See? Multiply any value in pt by 'pt and you'll get staff-spaces.

With a 10-pt staff, we get 'pt = 0.4 so that you have to multiply any
pt-value by 0.4 to get the corresponding value in staff-spaces. The factor
has to be twice as big because a 10pt staff is half the size of a 20pt
staff.

 
ancestor-pt value: conversion between pt and mm

In markup (i.e. font environment), Pango fonts (metrics and size in mm!)
come into play.

This factor does not change when varying global-staff-size or anything,
because both pt and mm are absolute units and the conversion factor always
stays the same. Knowing how many mm or pt are in an inch, it's easy to
derive the factor:
1in = 25.4mm
1in = 72.27pt

1pt = 0.3514598035145980351459803514598 mm
This is your ancestor-pt value. :)

Our standard 11pt-font therefore will be 3.8660578386605783... mm in size
*Caveat:* the Pango font size from stencil-expr is not quite that, because
there is some rounding applied to avoid buffering too many fonts with with
microscopic size differences.


text-font-size: Just the actual font size in pt

The text-font-size displayed for a 20pt staff is 11pt (as suspected).
When setting global-staff-size to 10pt, text-font-size will consequently
only be half as big: 5.5pt.


font and size form stencil-expr

This is, as usual, the font size in (absolute) mm, but slightly quantized to
avoid the buffering of too many differently-sized fonts with only
microscopic font size differences.

3.865234375 is about what we'd expect for a standard 11pt font, applying
\fontsize #2 will change this by a factor of 2^(2/6) = 1.2599210498 so that
we get a
4.870927651... as reported (slight quanting/rounding effects).


output-scale: converting staff-spaces into mm

Finally, the output-scale factor is needed to transform LilyPond metrics (or
\translate #'(a . b) operations) from staff spaces to Pango mm.


In a 20pt standard stave, four staff-spaces will make up the 20pt, i.e. 1sp
= 5pt.
Using the pt-to-mm conversion factor (we want mm for Pango!), one
staff-space is
1sp = 5pt = 1.7572990175... mm (that's your output-scale).

If we change the staff-size to 16pt, we get
1pt = 4pt = 1,4058392... as output-scale.


That's about all, I think…

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Usage of ly:stencil-fonts ??

[Torsten Hämmerle]

Thomas Morley-2 wrote
> I like to understand the numerical values.
> The pair (-0.443862992125984 . 1.09258582677165) seems to be the
> extent in Y-axis.
> 
> But what about 3.865234375 and 1.1950157480315?

Hi Harm,

*The 3.865234375 is the font size (in millimetres!)*
Converting this into pt (1 inch = 72.27 pt = 25.4 mm), you'll end up with
the standard 11pt fontsize.
These font sizes are always (!) absolute and never depend on
global-staff-size etc.

*The 1.1950157480315 is the running width of the character*

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Usage of ly:stencil-fonts ??

[Torsten Hämmerle]

Hi Harm,

As it looks like, this function has not been working for some time, I've
tested it back to 2.14.2

What does it do?

In lily/stencil-interpret.cc, the function find_expression_fonts gets a
scheme variable called expr with the following contents:


*(A) in your NoteHead example:*

(named-glyph #
noteheads.s0)

-> Font_metric contains "Emmentaler-20"


*(B) I've changed the TextScript example to \markup \italic "italic"*

Now, the expressiong gets a bit convoluted, but there's still a
 information contained (but with font-name #f and dummy size
1.0), but there still are font names in the glyph-string (this time it is
"TeXGyreSchola-Italic")

(translate-stencil (0.0 . 0.0) (glyph-string #
TeXGyreSchola-Italic 3.865234375 #f (quote ((0.717009448818898
(-0.0341433070866142 . 1.4340188976378) 0.0 0.0 i) (0.785296062992126
(-0.0341433070866142 . 1.36573228346457) 0.0 0.0 t) (1.26330236220472
(-0.0341433070866142 . 1.02429921259843) 0.0 0.0 a) (0.717009448818898
(-0.0341433070866142 . 1.60473543307087) 0.0 0.0 l) (0.717009448818898
(-0.0341433070866142 . 1.4340188976378) 0.0 0.0 i) (0.990155905511811
(-0.0341433070866142 . 1.05844251968504) 0.0 0.0 c)


It calls function *interpret_stencil_expression* and (in our two cases),
"named-glyph" and "glyph-string" should use function *find_font_function* 

But this function just takes care of "text" and "char".

Unfortunately, we have "named-glyph" and "glyph-string" instead (I think
font handling has considerably changed in the meantime), so that the
function returns nothing.


*Experimental correction*

When implementing "named-glyph" (giving back cadr) and "glyph-string"
(giving back caddr), we actually get

(#) for the NoteHead and
("TeXGyreSchola-Italic") for the TextScript in a first simple attempt.

With just your \number "1" example, TextScript will report ("Emmentaler-20")

So, basically, the information is there and it could be done.
But this looks like a tracker issue, because, as you found out, the function
currently just does nothing where it should give back a result.

All the best,
Torsten






--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: TextScript.outside-staff-padding and text's baseline

[Torsten Hämmerle]

David Kastrup wrote
> Given how often this occurs, maybe we should create some function for
> that purpose rather than putting pairs everywhere in peacemeal?
> 
> The principal question is what to do when the event does not have an
> explicit direction.  Then one would have to refer to the grob callback
> instead, maybe?

Yes, the up/down padding decision can only be taken in a callback, I agree,
because we need to wait for the direction to be finally known.

I my practical cases, I often need both directions and as soon as
staff-padding is used, I get an unbalanced look without different up/down
values.
When setting the one single value too high, the text above the stave gets
pushed too far up, when setting a smaller value, the text below the stave
will not be aligned to the baseline any more and the aligning purpose of
staff-padding is not fulfilled.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: TextScript.outside-staff-padding and text's baseline

[Torsten Hämmerle]

David Kastrup wrote
> Anything wrong with using a callback?

No, not at all, callbacks are fine and do solve the problem..
But given the fact that "aligning to the baseline" is specific to text so
that different up/down staff-padding values are rather the rule than the
exception, I thought it'd be nicer to simply say something like

  \override TextScript.staff-padding = #'(3 . 4) 

instead of having to define a custom callback function for a standard
situation.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: TextScript.outside-staff-padding and text's baseline

[Torsten Hämmerle]

The only thing I do not like about staff-padding is that, strictly speaking,
we'd need different values for up and down direction:
Above the stave, just the descenders go between stave and text baseline,
whereas below the stave, the baseline has to be sufficiently far away from
the stave so that there's enough space for the full text height:

 

Wouldn't it be nice to have staff-padding accept a pair of values?

Just thinking...
Torsten
 



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: acciaccatura issue

[Torsten Hämmerle]

Hi Jay,

This is a known issue (that, unfortunately, has not been solved so far).

But there's a remedy:
Acciaccaturas (and appoggiaturas and grace notes in general) at the
beginning of a measure must be  inserted in *all* the staves using "grace
spacer rests" of appropriate duration.

In your case, you can simply put a "\grace s8" in measure 3 of the upper
stave:

\grace s8 c8 \times 2/3 {d8 [c b]} g [d]

 

That way, timing will not get out of pace and the acciaccatura at the
beginning of measure 3 in the lower stave will be positioned correctly.
I know that's kind of a nuisance, but at least it solves the problem for the
time being…

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Modified slur stencil with added markup

[Torsten Hämmerle]

Urs Liska-3 wrote
> What is 'interval-center'?


Hi Urs,

Harm already revealed where interval-center is being defined.

But why did I use it?
A stencil x-extent is a pair of left and right extent, and in order to know
the total extent, we'll have to add up (car x-extent) and (cdr x-extent) and
divide it by 2 in order to get the centre. This could be done manually or by
using interval-center.

Using the horizontal centre of both markup and slur, the necessary x-shift
can be easily calculated.

In this case, it is important to know that ly:stencil-combine-at-edge uses
the reference point for alignment and the stencil will stick out to the left
if the left extent is negative.
The slur has a positive (!) left extent, and that's why it is shiftet to the
right with regards to the reference point (at the left edge of the
notehead).
In your original attempt, centering the slur destroyed this slight shift and
moved the whole lot to the left.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Modified slur stencil with added markup

[Torsten Hämmerle]

Hi Urs,

The centering of the slur stencil destroys its alignment (i.e. reference
point), so I'd just leave it alone and center-align the text by explicitly
calculating the necessary markup x shift from the stencil extents.


%%
\version "2.19.82"

annotatedSlur =
#(define-music-function (padding text) ((number? 1) markup?)
   #{
 \once \override Slur.after-line-breaking =
 #(lambda (grob)
(let*
 ((stencil (ly:slur::print grob))
  (dir (ly:grob-property grob 'direction))
  (markup-stencil (grob-interpret-markup grob text))
  (shift (- (interval-center (ly:stencil-extent stencil X))
   (interval-center (ly:stencil-extent markup-stencil X
  (new-stencil
   (ly:stencil-combine-at-edge
stencil
Y dir
(ly:stencil-translate-axis markup-stencil shift X)
padding)))
 (ly:grob-set-property! grob 'stencil new-stencil)))
   #})

{
  \annotatedSlur
  %\markup \score { c''' }
  \markup "hin."
  c''4 ( g' g' c'' )
}
%%

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: score with linea

[Torsten Hämmerle]

Aaron Hill wrote
> Torsten,
> 
> Not sure if you meant to attach code that demonstrates that, […]

Thanks for the hint, Aaron,

I actually used the raw … /raw tags because I thought it a good idea.
Obviously, this code remains hidden in some environments.

So, just for the sake of completeness, here's the classic %%% method:


\version "2.19.82"

\layout { ragged-right = ##f } 
\new Staff \with { \override StaffSymbol.line-positions = #'(-8 -4 -2 0 2 4)
} 
  {
s1
  }


All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: score with linea

[Torsten Hämmerle]

Hi Mario,

It is possible to define arbitrary stave lines and line positions:



 

You can even set individual thicknesses for these lines.

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to hide fingering in the output

[Torsten Hämmerle]

csmcd wrote
> When I try to hide the fingering using either of these methods, I get a
> core
> dump.

It even works in my Windows 7 (32bit) and Windows 10 (64 bit) environments,
tested with a variety of LilyPond versions.

What's your operating system and is there any useful error message?








--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: LilyPond issue 34 question

[Torsten Hämmerle]

Hi Jacques,

First of all, the different \grace durations (s128 instead of s8. resp. s16
s s) makes the Key Signature and Time Signature appear twice.
Second, if you use spacer rests of the correct duration, the 16th grace
notes notes will be naturally spaced and key and time sigs will happen in
the same point of time as they should.

If you try \grace { s16 } or \grace { s8 } just for fun, the shifted Time
Signature will just fall within the grace notes.

\grace { s4 } (longer than three 16th notes) will displace everything so
that you'll get a standard treble clef first an a overlayed bass clef in the
lower staff if you look closely. KeySignature and TimeSignature are doubled
and overlayed etc.

Exaggerating it and even setting \grace { s2 } or \grace { s1 } the double
KeySignature/TimeSignature will be shifted away from each other, but still
overlap.


To make a long story short (and, technically, it's not at all trivial,
otherwise this issue would have been closed many years ago):
Why not just using *matching* durations for all the auxiliary \grace spaces?

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: changing fingering position

[Torsten Hämmerle]

Gianmaria Lari wrote
> \version "2.19.82"
> {b\finger \markup \override #'(word-space . 0) \line { 2 \circle 3 2 }}

Hi Gianmaria,

An even more straight-forward (imho) option would be to simply concatenate
the three markup elements to get rid of the spaces:

{b4\finger\markup \concat {2 \circle 3 2} \prall}


Harm's solution, however, is perferable if you want to have some padding in
between: the gap can be varied by adjusting word-space.

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: New

[Torsten Hämmerle]

Bernhard Kleine wrote
> Something like 
> legato = #(make-dynamic-script (markup #:normal-text  "legato" )) 
> in the header helped to bring in the Dynamics the legato etc. on line with
> \f etc. . 
> But now I would like to have the 'legato' in italics.
> 
> Obviously I can not deconstruct the instructions to achieve that tool.
> 
> Please show me How!


Hi Bernhard,

All the "#:…." instructions in scheme are just the same as the "\…"
instructions in ordinary markup.
Keeping that in mind, #:normal-text is nothing else but \normal-text and it
is needed to switch back to normal text from the special \dynamic font used
for p, mf, fff, etc.

So, if you want the "legato" in italics, simply add #:italic

  legato = #(make-dynamic-script (markup #:normal-text #:italic "legato" )) 

C'est tout ! 

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: A separate line for dynamics?

[Torsten Hämmerle]

Bernhard Kleine wrote
> I remember vaguely that one can have a "staff" for the dynamics in an
> score, but I can not find it in the documentation of 2.19.82. Can you
> please point me to that.

Hi Bernhard,

I guess it's the Dynamics context you're having in mind. And, yes, it's hard
to find in the documentation.

A feeble hint is hidden in  1.3.1. Expressive marks attached to notes

  
(scroll about half-way down) where it says "The Dynamics context is
available to engrave dynamics on their own horizontal line"...

In  4.4.1 Flexible vertical spacing within systems

 
, the Dynamics context is mentioned, too.

References for keyboards

  
states "Dynamics may be placed in a Dynamics context, between the two Staff
contexts to align the dynamic marks on a horizontal line centered between
the staves; see Dynamics."

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Naming a StaffGroup

[Torsten Hämmerle]

Hi Joei,

You can move the ChoirStaff's shortInstrumentName almost wherever you want
by using an appropriate markup.
There's a mean little trick combining an empty markup " " with the actual
instrument markup so that a \translate will take effect:

%%
gruppe = \new StaffGroup
\with {
  instrumentName = \markup \rotate #90 "Chor II_l" 
  shortInstrumentName = \markup \combine " " \translate #'(2.5 . 0) \rotate
#90 "Chor II_s" 
}
%%

… and that's what it looks like after the shortInstrumentName markup
manipulation:

 

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Single digit double time signature

[Torsten Hämmerle]

Cantus Ornatus wrote
> Is it possible modifying the standard double time signature syntax in
> order
> to have such a layout?

Hi F.,

You can change the time signature style to single-digit:
  \override Staff.TimeSignature.style = #'single-digit
That way, only the numerator will be printed.

Other style possibilities are #'mensural or #'neomensural for special
mensural glyphs.

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange dotted slur which are not slurs or ties

[Torsten Hämmerle]

Bernhard Kleine wrote
> But how make them dotted?

Phrasing slurs can be made dotted by \phrasingSlurDotted and they can be
made dashed by \phrasingSlurDashed.




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange dotted slur which are not slurs or ties

[Torsten Hämmerle]

Bernhard Kleine wrote
> These dotted slurs are not slurs since the text is not suspended. Please
> let me know how you would set this example.


Hi Bernhard,


I'd just use phrasing slurs \( and \). 
In contrast to ties or ordinary slurs, each note will get its syllable,
phrasing slurs won't create automatic melismata. Voilà !

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: changing the length (height? positions? endpoints?) of an arpeggio

[Torsten Hämmerle]

Kieren MacMillan wrote
> I’m trying to tweak the "length" of an arpeggio (by 1 staff space at the
> top), and can’t seem to find the correct incantation or doc reference.


Hi Kieren,

You can explicitly set an arpeggio's start/end positions by overriding the
positions property.
The internals reference is a bit misleading, as the standard property
descriptions mentions left/right only.
For an arpeggio, however, positions holds a pair of lower/upper position
values.

It is calculated by the ly:arpeggio::calc_positions function, and this
function can be used in a custom scheme function just subtracting a given
amount from the lower value and adding the same amount to the upper value.
A simple example, manipulating the "standard" positions by
subtracting/adding correctional values (0 at the lower end, 1 at the upper
end, as requested by you):


%%%  MWE begins
\version "2.19.80"

#(define (widen-arp grob)
   (let* ((pos (ly:arpeggio::calc-positions grob))
  (lower-corr 0.0)
  (upper-corr 1.0))
(cons (- (car pos) lower-corr) (+ (cdr pos) upper-corr

{
  \override Arpeggio.positions = #widen-arp
  1\arpeggio
}
%%%  MWE ends

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Spacing issue with magnifyStaff

[Torsten Hämmerle]

Hi foxfanfare,

That's exactly the reason why I never use \magnifyStaff.
Just have a look at the treble clef and time signature sticking together in
the upper stave, that's because if the lowest stave seems to govern the
overall spacing.

When needing single cue-size staves in a score (no matter where), I always
use the old-fashioned method of setting fontSize plus staff-space.
That way, the overall spacing of the score will not be corrupted - at the
expense that the cue-sized staves' spacing is too wide, but it has to "too
wide" in order to propery align with the rest of the score.

Here's your original example setting fontSize and staff-space (using
fontSize -4, the exact match of your 4/7 factor would have been
-4.844129532345624644651815903391...) :)

HTH,
Torsten

%%
\version "2.19.81"

<<
  \new Staff
  <<
\new Voice
\relative c'' {
  \voiceOne
  a16(^"CORRECT" fis a c e gis c a c gis e c gis e g gis) |
  a16( fis a c e gis c a c gis e c gis e bes' b) |
}
\new Voice
\relative c' {
  \voiceTwo
  c16 a c e gis b e r f c a fis c r r8 |
  c16 a c e gis b e r f c a fis c r r8 |
}
  >>
  \new Staff
  \relative c' {
\tuplet 3/2 4 { a8 8 8 8 8 8 8 8 8 8 8 8 }
R1
  }

>>

<<
  \new Staff
  <<
\new Voice
\relative c'' {
  \voiceOne
  a16(^"WRONG SPACING" fis a c e gis c a c gis e c gis e g gis) |
  a16( fis a c e gis c a c gis e c gis e bes' b) |
}
\new Voice
\relative c' {
  \voiceTwo
  c16 a c e gis b e r f c a fis c r r8 |
  c16 a c e gis b e r f c a fis c r r8 |
}
  >>
  \new Staff \with {
fontSize = -4
\override StaffSymbol.staff-space = #(magstep -4)
  }
  \relative c' {
\tuplet 3/2 4 { a8 8 8 8 8 8 8 8 8 8 8 8 }
R1
  }

>>

\paper {
  ragged-right = ##f
}
%%



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: [Question] How to increment the current bar number

[Torsten Hämmerle]

David Kastrup wrote
> Malte Meyn 

> lilypond@

>  writes:
> 
>> You have to get the Score context somehow. This can be done by using
>> \applyContext. I don’t know what context the procedure then is called
>> with (maybe the current Bottom?)
> 
> The current "whatever".  Since you already had R1*3 descend to Bottom,
> that would be Bottom.


How about using ly:context-property-where-defined?
As in:


%%%
\version "2.19.82"

increaseBarNumber =
#(define-music-function (par loc addm) (integer?)
   (make-apply-context
(lambda (context)
  (let* ((where (ly:context-property-where-defined context
'currentBarNumber))
 (cbn (ly:context-property where 'currentBarNumber)))
(ly:context-set-property! where 'currentBarNumber (+ addm cbn))


testmusic = \relative {
  c'4 d e f g a b c d e f g a b c2 R1*3
  c4 b a g f e d c b a g f e d c2
}

\score {
  <<
\new PianoStaff <<
  \new Staff { R1*22 }
  \new Staff{
\testmusic
<>^"↓ increase barnumber by 100"
\increaseBarNumber #100
\testmusic
  }
>>
\new Staff { \testmusic \testmusic }
  >>
}%%%

All the best,
Torsten





--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: ^\markup placed below score

[Torsten Hämmerle]

Rachel Knight wrote
> Below is my score for a piece for a primer method. When the staff is
> showing, all the markups are in the right position, but as soon as I hide
> the staff lines, the last “R.H.” moves below the notes instead of above
> them, as I have specified. How do I fix this?

Yes, and the first _"L.H." goes above the notes rather than below.
Without any stave, LilyPond obviously has some difficulties to tell up from
down ;)

To solve this, I have hidden rather than omitted the StaffSymbol, but
reduced the line-count to 1, thus minimize spacing interaction.
Withoud \stopStaff, we'll have to remove the ledger lines and bar lines,
too. Clef and TimeSignature and Clef can be removed using \omit.
One \relative statement is enough and I've directly set
TextScripit.font-size to -3 instead of typing \teeny each time.
\voiceUp and \voiceDown automatically sets the direction of TextScript, so
even a neutral -"R.H."/"L.H." will do.


%%
\version "2.19.82"

 <<
   \new Staff \relative  {
 \override Staff.StaffSymbol.line-count = 1
 \hide Staff.StaffSymbol
 \omit Staff.Clef
 \omit Staff.TimeSignature
 \omit Staff.LedgerLineSpanner
 \omit Staff.BarLine
 \easyHeadsOn
 \override Stem.length = 7
 \override NoteHead.font-size = 3
 \override TextScript.font-size = -3
 \voiceTwo
 c4-"L.H." d e2
 \voiceOne
 c'4-"R.H." d e2
 \voiceTwo
 c'4-"L.H." d e2
 \voiceOne
 c'4-"R.H." d e2
   }
 >>
%%

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Aligning voices

[Torsten Hämmerle]

Rachel Knight wrote
> I’m having trouble having these two chords line up correctly. Whenever I
> change the stem direction of the top voice (either with /voiceOne or
> /stemUp), it shifts the notes to the right and is no longer in alignment
> with the notes in my second voice.


Hi Rachel,

First of all, the \relative has to go outside the {}.
Apart from that, it is totally OK that the main note columns align
horizontally. With opposing stem directions, naturally the displaced notes
elude into opposite directions.

Gould says:
/"*Double stems:* Arrange chords so that notes on the 'correct' side of each
stem align vertically. (This same principle should be used to align
adjacent-note chords in a score […])"/

LilyPond's vertical alignmet is perfectly alright.

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Auto-ottava Scheme script problems

[Torsten Hämmerle]

Sorry, certainly more straight-forward way would be just to use (filter
(music-type-predicate 'note-event) to filter out the note-events only:

 (let* ((elts (filter (music-type-predicate 'note-event)
  (ly:music-property mus-expr 'elements)))
   […]


auto-ottava2.ly
  


All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Auto-ottava Scheme script problems

[Torsten Hämmerle]

David Bellows wrote
> The following works as intended:
> 
>  or
> 
> 4
> 
> but these produce errors:
> 
> \f or
> 
> 4\f
> 
> The error message:
> 
> GNU LilyPond 2.19.82
> Processing `auto-ottava.ly'
> Parsing...auto-ottava.ly:24:15: In procedure ly:pitch-steps in
> expression (ly:pitch-steps p):
> auto-ottava.ly:24:15: Wrong type argument in position 1 (expecting Pitch):
> ()
> 
> The problem seems to be when there are dynamics involved with chords.
> Note, this does *not* happen with single notes and dynamics, only with
> chords and dynamics.


Hi David,

In chords, all the elements have to be looped, and, as it happens, dynamics,
but also scripts like staccato etc. will be among these elements and calling
ledger-line-no passing anything other than a pitch will lead to the "Wrong
type argument" error.

Here's a quick fix (see file attached below):
Filter out pitches from the elements and use the filtered list "pitches"
instead of "elts". This way, only pitches will be passed to ledger-line-no,
and everything will work as desired.
There might be more elegant ways, but I wanted to keep the coding as
original as possible.

auto-ottava2.ly
  

HTH,
Torsten





--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: center figured bass vertically

[Torsten Hämmerle]

mari+lilypond wrote
> Hi Torsten,
> 
> your answer did overlap with my last mail. It seems that your suggestion
> solves my questions in a way as I imagined.

Hi Markus,

I had some difficulties submitting my answer and, in the end, it appeared
four times - sorry for that.


Just a remark regarding the difference between \new and \context:
Using \context with the (existing) Staff's name will pass the musical
expression to this Staff. 
That's why your attempts increasing vertical spacing variables failed - both
notes and bass figures belong to the same Staff, so any inter-staff spacing
will have no effect.

\new, in contrast to that, will always create a new context (even if its
name already exists).

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: center figured bass vertically

[Torsten Hämmerle]

mari+lilypond wrote
> I use \dynamicUp (because it's not only cello but also a singing voice
> with
> lyrics) and in the very first example (\context Staff =) dynamic was
> drawn above figured bass and now below. How can I swap both in the
> example below?

Hi Markus,

Beyond the technical solution, it's quite challenging to have lyrics,
dynamics, and bass figures associated with one stave in a clearly readable
and aesthetic way.

The problem with Phil's solution is that the bass figures get their "own
line", so that the dynamics of the stave below will always stay below the
bass figures. The the "own separate line" is the reason for the nice
vertical alignment.
You might create a separate dynamics context and put it on top of the bass
figures.

In your original example (using the same Staff context for notes, dynamics,
and bass figures) you didn't like the alignment, because the bass figures
didn't share a common baseline.
This, however, can be achieved as usual: by setting staff-padding large
enough that all the figures' baselines are aligned at the same vertical
position:


%%%
\version "2.19.82"

violin = \relative c'' {
  e4 f4 g4 a4
}

cello = \relative c' {
  \dynamicUp
  c2. \p g4
}

figuredBass = \figuremode {
  \override Staff.BassFigureAlignmentPositioning.direction = #UP
  \override Staff.BassFigureAlignmentPositioning.staff-padding = #4
  <3>4 <4>2 <3>4
}

lyrtxt = \lyricmode { Please don’t! }

\score {
  <<
\new Staff = "violin"  {
  \clef treble \violin
}
\new Staff = "cello" \new Voice = "melody" {
  \clef bass \cello
}
\context Staff = "cello" \figuredBass
\new Lyrics \lyricsto "melody" \lyrtxt
  >>
}
%%%


 

Drawback: that way, the bass figures will keep at least the vertical
distance set by staff-padding, even if there are no notes above the stave.
Stacking dynamics even on top, it is not clear what save the dynamics belong
to if they come too close to the stave above. Increasing the stave distances
might require a lot of space and one could think of even using separate
saves for cello and vocals.

But maybe this is of any help, at all…

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: center figured bass vertically

[Torsten Hämmerle]

mari+lilypond wrote
> I use \dynamicUp (because it's not only cello but also a singing voice
> with
> lyrics) and in the very first example (\context Staff =) dynamic was
> drawn above figured bass and now below. How can I swap both in the
> example below?

Hi Markus,

Beyond the technical solution, it's quite challenging to have lyrics,
dynamics, and bass figures associated with one stave in a clearly readable
and aesthetic way.

The problem with Phil's solution is that the bass figures get their "own
line", so that the dynamics of the stave below will always stay below the
bass figures. The the "own separate line" is the reason for the nice
vertical alignment.
You might create a separate dynamics context and put it on top of the bass
figures.

In your original example (using the same Staff context for notes, dynamics,
and bass figures) you didn't like the alignment, because the bass figures
didn't share a common baseline.
This, however, can be achieved as usual: by setting staff-padding large
enough that all the figures' baselines are aligned at the same vertical
position:


%%%
\version "2.19.82"

violin = \relative c'' {
  e4 f4 g4 a4
}

cello = \relative c' {
  \dynamicUp
  c2. \p g4
}

figuredBass = \figuremode {
  \override Staff.BassFigureAlignmentPositioning.direction = #UP
  \override Staff.BassFigureAlignmentPositioning.staff-padding = #4
  <3>4 <4>2 <3>4
}

lyrtxt = \lyricmode { Please don’t! }

\score {
  <<
\new Staff = "violin"  {
  \clef treble \violin
}
\new Staff = "cello" \new Voice = "melody" {
  \clef bass \cello
}
\context Staff = "cello" \figuredBass
\new Lyrics \lyricsto "melody" \lyrtxt
  >>
}
%%%


 

Drawback: that way, the bass figures will keep at least the vertical
distance set by staff-padding, even if there are no notes above the stave.
Stacking dynamics even on top, it is not clear what save the dynamics belong
to if they come too close to the stave above. Increasing the stave distances
might require a lot of space and one could think of even using separate
saves for cello and vocals.

But maybe this is of any help, at all…

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: center figured bass vertically

[Torsten Hämmerle]

mari+lilypond wrote
> I use \dynamicUp (because it's not only cello but also a singing voice
> with
> lyrics) and in the very first example (\context Staff =) dynamic was
> drawn above figured bass and now below. How can I swap both in the
> example below?

Hi Markus,

Beyond the technical solution, it's quite challenging to have lyrics,
dynamics, and bass figures associated with one stave in a clearly readable
and aesthetic way.

The problem with Phil's solution is that the bass figures get their "own
line", so that the dynamics of the stave below will always stay below the
bass figures. The "own separate line" is the reason for the nice vertical
alignment.
You might create a separate dynamics context and put it on top of the bass
figures.

In your original example (using the same Staff context for notes, dynamics,
and bass figures) you didn't like the alignment, because the bass figures
didn't share a common baseline.
This, however, can be achieved as usual: by setting staff-padding large
enough that all the figures' baselines are aligned at the same vertical
position:


%%%
\version "2.19.82"

violin = \relative c'' {
  e4 f4 g4 a4
}

cello = \relative c' {
  \dynamicUp
  c2. \p g4
}

figuredBass = \figuremode {
  \override Staff.BassFigureAlignmentPositioning.direction = #UP
  \override Staff.BassFigureAlignmentPositioning.staff-padding = #4
  <3>4 <4>2 <3>4
}

lyrtxt = \lyricmode { Please don’t! }

\score {
  <<
\new Staff = "violin"  {
  \clef treble \violin
}
\new Staff = "cello" \new Voice = "melody" {
  \clef bass \cello
}
\context Staff = "cello" \figuredBass
\new Lyrics \lyricsto "melody" \lyrtxt
  >>
}
%%%


 

Drawback: that way, the bass figures will keep at least the vertical
distance set by staff-padding, even if there are no notes above the stave.
Stacking dynamics even on top, it is not clear what save the dynamics belong
to if they come too close to the stave above. Increasing the stave distances
might require a lot of space and one could think of even using separate
saves for cello and vocals.

But maybe this is of any help, at all…

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: center figured bass vertically

[Torsten Hämmerle]

mari+lilypond wrote
> I use \dynamicUp (because it's not only cello but also a singing voice
> with
> lyrics) and in the very first example (\context Staff =) dynamic was
> drawn above figured bass and now below. How can I swap both in the
> example below?

Hi Markus,

Beyond the technical solution, it's quite challenging to have lyrics,
dynamics, and bass figures associated with one stave in a clearly readable
and aesthetic way.

The problem with Phil's solution is that the bass figures get their "own
line", so that the dynamics of the stave below will always stay below the
bass figures. The "own separate line" is the reason for the nice vertical
alignment.
You might create a separate dynamics context and put it on top of the bass
figures.

In your original example (using the same Staff context for notes, dynamics,
and bass figures) you didn't like the alignment, because the bass figures
didn't share a common baseline.
This, however, can be achieved as usual: by setting staff-padding large
enough that all the figures' baselines are aligned at the same vertical
position:


%%%
\version "2.19.82"

violin = \relative c'' {
  e4 f4 g4 a4
}

cello = \relative c' {
  \dynamicUp
  c2. \p g4
}

figuredBass = \figuremode {
  \override Staff.BassFigureAlignmentPositioning.direction = #UP
  \override Staff.BassFigureAlignmentPositioning.staff-padding = #4
  <3>4 <4>2 <3>4
}

lyrtxt = \lyricmode { Please don’t! }

\score {
  <<
\new Staff = "violin"  {
  \clef treble \violin
}
\new Staff = "cello" \new Voice = "melody" {
  \clef bass \cello
}
\context Staff = "cello" \figuredBass
\new Lyrics \lyricsto "melody" \lyrtxt
  >>
}
%%%


 

Drawback: that way, the bass figures will keep at least the vertical
distance set by staff-padding, even if there are no notes above the stave.
Stacking dynamics even on top, it is not clear what save the dynamics belong
to if they come too close to the stave above. Increasing the stave distances
might require a lot of space and one could think of even using separate
saves for cello and vocals.

But maybe this is of any help, at all…

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Follow up: using a bracket or brace to indicate an organ manual change

[Torsten Hämmerle]

Joseph Srednicki wrote
> I have just encountered the situation where the manual-change bracket is
> colliding with an accidental. See the example included below.
> 
> Do any members of this list have any suggestions to resolve this
> situation?


Hi Joe,

The manual-change bracket is nothing but a TextScript markup. TextScript
markups can be shifted around without disturbing the overall spacing by
setting the extra-offset property.
In this case (I suppose the "Ch" belongs to the bracket and should be
shifted, too), you can easily adapt the extra-offset property as needed:

[…]
  4 
  \once\override TextScript.extra-offset = #'(-1 . 0)
  ^\ch^\markup\openBracket #17 \trill g8. [ fs16 ] |
[…]

If just the bracket (without the "Ch") has to be shifted, you might use the
\tweak command (restricted to the bracket):

[…]
   4 ^\ch-\tweak #'extra-offset #'(-1 . 0)^\markup\openBracket
#17 \trill g8. [ fs16 ] |
[…]

 

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

Thomas Morley-2 wrote
> this weekend I'll have not much time and I'll be completely offline
> next week for holidays.

No need to hurry, Happy Holidays ;) (oh no, that was politically correct and
is restricted Christmas time use only).



Thomas Morley-2 wrote
> In my initial testing I experienced different behaviour, for no other
> reason than different finger-numbers, i.e. small differences in their
> extents.
> Especially for right positioned fingers.
> So I recommend thorough testings ...

Yes, the slightest deviations in the number extents may just be over a
threshold or not.
The right-positioning problems, in any case, can't be solved by just
translating the stencil, so it's no wonder you very unstable results when
testing.
When taking all the dots into account, however, they make up a solid barrier
so that no fingering can slip through any more and everything will be stable
and robust against tiny extent variations.



Thomas Morley-2 wrote
> The curvy positioning is bad, imho.
> But I agree it might be a different issue.

Yes, that's a question of design and is definitely not linked to the
overlapping problem of issues 3692 or 5393. It should definitely get its own
issue (as well as the generally overlapping circled string numbers...)



Thomas Morley-2 wrote
>> But, as I said, I consider this expected behaviour, even if it seems odd
>> at
>> first glance.
>> Would you agree?
> 
> Yes, so far. :)

Well, then. I'm just wondering about the self-alignment functionality that
correctly adjusts the Y-offset depending on self-alignment-Y and
parent-alignment-Y, only it's via callback and too late for positioning and
thus the collisions happen.
I don't the idea of unnecessarily aligning the stencil twice -- first for
correct positioning, and then again when the self-alignment callback kicks
in.

All the best and enjoy your week off
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

Thomas Morley-2 wrote
> I tried to Y-center the Fingering-stencil.
> 
> Though, with the example below the result is not all that convincing.
> […]
> Additionally, if fingeringOrientations contains 'left or 'right a
> FingeringColumn is built at Staff-level, so the 'snap-radius-property
> comes into play.
> 
> No real clue how to proceed...


Hi Harm,

From my point of view, the Y-centering of the fingering stencil is perfectly
OK (we just need a "proper" solution), the dot collision problem has
bettered and can be completely cured by considering all the dots of the
chord.

So, your remaining concern is the strange (?) behaviour of the
FingeringColumn with respect to the snap-radius.
This looks admittedly odd and I was wondering why the heck the outer
fingerings don't come closer to their noteheads, respectively why are they
arranged in a circular shape even if there is no accidental in the way.
But, looking deeper into this, it is the expected behaviour and everything
works as designed. If we don't like this, it would be another issue to
change FingeringColumn algorithm, but, in any case, this is no unwanted
side-effect of our stencil manipulations.

To illustrate this, I've switched off any padding values, put a box around
the fingering numbers and gradually changed the font size from very small to
big in order to be able to observe the evolution of fingering placement.
I've used just one flat because of its straight left border.

 

Starting off with a very small font size, there's enough space for each
fingering to take its ideal Y-position, exactly centred on its notehead.


*Rule: A fingering must never get in between accidentals and noteheads.*


*In (1)*, the fingering "1" hardly touches the blue line signifying the
lower end of the flat accidental. It still can stick to its notehead. 
Fingerings 2, 3, and 4 clearly have to go outside the flat and are pushed
away from the notehead because of The Rule.

*In (2)*, the font size has been increased so that the "1" just slightly
gets into the "forbidden" flat area and therefore is pushed away from the
notehead, too.  The "5" still has enough space.

*In (3) and (4)*, the increasing height of the numbers starts spreading them
vertically, away from their original Y position.  In (4), it is clearly
visible that the "1" does not interfere with the flat anymore, but still (!)
keeps its outside position.

*In (5)*, finally, all the fingering number keep a distance from their
noteheads, even if the "1" and the "5" are actually quite far away from the
accidental.

The (intended) reason for this is that, even if there seems to be enough
space in the direct vicinity of their noteheads, these fingerings stay
"outside" because at their original Y position, they'd get in between
accidentals and noteheads. That's the simple reason why they stay "outside":
their X position is determined by the accidentals, calculated as if the
fingerings had their original Y position (i.e. the notehead's Y position).
In a second step, their Y position will be spread out due to stacking, while
keeping the X position.

If there are more than on accidentals involved (or sharps with their more
complex left skyline), the stacked fingerings may take on alignments along a
curved path.

In the end, snap-radius is used to avoid very small irregularities by
positioning the fingering in a straight line if they have "nearly" the same
X position to avoid an irregular, look.

But, as I said, I consider this expected behaviour, even if it seems odd at
first glance.
Would you agree?

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Making slurs more visible

[Torsten Hämmerle]

Galen Menzel wrote
> Just so I understand, it seems that Tie.details.min-length cannot 
> influence note spacing. What does it influence other than this specific 
> case that I am asking about here?

Hi Galen,

By the way: I also stumbled over the fact that min-length is not listed
among the details default values shown in the internals documentation.

How come? This is because it is not there initially and therefore is not
listed as a default value.
In these cases, a hard coded value will be used instead (in this case, it's
#1, but you'll have to look into the coding). The full overview of available
properties can be found in the tie-interface documentation as described by
David (N).

*What does min-length actually do?*
I really does not influence note spacing, this is only about the choosing
the "best" of several possible tie configurations. Just a few examples:
There is a relationship between height and length of a tie, it may go in
between stave lines or not, in between noteheads or not etc.
Lilypond plays around with several possible solutions, adds up penalty
values and finally picks the solution with the lowest number of penalty
points, i.e. the optimal solution.


Taking this into account, there is /yet another way/ for avoiding these tiny
ties: just increase the penalty value for min-length ties, thus making them
very unattractive:

  \override Tie.details.min-length-penalty-factor = #1000 (default: 26)

This will make all tie configurations with very short (min-length) ties very
unattractive and LilyPond will favour any other solution.
You may look at all the *_penalty values in the details list to get an idea.
When LilyPond has to decide between "knit or chair", it will pick the one
that does the least harm (sorry, Thomas).

This is just to explain how the penalty system works for finding the optimum
solution among several possibilities, but of course the best way is to say
"I definitely do not want ties shorter than min-length!" is simply setting
Tie.details.min-length.

HTH,
Torsten






--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Making slurs more visible

[Torsten Hämmerle]

Galen Menzel wrote
> Is there a simple way to direct lilypond to use the larger 
> ties here?

Hi Galen,

Yes, there are several ways:

The most obvíous way is to use

  \override Tie.minimum-length = #...

But this also affects the spacing of notes.


If I get you correctly, you'd rather like to keep the spacing (without
lyrics, it's even tighter), but you don't want the ties to become too short
when slipping in between the noteheads.
This can be achieved by playing around with one of the details properties:

  \override Tie.details.min-length = #...

A sufficiently large value of details.min-length will prevent a tie from
being squeezed into a too narrow gap between noteheads.

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Piano, voices and stem directions

[Torsten Hämmerle]

[Off topic]


Urs Liska-3 wrote
> The sustain pedal of a real (grand) piano is nothing like the 
> MIDI pedal of the same name, but much closer to the MIDI volume pedal 
> ;-) 

To spare the honour of MIDI, half-damper pedals do exist and they act as a
continuous controller. Whether the sound engine used (resp. the sound) can
handle it or not is a different story...



Urs Liska-3 wrote
> The exact pedal position is a function of the imagined sound, the 
> characteristic of the instrument and the acoustics of the room. And it 
> is (should be) only partially controlled consciously, mostly it is a 
> subconscious feeback loop between the ears and the muscles.
> […]

… and, in my opinion, the sustain pedal is one of the most underrated
elements of the piano, it deserves much more attention than it often gets,
at least in non-professional environments.
The subtleties of tastefully dosed damping are an essential part of piano
playing.



Urs Liska-3 wrote
> I recall that for example Claudio Arrau went to great length arguing that 
> the distribution of hands is a means of expression and that even if 
> (well, actually *because*) it imposes additional demands on the player 
> it should be faithfully executed. I found this to be a very interesting 
> thought, although I didn't adopt it personally.

A very interesting thought, indeed, I think this also depends on the music
to a certain extent and it is one of the great obstacles and a reason why
one needs a good teacher when learning the piano:
On the one hand (pun!), people are different and should pick the
fingering/hand distribution that suits them best. 
On the other hand, for the learning, everything new feels awkward it needs a
lot of practice to get used to it and you must not duck away from the
effort.
So, probably, mostly in educational drills/études, one had better stick to
the instructions, but later, in real life, there is no reason why
experienced pianists should not do it the way it works best for them.

Even the greatest pianists/composers of all time could not always feel their
way into other people, and even the greatest pianists often do things
unconsciously (due to talent or genius) without being able to pass it on to
their disciples. :)

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Piano, voices and stem directions

[Torsten Hämmerle]

Noeck wrote
> Probably, that also means that using separate voices is the appropriate
> syntax, isn’t it? Can I make the slur aware of other voices’ notes?

Hi Joram,

Sometimes, decisions whether to use separate voices, temporary parallel
contexts, etc., are often more of a technical nature (coding-wise).

But in this case, at least that's my personal opinion, I think we have to
distinguish between the musical idea/content (the "illusion" created by the
pianist) and how one can actually play all this with only two hands (and the
sustain pedal).
I'd see the musical line (the semiquavers, even with a phrasing slur) as one
voice and therefore code it as one voice. The stem directions, to me, are
mere hints for the player (very valuable hints, though).

Rachmaninov managed to incorporate the intended rapid transitions between
the two hands without having to clutter the music with m.g./m.d. remarks
(main gauche/left hand, main droite/right hand) and he even hints about
pedaling without clumsy \sustainOn/Off symbols.
Pedaling is very delicate there, anyway, sometimes one might even use
half-pedaling (not just on/off).

Just using \stemUp and \stemDown seems appropriate to me, because it's one
single voice (just being divided up into two hands for physiological
reasons) and the dynamics stay where they are, it's easier to start and end
phrasing slurs, …

And, last but not least: these "encrypted playing instructions" are, just
like fingerings in general, not carved in stone and hardly justify a strict
separation of voices.
Just look at the last two down-stemmed semiquavers in the measure: Some
(most?) play them using the right hand, even if their stems are down.
Later on, I'd still use a single voice that changes staves. 
A single voice for "the line" seems most natural to me. But opinions may
differ, of course.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Piano, voices and stem directions

[Torsten Hämmerle]

Hi Joram,

This is all about the transitions between both hands: the downstem notes are
to be played by the left hand.

HTH,
Torsten 



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: changing symbols used by Measure_grouping_engraver

[Torsten Hämmerle]

Thomas Morley-2 wrote
> Hi Torsten,
> 
> iiuc, this will result in a _horizontal_ line, not vertical. ;)


Drat, this tiny detail makes my simplistic attempt rather useless.

Lame excuse: "No, this is not a horizontal line, it's actually a vertical
line, just very thick and very short". ;)

But, as usual, your elaborate solution leaves nothing to be desired.

Thanks,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: changing symbols used by Measure_grouping_engraver

[Torsten Hämmerle]

Flaming Hakama by Elaine wrote
> In particular, how to change the symbol used to denote the dotted 8th
> value
> in compund time:
> instead of a triangle, how do I get a vertical bar (or slash)?

Hi Elaine,

The two options "triangle" and "bracket" are pretty much hardcoded.
But you can set the height (thus squeezing both forms into a vertical line
when you set height to 0) and thickness (to make this line as thick as you
like):

  \override Staff.MeasureGrouping.height = 0

That way, you'll get a vertical line (unfortunately the bracket will be
indistinguishable then from the triangle).

But you might define a custom stencil quite easily that sets the height to 0
if style is #'triangle and then calls the original print stencil.
In the following example, I've used the original snipped coding as a basis,
because in your example, there were no brackets at all.

%%%
\version "2.19.81"

#(define (custom-grouping-stencil grob)
   (let ((style (ly:grob-property grob 'style)))
 (if (eq? style 'triangle)
 (ly:grob-set-property! grob 'height 0))
 ly:measure-grouping::print))

\score {
  \new Voice \relative c'' {
\time 9/8
g8 g d d g g a( bes g) |
\set Timing.beatStructure = 2,2,2,3
g8 g d d g g a( bes g) |
\time 4,5 9/8
g8 g d d g g a( bes g) |
\time 5/8
a4. g4 |
  }
  \layout {
\context {
  \Staff
  \consists "Measure_grouping_engraver"
  \override MeasureGrouping.stencil = #custom-grouping-stencil
}
  }
}
%%%

 

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

Thomas Morley-2 wrote
> […]
>   \mark "Fingerings right"
>   \set fingeringOrientations = #'(right)
> […]


Hi Harm,

When setting fingeringOrientations to #'(right), the occasional collision of
fingering and dots are a result of dots moving vertically away too far from
their noteheads.

Intervals of a second in combinations with "quantized" dot placements
between lines may lead to 1 staff-space Y distance between notehead and dot,
i.e. the fingering does not collide with the dot of its own notehead, but
runs into a neighbouring dot:

 

I'll try to to also take care of the neighbouring dots (i.e. make them known
to the side-position-interface...

Let's see,
Torsten





--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

Simon Albrecht-2 wrote
> I created one and tried to include all the analyses yet presented.
> https://sourceforge.net/p/testlilyissues/issues/5393/;

Thanks, Simon. I think makes sense trying to improve the fingering placement
step by step.
And everything that can get ...Orientations (fingeringOrientations,
strokeFingerOrientations, stringNumberOrientations) is affected.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

Hi Harm,

Yes, fingerings are quite a large construction zone (and right hand
fingerings or string numbers as well).
Issue 3692 hasn't been solved yet, and your examples show that there is also
a general dot collision problem for right fingerings.

When increasing snap-radius, fingerings may overlap when forced into one
vertical column.



Thomas Morley-2 wrote
> I tried to Y-center the Fingering-stencil.
> […]

This is pretty much what I did (using a much more primitive hard-coded
markup just to see the effect).
This centering at least solves the accidental interaction problem, but it is
only one step of many.

And of course the LilyPond coding should be corrected without having to
manipulate the stencil.

All in all, fingering placement is awfully challenging, using standard
interfaces and avoiding collisions with anything that might get into the way
(other fingerings, right hand fingerings, string numbers, accidentals, dots,
scripts, ties, slurs, …)

In any case, your examples add another level of difficulties, as the close
notehead positions require additional vertical shifting of fingerings and
dots. Phew...

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

Simon Albrecht-2 wrote
> I went to the issue tracker so this doesn’t get lost – it seems to be 
> related to or a subset of 
> https://sourceforge.net/p/testlilyissues/issues/3692/;.

Hi Simon,

While the descriptive title "Fingering collision with accidentals" of issue
3692 more or less describes our current problem, I think this has to be
technically separated.


Fingering positions at the left concerned:
1. Why aren't the numbers placed below the accidental even if there's plenty
of space?
2. Why do numbers above an accidental overlap?

This strange effect can be perfectly explained when assuming that horizontal
positioning is done in a state where the numbers still sit on their
baselines and these baselines are at the height of their corresponding
notehead.
After horizontal positioning, these numbers will be centred vertically, i.e.
shifted down by half a staff-space (because they happen to be about a
staff-space high).
This shift will make them either overlap an accidental below or create an
unnecessary gap.

I've tried to illustrate this in the following PDF:
test-accidental-fingering2.pdf

  

I think this should get its own tracker issue.

All the best,
Torsten






--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

David Kastrup wrote
> A feature of the placement algorithm and a bug of the character design
> maybe?


The sharp glyph design looks OK to me:

 

left: fingering and accidental skylines taken from the example (stave
removed)
right: MetaFont glyph proof printout with bounding box.

But something definitely does not work quite as intended: fingerings above
accidentals even tend to overlap the accidental to some degree, whereas
below the accidental the is an unnecessarily large gap.

Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fingering position in polyphony face to sharp glyph. Bug?

[Torsten Hämmerle]

Schneidy wrote
> The first fingerings are independently positioned while the second
> integrate the accidental sign to calculate the padding.
> This happend with sharp glyph only.
> I guess it has something to do with upper 'Y-extent from the fingering --
> not from the glyph(?) --, however I did not find any issue.
> Any idea?


Hi Pierre,

Yes, it's the sharp glyph that pushes the fingering away.
More precisely, it's the horizontal skylines. You can easily verify this by
reducing Staff.Accidental.font-size until the 2 fits beneath the sharp
accidental.

So this isn't a bug, it's a feature. But admittedly, the automatic result
isn't quite satisfactory.
Anyway, in tight conditions like that I don't consider it a particularly
good idea to squeeze the fingering numbers in between the notes. It's hard
to tell which note belongs to zhe 1 between the F# and the G# in the upper
voice. Adding more padding would affect the spacing too much.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: The abyss

[Torsten Hämmerle]

Ralph Palmer wrote
> I'm surprised no one complained!

Sorry, I couldn't find the appropriate complaint form.



Ralph Palmer wrote
>> "Buck looking into the abyss."

Instead of complaining, on that occasion: Thanks a lot for your work on the
LilyPond Buck list.
Good to see that there is an apprentice Buck being prepared to face the
unfathomable abysses of a LilyPond virtually on par with the Mariana Trench.

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \textLengthOn in polyphony and over MultiMeasureRests

[Torsten Hämmerle]

Trevor Bača-2 wrote
> Torsten, how are you achieving the text centered above the pair of half
> notes in the original example (ie, in the measure top-headed with
> "Minima")? Try as I might, I can't get it!


Hi Trevor,

You've got me there! ;)

Standard \textLengthOn will push away neighbouring notes and you won't get
the markup text to neatly and symmetrically align with the barlines without
some tweaking.

\textLengthOn just sets the following two properties:

  \override TextScript.extra-spacing-width = #'(-0.0 . 0.4)
  \override TextScript.extra-spacing-height = #'(-inf.0 . +inf.0)

By adapting extra-spacing-width, we can actually set the left and right
"margins" of the text. This way, we can attach the TextScript to the second
note and make it overlap the first note.

Finally (this is not necessary, though) I've shifted both notes to the right
by using extra-offset to better match the original.

 

%%%
{
  \override TextScript.self-alignment-X = #CENTER

% custom version of \textLengthOn:
  \override TextScript.extra-spacing-width = #'(2.6 . 0.4)% default:
#'(-0.0 . 0.4)
  \override TextScript.extra-spacing-height = #'(-inf.0 . +inf.0)

% Shift NoteHead and Stem to the right
  \override NoteHead.extra-offset = #'(5 . 0)
  \override Stem.extra-offset = #'(5 . 0)

  R1
  \bar "||"
  c''2 c''^\markup \line { \typewriter "#'extra-offset" "trickery" }
  \bar "||"
}
%%

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Easy Note Heads and colors

[Torsten Hämmerle]

rodrigo wrote
> Since I am not a programmer ,  there is certainly a better way to do that,
> but at least it works for me. Kept here for reference and eventually
> helping
> others.


Hi Rodrigo,

There is a much easier way to do it:
The note names used by the standard engraver (just switching \easyHeadsOn,
nothing else) are taken from the note-names property of NoteHead.

If you need other note names, all you need to do is to override the
note-names vector, no need at all for any additional programming:

%%%
\version "2.18.2"

\relative c' {
  \easyHeadsOn
  \override NoteHead.note-names = #(vector '"dó" '"ré" '"mi" '"fá" '"sol"
'"lá" '"si")
  c4 d e f g a b c
}
%%%

The only remaining problem is that the long Portuguese names won't fit into
the noteheads, but this can be corrected by setting the font-size:

  \override NoteHead.font-size = #-11

The Easy notehead's diameter will always be calculated depending on
staff-space and line-thickness, so that the font-size in this case can be
used to change the font-size of the note name text, not the notehead itself.

HTH,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: an "odd" accidental problem...

[Torsten Hämmerle]

Anthony Youngman-2 wrote
> Well, lilypond is about the only place I ever normally see it! :-) YMMV
> :-)

Here's a non-LilyPond excerpt of Tchaikovsky's Nocturne op. 19 no. 4:
 
After the cadenza, the key signature changes and the E-flat is being
cancelled.
This is the "old Russian standard" where the cancellation signs go before
the barline.

LilyPond's default corresponds with the traditional practice (see Gould),
the contemporary practice will do without cancelling signs, you normally
won't see them in modern editions.

Cheers,
Torsten





--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: an "odd" accidental problem...

[Torsten Hämmerle]

Addenda et corrigenda:

I was mistaken, my example shown wasn't an example of D-sharp, but actually
D-natural. So the order of accidentals is comprehensible.

This becomes clear when taking the preceding measure (at the end of the
preceding line) into account:

 

The original D-flat will be turned into a D-natural and from there (!) into
a D-sharp.  There is no need for a natural sign because the preceding
D-natural.
In the next bar, the first sharp seems to be a cautionary accidental
(reminding of the D-sharp in the preceding measure) with a natural directly
behind, yielding a D-natural again.

In any case, the multiple accidentals are quite unnecessary, the ITM edition
was published in 1959.
The only thing I can think of that the composer wanted to explicitly point
out the direction of the alteration with respect to the preceding
accidental. In this case, a D-natural without preceding sharp would imply an
alteration up from the key signature's D-flat, where actually it's a
down-alteration with respect to the preceding D-sharp.
But this is rather speculative, but at least this way of seeing it makes
some sense to me.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: an "odd" accidental problem...

[Torsten Hämmerle]

Urs Liska-3 wrote
> It's completely impossible to discuss these questions without the 
> musical context. There are musical situations where e natural and f flat 
> can be freely exchanged, but there are many other contexts where it 
> *does* make a difference. […]


Hi Urs,

Of course you are right and also David (K.)'s remarks about enharmonics with
regards to strings/positions certainly is what these Etudes are about
("thinking of a B-sharp as a C" etc.).  I was just playing on the original
posting ("E natural needed") when the source/composer/background was
completely unknown.

By the way, I've found a similar case (combination of accidental and
cancellation sign) in Fuchs' 16th Etude, just to show a sample musical
context:

 

Apart from enharmonic spellings (I'm OK with that, there always may be
reasons for one or the other enharmonic spelling), the really weird thing is
the combination with a cancelling natural sign even after (!) the
accidental.
The D-sharp marked in red cancels out the D-flat of the general key
signature, but, most interestingly, the cancelling natural sign has been
placed after the sharp, directly in front of the notehead.
This really is a bit queer!
I've seen naturals precede accidentals, but never the other way round.

Isn't that peculiar?

Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: an "odd" accidental problem...

[Torsten Hämmerle]

B~M wrote
> It appeared in the "Fantasy Etudes for
> Viola" written by
> Lillian Fuchs who was a significant contributor to Viola in the USA.


Hi Paul,

Thanks for this background information.
Lillian Fuchs' expertise is beyond all possible doubt, and I apologize for
suspecting ignorance. 
Moreover, her 16 Fantasy Etudes have been published by a renowned company,
and so this strange orthography may be well-founded.
It'd be interesting to learn about her motives, but, unfortunately, she
can't answer anymore.

All the best,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: tie direction !?

[Torsten Hämmerle]

David Kastrup wrote
> Can be a memory-order thing.  When two things compare equal, their final
> order of decisions can depend just on which choice happened to get a
> location lower in memory.  In that case, the results need not even be
> deterministic given identical scores on the same platform with the same
> program.

Possibly yes.  On the other hand, this never seem to happen if the exact
same situation is being moved away from Y-offset 0 (the middle line).

I think it'd be favourable in any case to have a well-defined tie direction
in these neutral cases, i.e. pointing away from the neutral stem direction. 
Tie.neutral-direction gives the impression to determine the tie direction in
neutral/undecided cases, but it obviously doesn't.

As Harm said, explicitly setting the tie direction is very unsatisfactory at
least if transposing instruments are concerned.

Isn't that a case for the issue tracker? "Unambiguously respect
Tie.neutral-direction"?

All the best,
Torsten




--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user