Aw: Re: Pseudo-handwritten font

[Torsten Hämmerle]

Hello all,my name is Torsten (Be-3) and I happen to be the author of this little Lilypond Jazz "excursion". ;)And yes, of course I will publish the coding here, albeit not finished, but I shortly before pressing the send button I got a nice blue screen (thank you, windows!) and had to start over again.Included will be fonts (a text font and a "music" font) I had to add a few missing characters...So, hopefully, everything will be ready tonight...Thanks for all the friendly comments, by the way...Until thenTorsten


Gesendet: Dienstag, 12. März 2013 um 11:50 Uhr
Von: "Xavier Scheuer" 
An: "Thomas Morley" 
Cc: "David Kastrup" , lilypond-user@gnu.org
Betreff: Re: Pseudo-handwritten font


On 7 March 2013 21:52, Thomas Morley  wrote:
>
> Earlier this day I informed the Author of it in the DLF (the german
> LilyPond-Forum).
> He answered already, reporting having made a lot of improvements and
> posting a new image.
> Though, no code, perhaps he will post the code here or in DLF, don't know.

Hi,

Apparently people are very interested by this pseudo-handwritten font
(here on the international mailing list, but French-speaking users
also repeatedly manifest their interest on lilypond-user-fr, and I
guess it is the same for German-speakers).

Thomas (Harm), since you speak German and already got in touch with
the author, could you  (well, or someone else) ask him if he will
eventually release the code of this font?  And preferably using a
free/libre license (like GPL or OFL)?

If so, we could safely add a feature request to support this
"game changer of strategic importance" in future lilypond releases.

It would be great to have a "music-font" property for each grob
(including each individual Script), to allow people to mix Feta,
Gonville and (if so) this pseudo-handwritten music font in one same
score.

Cheers,
Xavier

-- 
Xavier Scheuer 

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




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

Aw: Re: Re: Pseudo-handwritten font

[Torsten Hämmerle]

Hi Werner,> What do you mean with `rigid'?
Some things related to Feta/Emmentaler access are still being handled deep inside non-public scheme coding or even C source code and consequently very hard to tweak.Amongst the most "stubborn" stencils are multi measure rests where the glyph names are assembled in the C code by concatenating strings. These things are very hard to manipulate from "outside".Another example: It's easy to change the font used for ChordNames, but the accidentals will be Feta accidentals and there is no straight-forward way to replace them by anything else.That's what I meant by "rigid".> It's not necessary to use Metafont at all!  However, > you currently
rely on the glyph metrics from feta > (at least partially), but you use
different glyphs.  > To be really independent you have to add `LILC',
> `LILF', and `LILY' tables to the font.  > I can imagine that it is not
too complicated to > write corresponding scripts for FontForge.

Ah, great, thanks, I wasn't sure about that and, frankly, I don't even know the format/contents of these lookup tables, let alone how to coerce FontForge to have them embedded into the font...> I vote for adding the stuff as-is since it is very non-intrusive, > and
better LilyPond integration can be a future project.Yes, just let's look how far we can get using this non-destructive method... :)I'm just happy that in the meantime some "main actors" as David or even Jan seem to acknowledge the fact that Lilypond would certainly benefit from being able to produce "jazz output".Take care,Torsten

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

Aw: Re: Re: Pseudo-handwritten font

[Torsten Hämmerle]

Gesendet: Donnerstag, 14. März 2013 um 11:53 Uhr
Von: "David Kastrup" 
> I think what we want to arrive at is a way to drop in music fonts into
> LilyPond in a tolerable workable way.  I think that we can't avoid at> 
first the necessity of having the font, if not its glyphs, at least its> 
metrics and letter names, tailored to LilyPond. Yes. I absolutely agree. Example: in contrast to the fonts used by Finale, Sibelus et al. in LilyJAZZ there are distinctive Flag characters ranging from quavers to hemidemisemiquavers just like in Feta, whereas Finale tend to bulild them up from parts, as it looks like.> A second stage might> 
likely include putting a Scheme layer in between that can serve LilyPond> 
with the impression of a virtual font, but I think that a viable> 
starting point would likely be a font with a specific layout.Great!> 
The Jazz fonts serve a different purpose than Gonville: Gonville is> 
intended as a wholesale replacement of LilyPond's fonts, made with a> 
somewhat different set of design choices.  The Jazz fonts, in contrast,> 
are for a different style of use.  For this reason, Gonville inclusion> 
centered on the question "how do I get an installation where the default> 
LilyPond fonts have been replaced by Gonville?".
> > 
We can't do that with the Jazz fonts.  While there will be users who
> don't use anything else, we will also have users who need both styles.

We can't do that and we *mustn't* do that, because a traditional font (Feta/Gonville) surely has to remain the default font in *any* lilypond installation. While a jazz font may look great in specific applications such as lead sheets, it's certainly a bad choice for, say, complex piano music.Thanks and all the best,Torsten

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




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

Aw: Re: Re: Re: Pseudo-handwritten font

[Torsten Hämmerle]

Gesendet: Donnerstag, 14. März 2013 um 14:59 Uhr
Von: "David Kastrup" It's not "just" Jazz.  This is pretty much par for the course for
Barbershop and quite a few other forms of vocal harmony.

Interestingly, not for pop music.  I also don't think it is used much
for piano or other vertically dense forms of music.  So it might even
make sense to be able to change style on a per-staff basis.
Hi David,The current implementation using \jazzOn \jazzOff takes this into account. Perhaps it would be a good idea to define something like a \JazzStaff context in analogy to \VaticanaStaff and the like.I could imagine, just as an example, to compare the original arrangement of Victor Herbert's "Indian Summer" (in traditional font) to the simplified/modernized Real Book line and chords in "jazz font" one stave above...By the way, the possibility to change styles resp. to have both styles in one document was one of the reasons to keep it all separate/non-destructive rather than globally replacing the standard internal font.Best,Torsten

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

Aw: Re: grace note stem lengths

[Torsten Hämmerle]

Hi Kevin,Apart from changing the Stem length-fraction (either by scheme commands or an accustomed \override), as soon as beams come into play, the beams, i. e. their positions and slopes will determine the stem lengths. That's why it's no use trying to override the Stem #'length.So, if anything else fails, as a last resort, there's always the possibilty to set the Beam #'position manually - this does apply to both grace notes and "ordinary" ones.Or, as Bill Shakespeare would have said: "It was the Beame, and not the Stemme."  ;)Slán,Torsten


Gesendet: Donnerstag, 14. März 2013 um 17:25 Uhr
Von: "Pierre Perol-Schneider" 
An: "Kevin Barry" 
Cc: lilypond-user@gnu.org
Betreff: Re: grace note stem lengths


Hi Kevin,Try this :\new Staff {    $(add-grace-property 'Voice 'Stem 'length-fraction '2)	
    \new Voice {	\relative a' {		s  a32 \afterGrace a { b32[ g] } a8
	}     }}
2013/3/14 Kevin Barry 
Dear LilyPond users,

Occasionally I find the stem lengths of grace notes to be too long, as in the following example, where the grace 32s have longer stems than the normal ones (because of the slope I think):

\version "2.16.2"

\relative a' {
  s  a32 \afterGrace a { b32[ g] } a8
}

I have tried to alter them with various overrides, including
\override Stem #'(details beamed-lengths) = #'(2)
but they mostly have no effect.  Only
\override Stem #'length-fraction = #0.5
sometimes works for reasons I don't really understand (the behaviour of this property seems unpredictable - different values have odd effects) I gather it's not for this purpose, but I was just trying everything I could find in the internals manual. Could anyone shed some light?


Kevin


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





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

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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

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: 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

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]

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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]

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: 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: 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,

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: 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: 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: 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
> 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
> 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]

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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]

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: Left-handed fretboard?

[Torsten Hämmerle]

Hi all,

In the more recent developer versions, threre's a surprisingly simple way to
reverse the order of strings:
just set the string-distance to #-1. ;)
This doesn't work in 2.18.2, though.


\version "2.19.80"

\include "predefined-guitar-fretboards.ly"

<<
  \new FretBoards {
\chordmode {
  c1
  \override FretBoard.fret-diagram-details.string-distance = #-1
  c1
}
  }
>>


 

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: Left-handed fretboard?

[Torsten Hämmerle]

Ooops, in the image, the #-2 should be a #-1, of course, because #-2 would
have doubled the string distance...

Sorry,
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: Left-handed fretboard?

[Torsten Hämmerle]

Thomas Morley-2 wrote
> commit 3ea80e17452cb1e99aa4b7ff77b0ae2f5293b50d
> Author: Thomas Morley <

> thomasmorley65@

> >
> Date:   Sat Dec 31 12:33:24 2016 +
> 
> Let the distance of strings and frets in fret-diagrams be settable
> 
> Issue 5025


That's funny, indeed,

Thanks for the hint! I wasn't even aware of the fact that the
string-distances property is relatively new. 
It was just a straight forward attempt and it's common practice to create
mirrored images by applying a negative scale factor.

I bet the possibility of using negative distances was not part of the
original design... :)
As the diagrams are being centered, there should be no side effects.

Once again a most valuable and ever fruitful LilyPond enhancement brought to
you by Harm's 1001 megabytes of scheme code...! :D

Slán go fóill
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: Left-handed fretboard?

[Torsten Hämmerle]

Indeed, Karlin,

you are perfectly right - thanks for the observation! 
This is definitely not a Windows problem, it's an unwanted side effect of
using negative string distances:
The total width (5 times the string distance on a 6 string instrument) has
to be increased by the half the line thickness on either side in order to
neatly align.

In our mirrored case, the (negative!) line thickness is added, i.e. the line
thickness is actually being subtracted (!), so that the horizontal bar (the
"nut") aligns with the inner margins of the "strings" rather than the outer
margins.

If we want to deliberately and officially use the negative string distance
hack, we could adapt the width calculation by just adding the *absolute
value of the string thickness* (thus ignoring the sign of string-distance) -
that'll do the trick.

Nighty-night
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: Left-handed fretboard?

[Torsten Hämmerle]

I've now created a new issue, encouraged by DAK's assent: 
#5264 Left-handed fret-diagram nut alignment
  

@Harm: If you're busy, I could well take over this task.
I'm just getting acquainted with the git/issue/review process, so such
simple tasks come in handy.

Cheerio,
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: Left-handed fretboard?

[Torsten Hämmerle]

Ah, yes, when in landscape mode, setting a negative string-distance makes the
whole diagram flip below the baseline.

Oh dear, another effect (in general):
capo numbers and other objects that should be placed in the margin of the
diagram.
When setting a negative string-distance, they flip inside the diagram.

Probably we should extend issue 5264 to all negative string-number problems.

Cheerio,
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: Left-handed fretboard?

[Torsten Hämmerle]

Thomas Morley-2 wrote
> Meanwhile I think supporting negative string-distance is a bad idea,
> because too many detail-problems need adjustments. And using negative
> string-distance was not intended as I introduced it. I should have
> always gone for (abs ...). But this could be corrected...

Well, at least there are far more mean little details to be observed than I
had expected, so it won't make much difference implementing a "proper"
solution using an appropriate sub property.

When driving through "Friederieke" today, I was thinking of (abs ...), too,
but on the other hand - please don't beat me - give it a try and see what
happens if you *set StaffSymbol.staff-space to #-1*. 

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: Sessions with Frescobaldi 3.0

[Torsten Hämmerle]

Hi Joei,

I habe just played around with the Sessions feature (Windows 10 64bit,
Frescobaldi 3.0.0).
No problems there at first glance.

*That's what I did:*
(1) Set the "Start with last used session" in Edit > Preferences
(2) Create a session containing two lilypond files (I don't use sessions at
the moment)
(3) Quit Frescobaldi
...
(4) Open Frescobaldi again - and voilà - all documents of the last sessions
have been automatically opened and even syntax highlighting works as
expected.

This only works if there is an active session set in the Session menu.
When "No Session" has been selected, no session will be opened during the
Frescobaldi start up process, of course.

Cheerio,
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: Long syllable vs. span bar

[Torsten Hämmerle]

Hi Simon,

Probably the easiest way to achieve this is just to use *ChoirStaff* and add
the Span_bar_engraver to get the bar lines.
That way, Lyrics will nonchalantly cross the bar lines as if they weren't
there and by setting the whiteout property, you're there.

I've just adapted your original coding to your needs:

\version "2.19.80" 

\paper { 
   line-width = 110 
   indent = 0 
} 

\score { 
   \new ChoirStaff \with { \consists "Span_bar_engraver" } << 
 { 4 4 4 4~ 4 8 8 4 4~ 4 8 8 2 } 
 \addlyrics { 
   \override LyricText.whiteout = ##t
   a ver -- y looong __ syl -- la -- ble, 
   looong __ syl -- la -- ble 
 } 
 { 1 1 1 } 
   >> 
} 


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: Transcriber title

[Torsten Hämmerle]

Hi Álvaro,

In the very likely case that you're using custom title markup anyway, I'd
like to mention the possibility of simply adding any desired non-standard
header variable to the \header section:

\header {
  transcriber = "Álvaro Cáceres Muñoz"
}

...and retrieving it later in your custom
bookTitleMarkup/scoreTitleMarkup/evenHeaderMarkup etc. exactly like any
other standard \header variable:

\fromproperty #'header:transcriber

On custom title markup, please refer to:
3.2.2 Custom titles headers and footers

  

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: Fwd: Re: turning a blind eye to dotted note

[Torsten Hämmerle]

Hi Bernhard,

a cadenza is rhythmically free, no checks, no limits, no rules. So a
combination of \cadenzaOn and | doesn't make any sense.

Apart from this - in addition to all the other replies - I'd like to point
out that LilyPond's behaviour (allow note durations to stretch out into the
next bar) is one of the big advantages compared to much more rigid software
(Finale, Sibelius, ...).

This tine example shows a tuplet /deliberately/ crossing a barline:

Try to achieve this with any other software (I'm not sure about Dorico,
though) and you'll see that a lot of tricky tweaking and fiddling is needed
to get it done. 

tuplet-spanning-barline.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: Fwd: Re: turning a blind eye to dotted note

[Torsten Hämmerle]

David Kastrup wrote
> Seriously?  It's pretty much standard fare [...]

Yes, David, no kidding!
I couldn't believe it either...
Incidentally, a few months ago someone asked me whether I knew how to do
this in MuseScore.
My first thought was: well, MuseScore is a non-commercial, non-professional
software, but Finale and Sibelius should be able to handle this with ease -
but, apparently, no, they can't!

Curiosity was awoken, but all I could find was a couple of threads that
clearly stated that both Finale and Sibelius need a lot of trickery
(changing metre and hiding it, manually moving noteheads to their proper x
position etc.)

Dorico, by the way, is a laudable exception, just checked it.

Cheerio,
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: Force top-system-spacing to be absolute

[Torsten Hämmerle]

Urs Liska-3 wrote
> What is the correct way to force the first system to be at an absolute 
> position on the staff, i.e. in the example the center line exactly 16 
> staff spaces below the page border?

Hi Urs,

I may be mistaken, but a minimum-distance of 0 seems to be the cause (event
with stretchability 0).

If you set *minimum-distance to 16*, too, then this distance will actually
be kept even under very tense conditions (tested with your example).

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: aligning lyrics to hidden notes

[Torsten Hämmerle]

Hi Sandro,

Indeed, Phil's query regarding your LilyPond version is the pivotal
question. For two reasons:

First reason
NullVoice has been introduced in Version 2.18 (as far as I know)

Second reason
Current development version 2.19.80 (and before) won't have the problem


Stripping down your case to a minimal example makes it clear what you want
to achieve:

%%%
\version "2.18.2"

mel = \relative { c4 c 'g g }
bas = \relative { \clef bass c4 r c r f^"End of NullVoice" r c r }

\score {
  \new Staff <<
\new Voice \bas
\new NullVoice \mel 
  >>
}
%%%

Print out the bass part while still keeping the lyrics (for orientation or
whatever reasons).
You're using NullVoice in order to get the lyrics aligned to the (invisible)
melody.

I've omitted the lyrics because the combination of "normal" Voice and
NullVoice is all we need to see the effect - NullVoice seems to push down
all the rests as if there was polyphony.
In my simple example, you can see that the stem direction flips, i. e. the
notes themselves behave as they should (\oneVoice), whereas the rests drop
down as if in \voiceTwo.

In bar 2, NullVoice stops and - lo and behold - the rests are back in
place... Strange...

I'd call it a bug, but there has been some recent work on NullVoice and
meanwhile, in 2.19.80 (and before), everything seems to be OK.

NullVoice-rests-2-18-2.png
  
Strange NullVoice effect on rest position in 2.18.2

In 2.18.2, you can set \override Rest.staff-position = #0 to force the rests
back, or use a development version.

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: turning a blind eye to dotted note

[Torsten Hämmerle]

BB-3 wrote
> Sorry, needed some time to realize that I expect to much from lilypond 
> to check automatically set bar lines and such "impossible cases" of 
> 17/16 itself.

That's exactly the point: but it isn't a case of "17/16", it's just a case
of a quaver note starting at 16/16 (the notehead starts in the correct bar).
The only "uncommon" thing is that it reaches out into the next bar.

LilyPond's barline isn't "wrong", either: it's excalty where it should be
and even the follow-up note will be placed a wee bit further away from the
bar line so that everything will neatly align with other voices.

Situations like my tuplet example (even with tuplet bracket/beam crossing a
barline) can be found in Chopin's works among others, *so notes stretching
over barlines are, albeit rare, absolutely possible* and not necessarily a
"mistake".

Apart from this: I may not want any auto correction feature to automatically
remove the "erroneous" k in Handel's "Musick for the Royal Fireworks", for
that's the way it was actually written back in the days... :) 

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: Pitch inflection

[Torsten Hämmerle]

Hi Michael,

It probably would have been helpful if you had provided an example (so that
we can see how exactly the arrows are supposed to look like).

But in the end all boils down to the possibility of replacing a standard
accidental by an arbitrary markup. There's a snippet demonstrating how this
can be done:
Snippet: Customized accidentals   

You may simply use one of the Unicode arrows, LilyPond graphic markup,
PostScript code -- whatever you like.

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: Rhytm problem

[Torsten Hämmerle]

Ondokuz Mayıs Üniversitesi Devlet Konservatuvarı wrote
> Is it possible to open the gap between the measurement figures and the
> first note?

Merhaba Emre,

First let me state that I consider using lyrics the best compromise when
trying to achieve a half-way rhythmically consistent spacing in combination
with rather long syllables ("Düüm").
I'd even use a smaller font size and/or a condensed font, eventually.
In my example coding below, 
*\override LyricText.font-size = #-2*
doesn't obscure the natural spacing anymore. 

The gap between time signature and first note can be set as follows:
*\override Staff.TimeSignature.space-alist.first-note = #'(fixed-space . 4)*

A complete list of all the internal properties of TimeSignature can be found
here:
3.1.126 TimeSignature
  

Using the reduced font-size, the default gap (2) isn't too bad, though.


By the way: 

\relative c' { ... } doesn't make any sense in a \RhythmicStaff.

\startStaff is completely unnecessary

You can use the short forms \stemUp, \stemDown, \stemNeutral instead of
\override Stem.direction = #...

\override Staff.Clef #'stencil = ##f has no effect, either.

Based on your laste example, you'll get

%%%
<<
  \new RhythmicStaff {
\numericTimeSignature
\override Staff.TimeSignature.space-alist.first-note = #'(fixed-space .
4)
\time 4/4
c2 c4 \stemDown c4
  }
  \addlyrics {
Düüm Te Ke
  }
>>
%%%

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: Rhytm problem

[Torsten Hämmerle]

Ondokuz Mayıs Üniversitesi Devlet Konservatuvarı wrote
> Is there any clef for percussion note?

Yes, there is. 
\clef percussion
or
\clef varpercussion
are two common clefs used for percussion staves.

*Caveat:* By default \RhythmicStaff will not print any clef by default,
because a non-pitched single-line stave does not need a clef.
So, if you want to print a clef symbol, you'll have to include the
Clef_engraver:


 <<
 \new RhythmicStaff \with { \consists "Clef_engraver" }
 {
 {
 \clef percussion
 \numericTimeSignature
 \time 4/4
   c2 c4 \stemDown c4
 }
 }
 \addlyrics {
   \override LyricText.font-size = #-2
 Düüm Te Ke
 }
 >>


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: Rhytm problem

[Torsten Hämmerle]

Ondokuz Mayıs Üniversitesi Devlet Konservatuvarı wrote
> But I want to use
> 
> \clef varpercussion
> 
> When I add this line it turns to Clef G. How can I use Clef varpercussion?

Ooops,

Sorry, the varpercussion clef is fairly new and only available from 2.19
onwards.

That's, by the way, one of the reasons why you should always state the
LilyPondversion you're using.
I'm using the current development version in most cases and so I wasn't
aware of the fact that varpercussion didn't exist yet in prior versions.






--
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: Gis major key signature; Lily's key signature algorithm

[Torsten Hämmerle]

Hi Richard,

That's an interesting question, indeed...



Richard M wrote
> Why does LilyPond notate it one way, [...]

LilyPond uses a list keyAlterationOrder containing the order of alterations
printed.

It is defined as follows in engraver-init.ly:

  keyAlterationOrder = #`(
(6 . ,FLAT) (2  . ,FLAT) (5 . ,FLAT ) (1  . ,FLAT) (4  . ,FLAT) (0  .
,FLAT) (3  . ,FLAT)
(3 . ,SHARP) (0 . ,SHARP) (4 . ,SHARP) (1 . ,SHARP) (5 . ,SHARP) (2 .
,SHARP) (6 . ,SHARP)
(6 . ,DOUBLE-FLAT) (2 . ,DOUBLE-FLAT) (5 . ,DOUBLE-FLAT ) (1 .
,DOUBLE-FLAT) (4 . ,DOUBLE-FLAT) (0 . ,DOUBLE-FLAT) (3 . ,DOUBLE-FLAT)
(3  . ,DOUBLE-SHARP) (0 . ,DOUBLE-SHARP) (4 . ,DOUBLE-SHARP) (1 .
,DOUBLE-SHARP) (5 . ,DOUBLE-SHARP) (2 . ,DOUBLE-SHARP) (6 . ,DOUBLE-SHARP)
  )

(sorry for the bad formatting).

the numbers range from 0 to 6 with 0 = C ... 6 = B

translated into pitches, that will be
   Bb Eb Ab Db Gb Cb Fb
   F# C# G# D# A# E# B#
   Bbb Ebb Abb Dbb Gbb Cbb Fbb
   F## C## G## D## A## E## B##


That's why F## will be printed last.



Richard M wrote
> [...] and I'm wondering if there's an official source that determines how
> they are to be notated.

As to the "official" order of accidentals, Elaine Gould writes: "The order
of accidentals follows the 'cycle of fifths'."

This, unfortunately, is not very clear for the "theoretical keys" containing
double flats or double sharps.

*1st interpretation* (LilyPond's behaviour)
As the F## in G# major is the last accidental in the circle of fifths, so
it's printed last.

*2nd interpretation*
While the F## may be the last accidental, it's nevertheless replacing the F#
(the first sharp) and therefore should be printed first.

By the way, switching languages in Wikipedia, simple English or Polish will
show LilyPond's order. ;)

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: Tromba "mo"

[Torsten Hämmerle]

Just out of curiosity - shouldn't it be "tromba prim*a*/second*a*" in Italian
(1ma/2da)?
I'd be interested in the link, too.

Or is it a case of "modo russico" ;)

Cheerio,
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: \RemoveAllEmptyStaves and Dyanmics context line for piano pedals

[Torsten Hämmerle]

Hi Andrew,

The difference between \RemoveEmptyStaves and \RemoveAllEmptyStaves is that
\RemoveEmptyStaves will not remove empty staves in the first system, the
reason for it being that in orchestral scores it is common to display all
instruments involved in the first system - no matter if they play or not.

Your problem is caused by the fact that, from LilyPond's point of view,
staves containing "no music", i.e. rests or spacer rests only, are
considered as "empty". Therefore, dynamics will also vanish using
\RemoveEmtpyStaves.

The difference between PianoStaff and GrandStaff, by the way, is that
PianoStaff uses the "Keep_alive_together_engraver". This has the effect (in
orchestral scores) that both piano staves are shown as soon as one of them
contains music.

Solution to your problem:
Just use GrandStaff (without "Keep_alive_together") and apply
\RemoveAllEmptyStaves to the Staff lines only but *not* for the dynomics
line:

~~~
\version "2.18.2"

\score {
  \new GrandStaff <<
<<
  \new Staff { \repeat unfold 4 { b'1 } \break \repeat unfold 4 { b'1 }
\break \repeat unfold 4 { b'1 } }
  \new Dynamics { s1*2 s1*3\p\< s1*2\f s1*2\> s1\pp }
>>
\new Staff { R1*10 b1 b1 }
  >>
  \layout {
\context {
  \Staff
  \RemoveEmptyStaves
  \override VerticalAxisGroup.remove-first = ##t
}
  }
}

That way, the \new Dynamics line will not be removed and GrandStaff instead
of PianoStaff saves you from the Keep_alive_together engraver.
I didn't use \RemoveAllEmptyStaves here because it didn't exist back in
2.18.2

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: make all sharp signs and flat signs visible within one measure

[Torsten Hämmerle]

Hi Gert,

You can set the \accidentalStyle to "forget": 

~~+
\version "2.18.2"
\relative { \accidentalStyle forget bes'4 bes bes bes }

Does this solve your problem?

Groeten,
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: Automatic vertical spacing when *some* values are fixed

[Torsten Hämmerle]

Hi Urs,

With the top and bottom fixed, the only flexibility left lies in varying the
distances between systems and staves.
Unfortunately, the system-system-spacing has a default minimum distance of 8
(between the systems) and squeezing three systems into one page seems to be
better than stretching them too far apart.

I'd play around with system-system-spacing.minimum-distance.

1st attempt: When setting minimum-distance to 11, thus forcing a wider
distance between systems, LilyPond still complains about compressing (and
it's even worse).
Now, there is much more compression within the stave groups. No, that's not
good, either...

Even pushing up system-system-spacing.minimum-distance to 12 still squeezes
three systems on page 1, but only two on page 2 (because of the p standing
out in the last line).
That's just (!) because of the p in Vc bar 14., one might say.
So a tiny difference in hairpins, stems, ... makes a huge difference in the
resulting layout (three systems or two systems per page).
This looks awful and very unbalanced. But there's nothing in between: it's
either two or three systems per page.

Setting system-system-spacing.minimum-distance to 13, finally pushes the
systems so far apart that only two systems (but consistently at last) fit on
one page.

Doesn't look too good, either... No, none of the solutions really works.


*The actual problem*
The space available on the page does not at all go well with the system size
for a string quartet.
Just reduce the stave size and everything will fit neatly...

Sometimes, I just use one of the system-count, systems-per-page,
min-systems-per-page oder max-systems-per-page paper variables to achieve a
uniform number of systems on all pages.

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: OT: typewriter LaTeX package

[Torsten Hämmerle]

Hugh Myers wrote
> I had a good deal of correspondence with folks across the pond and never
> thought twice about the double space post-sentence.

Your're certainly right, but I strongly suspect that all this correspondence
was in English.

Let me assure you that Urs is right: in Germany, without any doubt, there is
no double space.
And, as you surely know, we Germans are famous for our over-regulation:
There even is a common DIN (German Institute for Standardization) standard:

DIN 5008 Regeln für Maschinenschreiben (Typewriting standards)

It says that there is only ONE space after punctuation marks according to
German standards.
The Duden, a kind of German Bible of orthography containing the official
rules, traditionally contains a chapter about typewriting---stating there is
one space only after the end of a sentence.

The same holds true for France, too, by the way (hence the term "French
spacing").


Finally Associated Press Stylebook (!): "Use a single space after a period
at the end of a sentence."



Quintessence:
There are far more languages than American English in the world and,
consequently, there has always been a certain variety of typographic
conventions.


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: OT: typewriter LaTeX package

[Torsten Hämmerle]

mskala wrote
> All present tense... there's no doubt that the narrow space is more common
> *today*, but typewritten documents in the typewriter era (which ended in
> roughly the 1980s) are not necessarily the same story.

Sorry, I forgot to mention that DIN 5008 dates back to 1928.
My mother, who has been professionally trained in the 1950s, confirmed that
using one space only was common German practice in the golden typewriter era
and this was officially taught.

Schmidt.jpg   

Please find attached an original letter from (1978, *not* today). It's an
official letter by German chancellor Helmut Schmidt, so you can bet on it
that the typist was top-notch. I've marked the one-space gaps between
sentences in red.

Cheerio,
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: Positioning graphic markup inside staff

[Torsten Hämmerle]

Hi delboh,

By design, an outside-staff object is not supposed to be placed inside the
staff. That's the simple reason why setting Y-offset doesn't help---an
outside-staff object just can't cross the border into the stave.

*Remedy:*
An outside-staff object can be made "inside-staff" by setting
outside-staff-priority = ##f.

In this case, with  
\override TextScript.outside-staff-priority = ##f
you may even set X-offset to any value inside the staff and the TextScript
will be placed there as desired.

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: Positioning graphic markup inside staff

[Torsten Hämmerle]

Torsten Hämmerle wrote
> you may even set X-offset to any value inside the staff and the TextScript
> will be placed there as desired.

Addenda et corrigenda
Sorry, I meant Y-offset, of course...




--
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: Why do lyric extenders require an associated voice?

[Torsten Hämmerle]

Hi,

As soon as associatedVoice has been set to /anything/, LilyPond will pick
the next best voice it can find.

The actual value assigned to associatedVoice is only important if there are
multiple voices present to choose from.
Let me illustrate that with an amended example taken from the documentation:

~~~
\version "2.18.2"

\score {
  <<
\new Staff <<
  \new Voice = "melodyOne" {
\relative {
  \voiceOne
  a'4 a a a
  \repeat volta 2 { b4 b b b( | c b a b) }
}
  }
  \new Voice = "melodyTwo" {
\relative {
  \voiceTwo
  a'4 a a a
  \repeat volta 2 { b4 b b b( | c b2.) }
}
  }
>>
\new Lyrics \lyricsto "melodyOne" {
  Not re -- peat -- ed.
  <<
{ The first time words. __ }
\new Lyrics {
  \set associatedVoice = "bogus"
  Sec -- ond time words.  __
}
\new Lyrics {
  \set associatedVoice = "melodyTwo"
  The third time words.  __
}
  >>
}
  >>
}

As you can see, the "Second time words" align with melodyOne (the first to
come in case of bogus assignment), but "The third time words" align with
melodyTwo.

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: Why do lyric extenders require an associated voice?

[Torsten Hämmerle]

It's not only about extenders, it's about aligning lyrics to a melody in
general.
Moreover, the associatedVoice property can be used to switch voice
assignment etc.

The difference between setting associatedVoice to a nonexistent voice and
setting it to ##f (resp. not setting it at all) is that in case of ##f, the
lyrics won't be aligned to /any/ melody and you'll have to explicitly
specify durations.

All in all, it's the difference between using \lyricsto "..." and not using
\lyricsto "...", like in
\lyricmode { Not4 a -- ligned to a mel2 -- o -- dy }

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 name e2:m7(b5)/d

[Torsten Hämmerle]

Hi Ming and Robert,

While e:min7.5-/d is the correct LilyPond coding for of the chord in
question, the standard output still does not match Ming's specification.

*"Problem"*
(leaving away the /D, just looking at the main chord here)
A minor seventh chord with diminished 5th is nothing else but a
half-diminished seventh chord. 
In this case, LilyPond's standard output will produce an Eø.
Writing Em7(b5) is just an alternative that can't be achieved without
altering LilyPond's standards.

For this very likely reason, one may specify chord-exceptions to adapt the
output to personal taste as described in  Chord Name Exceptions

 
.

The notes contained in the "template chord" always refer to tonic C, so
we'll have to specify the notes of a Cm7(b5) in LilyPond's native (Dutch)
language:
.
As demonstrated in the link, you may specify an arbitrary markup, in this
case something like

~~~
 chExceptionMusic = {
   1-\markup {  m\super \concat { 7 (\teeny\raise #.3 \flat
5) } }
 }

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: Advice on glyph construction

[Torsten Hämmerle]

Hi Andrew,

It's quite annoying that the Unicode characters differ in size and bounding
box (surprisingly, there is no matching circle among the Geometric Shapes
U+25A0 to U+25FF)...


Andrew Bernard wrote
> [...] but I can't figure out how to get the rightmost Unicode glyph to sit
> further down [...]

That's easy: you'll have to set 
TextSpanner.bound-details.right.stencil-align-dir-y = #CENTER
(in your example, only the left align dir has been set to center, that's why
the right text still sits on its baseline).

Having that done, the circles still don't align properly, because they are
slightly different in size and the empty circle has a wider bounding-box
(that's why there is a little gap between the arrow and the circle).

I often use the \box command with zero box-padding to actually see the
bounding boxes, e.g.
\markup \concat \override #'(box-padding . 0) \box { \char ##x25D0 \char
##x20DD }





Andrew Bernard wrote
> [...], and then I also need arrows off to the right of this glyph
> from time to time.

Unfortunately, the line-spanner uses a custom arrow head
(Line_interface::make_arrow) that strongly differs from the standard
\arrow-head markups.
It can be mimicked by using a rotated and scaled triangle, though.

All in all, I've set up two simple \markup definitions (adjusting bounding
box and size of the circles and adding an artificial markup arrow.
It's not a proper solution (manual tweaking involved and with another font,
Unicode characters may behave completely different), but, well, it's a
simple solution using nothing but run-of-the-mill markup:

~~~
\version "2.19.81"

halfCircle = \markup { \hspace #.21 \char ##x25D0 \hspace #0.21 }
emptyCircleArrow = \markup \concat { \lower #.27 \scale #'(1.075 . 1.075)
\char ##x20DD 
 \hspace #0.2
 \rotate #-90 \lower #0.03 \scale
#'(0.38 . 0.6) \triangle ##t }

 {
  \override TextSpanner.style = #'line
  \override TextSpanner.bound-details.left.stencil-align-dir-y = #CENTER
  \override TextSpanner.bound-details.left.text = \markup \halfCircle
  \override TextSpanner.bound-details.right.stencil-align-dir-y = #CENTER
  \override TextSpanner.bound-details.right.text = \markup \emptyCircleArrow
  \override TextSpanner.bound-details.right.arrow = ##t
  c'4\startTextSpan
  c' c' c' |
  c' c' c' c'\stopTextSpan |
}

circle-markup.png
  


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: Force Lilypond to preserve vertical order of TextScripts?

[Torsten Hämmerle]

How about script-priority?

I always thought that concurrent (Text)Scripts will be internally numbered
by counting up script-priority in the order given and the first
(Text)Scripts will be printed closest to the noteheads (depending on whether
the scripts are above or below the stave).

So, even all have the same outside-staff-priority, their order can still be
manipulated by using script-priority, that's what script-priority has been
designed for.

Or did I get something wrong?

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: Force Lilypond to preserve vertical order of TextScripts?

[Torsten Hämmerle]

Hi Joram,

TextScript.script-priority has a default value of 200.
Each concurrent TextScript will be counted up (starting with 200+0 = 200,
200+1 = 201, 200+2 = 202, etc.) by default.
The smaller the number, the closer to the notehead.

So, by default, LilyPond will keep the order of TextScripts intact and I'm
really wondering what happened in your original non-working example...

*Caveat:*
Your first \tweak may be dangerous, because LilyPond will automatically
count up the value of script-priority, i.e. when saying
{ a-\tweak script-priority #201 -"one" -"two" }
then both "one" and "two" will have the same script-priority value 201 and
anything could happen.

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: Force Lilypond to preserve vertical order of TextScripts?

[Torsten Hämmerle]

Hi Kieren,

Sometimes, the order of stacks /is/ important and you even can't always put
them together into a \markup column:

Fingering, for example, uses script-priority, too.
This time, it does not depend on any input order, but the script-priority is
calculated from the Y-position of the noteheads in a chord (centre of the
stave means zero offset). The order of entry doesn't matter, but the order
of fingering numbers has to be the exact same order as the (graphical) order
of noteheads in a chord.

It's the same mechanism, though.
And a lot has to happen before LilyPond starts messing with that
well-defined order. At least that's what I always thought up to now... (?)

Cheerio,
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: Disable extra space around StaffGroup?

[Torsten Hämmerle]

Nathan Sprangers wrote
> If it helps, my interest is in creating band scores, which usually place
> an
> extra bracket or brace around certain families (such as the clarinets,
> cornets, etc in Holst's First Suite for Military Band
> ),
> but there is typically no extra space around these staff groups.


Hi Nathan,

Concerning the spacing "around" staff-groups:
By default, LilyPond tries to keep staff-groups closer together in general.
When stretching has to be applied this becomes particularly obvious.

As in Holst's example (Military Band, i.e. Wind Band), it is common to have
uniform vertical spacing just ignoring groups or sub-groups.

This can be achieved fairly easy:
By setting VerticalAxisGroup.staff-staff-spacing of \Staff (a single
stand-alone stave, the lowest level in grouping hierarchy) to the values
found in the staff-grouper (in my example, I've used the default values).

\layout {
  \context {
\Staff
\override VerticalAxisGroup.staff-staff-spacing =
  #'((bavsic-distance . 9) 
(minimum-distance . 7) 
(padding . 1) 
(stretchability . 5))
  }
}

If set, these values will be automatically used even within different groups
in the hierarchy.
Background: VerticalAxisGroup.staff-staff-spacing is *not* specified by
default and do by default, the spacing values will be "inherited" depending
on the level of hierarchy.


To demonstrate this, I've chosen a very small global-staff-size and
deliberately forced stretching. Using Acrobat Reader's measuring feature,
I've marked the gaps between the staves (see attached PDF).

*Default vertical spacing* - vertical spacing between groups differs
depending on grouping level.
test-uniform-vertical-spacing-default.pdf

  

*Uniform vertical spacing* by explicitly setting
Staff.VerticalAxisGroup.staff-staff-spacing
test-uniform-vertical-spacing-proof.pdf

  

In the second example, applying the layout changes just on in the \Staff
context, there is absolutely the same vertical distance between all staves,
ignoring any grouping.

Cheerio,
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: Inserting a verical space, or an empty line, between two markups attached to a note.

[Torsten Hämmerle]

Hi Robert,

The main problem is the baseline-skip within the columns, i.e. the lines of
text are too far apart from each other.
If the default skip is too wide, inserting positive \vspace can only make it
worse (by the way, it's also possible to insert negative \vspace).

The "proper" and most natural way, however, is to adjust the baseline-skip
at will:

Each \column (or \center-column) has a property called baseline-skip that
can be altered by overriding its default value. I've also included two
separate \center-columns and a \line construct in order to be able to shift
the "Rome, Mars 1934" column slightly to the right. Just for demonstration
purposes how these markup "boxes" can be nested and combined.

\version "2.19.81"

\markup {
  \column {
\override #'(baseline-skip . 2.2) \italic \center-column {
  "m. g."
  "dessus"
}
\vspace #0.8
\line {
  \hspace #1.2
  \override #'(baseline-skip . 1.8) \tiny \center-column { 
"Rome"
\bold "Mars 1934"
  }
}
  }
}

mg-dessus.png
  

There are two different baseline-skip values for the two boxes (Rome, Mars
1934 is in smaller type and requires a smaller baseline-skip).

I generally used double qoutes for text because it will be coloured as
verbatim text in my editor and (in this case to prevent "Mars 1934" from
begin split into two lines.

HTH
Torsten

PS: I don't know the original page layout, but probably it would be best to
use tagline for "Rome...", as in Noeck's proposal. But it is always
beneficial to know about baseline-skip, anyway.



--
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: \pralllUp inside Staff

[Torsten Hämmerle]

Ali Cuota wrote
> in BWV 572 (trio Sonate d-minor) 

Ah, I guess you mean BWV 527... ;)



Ali Cuota wrote
> he wants a prallUp (well I understand it this way) inside the staff (see
> picture). I tried with
> the 3 ways I found inside the Notation manual (\raise, \super,
> \dir-column) (version 2.18.2) but none works.

\raise, \super etc. are markup commands.
Moreover, by moving the \prallup (Script) in between the notes, the overall
note spacing is affected (in the other two staves, too, of course).
Therefore, you should try to manipulate the Script positioning.
This is possible by specifying X-offset and Y-offset values, and, in order
to move it away from the preceding notehead, you could even use
extra-spacing-width:

 \version "2.18.2"

 \new PianoStaff <<
   \new Staff \relative {
 \key d \minor
 \time 6/8
 d''8 ~ d32 cis b a e'16 g, g8\prall f
 \once\override Script.Y-offset = #-1.5
 \once\override Script.X-offset = #-3.2
 \once\override Script #'extra-spacing-width = #'(-0.6 . 0)
 as\prallup
   }
   \new Staff \relative {
 \clef bass
 \key d \minor
 \time 6/8
 bes!8 g a d,8. es16 c! d |
   }
 >>

I've set the whole measure and included one other stave to show the correct
rhythmic alignment of the resulting note columns.

prallup-inside.png
  

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: \pralllUp inside Staff

[Torsten Hämmerle]

Hi Francois,

my previous answer probably went amiss, so the 2nd attempt...


Ali Cuota wrote
>  in BWV 572 (trio Sonate d-minor) 

Ah, I guess you mean BWV 527... ;)


Ali Cuota wrote
> he wants a prallUp (well I
> understand it this way) inside the staff (see picture). I tried with
> the 3 ways I found inside the Notation manual (\raise, \super,
> \dir-column) (version 2.18.2) but none works.

\raise and \super are markup commands. 
And,  in this case, by squeezing the prallup below the beam between the
notes, the note spacing will be affected and you should try to set X-offset
and Y-offset of the Script (technically, \prallup is a Script).
In order to move the follow-up notehead a bit further away, you could use
extra-spacing-width.

In my example, I've included the complete measure and added another stave,
just to show the correct rhythmic alignment of the resulting note columns:

 \version "2.18.2"

 \new PianoStaff <<
   \new Staff \relative {
 \key d \minor
 \time 6/8
 d''8 ~ d32 cis b a e'16 g, g8\prall 
 \once\override Script.Y-offset = #-1.5
 \once\override Script.X-offset = #3.2
 \once\override Script.extra-spacing-width = #'(0 . 0.5)
 f\prallup as
   }
   \new Staff \relative {
 \clef bass
 \key d \minor
 \time 6/8
 bes!8 g a d,8. es16 c! d |
   }
 >>

prallup-inside.png
  

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: Function to override the stem direction and flag of a single note?

[Torsten Hämmerle]

Hi Andy, 

You don't need a special function for this, it's all contained in the
standard.

I've constructed a parallel context (with <<...\\...>>) thus having two
voices with opposite stem directions.
The upper noteheads will automatically be merged.

Now for the tricky part (the 16th flags): First, I've set \autoBeamOff in
the upper voice to get single flags.
Secondly, I've entered 16th notes (to get the semiquaver tails), but
rhythmically made quavers out of them by multiplying their value by 2 (16*2
= 8).
As a result, you get the desired 16th flags where practically there are 8th
notes:

\version "2.19.81"

\relative {
  << { \autoBeamOff e''16*2 e e e } \\ 
 { 8 * } >>
}

Another (simpler) way is to insert invisible rests between ordinary
semiquavers:

\relative {
  << { e''16 s e s e s e s } \\ 
 { 8 * } >>
}

But there's a more or less serious drawback (depending on the overall
spacing, the contents of other staves in the system, etc): the note spacing
will be unnaturally widened (with respect to ordinary quaver spacing).

semiquaver-quavers.png
  

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