Re: Slurs inside a beam

[Aaron Hill]

On 2018-08-11 13:30, David F. wrote:

While we’re on the topic of bending slurs to our will, I’d like for
slurred, beamed eighth notes to have the slur printed below or inside
the beam.  This works with a simple ^~ for ties.  How might I
accomplish this?



The behavior I am after can also be seen here:
  https://hymnary.org/hymn/SS4C1956/page/561


You can always adjust the control points to get the slur to fit within 
the notes.  However, manually setting control points can be a little 
tedious, especially if you have a slur that is almost correct but just 
needs a little nudging in the right direction.


This (likely over-engineered) approach allows you to transform an 
existing slur by means of scaling, rotation and translation.  It 
automatically scales and rotates about the center of the slur, which 
seemed most natural when I was experimenting with it.



\version "2.19.82"
\language "english"

#(define (transform-coords coords scale rotate offset)
  (let* ((x-coords (map (lambda (coord) (car coord)) coords))
 (y-coords (map (lambda (coord) (cdr coord)) coords))
 (x-center (/ (+ (apply min x-coords) (apply max x-coords)) 2))
 (y-center (/ (+ (apply min y-coords) (apply max y-coords)) 2))
 (theta (* rotate (/ PI 180)))
 (c (cos theta)) (s (sin theta)))
(map (lambda (coord) (let (
(x (* (- (car coord) x-center) (car scale)))
(y (* (- (cdr coord) y-center) (cdr scale
  (cons (+ (* x c) (* y (- s)) x-center (car offset))
(+ (* x s) (* y c) y-center (cdr offset) coords)))

#(define ((transform-slur scale rotate offset) grob)
  (let ((coords (ly:slur::calc-control-points grob)))
(transform-coords coords scale rotate offset)))

transformSlur =
#(define-music-function (parser location scale rotate offset)
(pair? number? pair?)
  #{ \once \override Slur.control-points =
   #(transform-slur scale rotate offset) #})

\new Staff \with { beamExceptions = #'() } << {
  e'8 ( a'8 )
  \transformSlur #'(0.6 . 0.8) #15 #'(-0.3 . -2.6)
  e'8 ^( a'8 )
  \tuplet 3/2 { b'8 ( a'8 ) f'8 }
  \tuplet 3/2 {
\transformSlur #'(0.5 . 0.6) #180 #'(0.4 . 2)
b'8 _( a'8 )f'8 }
} >>


NOTE: Purely for the sake of demonstrating rotation, the second slur is 
a "down" slur that I have flipped over.


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

Re: Slurs inside a beam

[Andrew Bernard]

Hi David,

One way to do it:

\version "2.19"

{
  8. 16
}


>From the Changes page:

A new command \=X has been added – where ‘X’ can be any non-negative
integer or symbol – so that a specific ‘id’ can be assigned to the start
and end of slurs and phrasing slurs.

This is useful when simultaneous slurs are required or if one slur overlaps
another or when nesting short slurs within a longer one.

Andrew



On Sun, 12 Aug 2018 at 06:31, David F.  wrote:

> While we’re on the topic of bending slurs to our will, I’d like for
> slurred, beamed eighth notes to have the slur printed below or inside the
> beam.  This works with a simple ^~ for ties.  How might I accomplish this?
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Slurs inside a beam

[David F.]

While we’re on the topic of bending slurs to our will, I’d like for slurred, 
beamed eighth notes to have the slur printed below or inside the beam.  This 
works with a simple ^~ for ties.  How might I accomplish this? 

\version "2.19"
\language "english"

\new Staff \with { beamExceptions = #'() } << {
 e'8 ~ e'8  % Tie bends down
 e'8 ^~ e'8  % Tie bends up *below* or *inside* the beam

e'8 ( a'8)  % Bends down
e'8 ^( a'8 )  % Bends up *above* or *outside* the beam

\tuplet 3/2 { b'8 ( a'8 ) f'8 }  % Bends down

\tuplet 3/2 { b'8 ^( a'8 ) f'8 }  % Bends up *above* or *outside* the beam
}>>

The behavior I am after can also be seen here:
  https://hymnary.org/hymn/SS4C1956/page/561

Thanks!
David


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

Re: v2.19 pdf manuals are malformed

[Karlin High]

On 8/11/2018 2:43 PM, Galen Menzel wrote:
The PDF manuals linked from http://lilypond.org/development.html appear 
to be malformed. Compare page 1 of notation.pdf from v2.18 and v2.19


I understand it's a known issue, in the process of getting fixed. Thanks 
for reminding.



--
Karlin High
Missouri, USA

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

Re: Making slurs more visible

[Galen Menzel]

On 11 Aug 2018, at 10:33, David Kastrup wrote:

> "Galen Menzel"  writes:
>
>> On 11 Aug 2018, at 1:23, Torsten Hämmerle wrote:
>>>
>>> This is just to explain how the penalty system works for finding the
>>> optimum
>>> solution among several possibilities, but of course the best way is
>>> to say
>>> "I definitely do not want ties shorter than min-length!" is simply
>>> setting
>>> Tie.details.min-length.
>>
>> Hi Thorsten — thanks for this excellent explanation! It definitely
>> makes things clearer. To avoid unintended consequences of futzing I’ve
>> ended up just briefly adjusting the ties as follows:
>>
>> \override Tie.details.min-length=#3
>> g4. g8~g g~g g
>> \revert Tie.details.min-length
>>
>> Thanks for all the help!
>
> I'd recommend using \temporary \override here since then the \revert
> will restore any preexisting value.  That makes such a passage work
> better as a "black box" for copy and/or in music functions.

Great tip — thank you!

Galen

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

Re: Making slurs more visible

[David Kastrup]

"Galen Menzel"  writes:

> On 11 Aug 2018, at 1:23, Torsten Hämmerle wrote:
>>
>> This is just to explain how the penalty system works for finding the
>> optimum
>> solution among several possibilities, but of course the best way is
>> to say
>> "I definitely do not want ties shorter than min-length!" is simply
>> setting
>> Tie.details.min-length.
>
> Hi Thorsten — thanks for this excellent explanation! It definitely
> makes things clearer. To avoid unintended consequences of futzing I’ve
> ended up just briefly adjusting the ties as follows:
>
> \override Tie.details.min-length=#3
> g4. g8~g g~g g
> \revert Tie.details.min-length
>
> Thanks for all the help!

I'd recommend using \temporary \override here since then the \revert
will restore any preexisting value.  That makes such a passage work
better as a "black box" for copy and/or in music functions.

-- 
David Kastrup

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

Re: Making slurs more visible

[Galen Menzel]

On 11 Aug 2018, at 1:23, Torsten Hämmerle wrote:


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

Tie.details.min-length.


Hi Thorsten — thanks for this excellent explanation! It definitely 
makes things clearer. To avoid unintended consequences of futzing I’ve 
ended up just briefly adjusting the ties as follows:


\override Tie.details.min-length=#3
g4. g8~g g~g g
\revert Tie.details.min-length

Thanks for all the help!

Best,

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

Re: Making slurs more visible

[Galen Menzel]

On 11 Aug 2018, at 0:26, Malte Meyn wrote:


I would not notate the left hand rhythm as

4. 8~ 8 8~ 8 8

but as

4. 8~ 8 4 8

That’s easier to read for the player.


Thanks for pointing this out! You’re totally right — I’m not sure 
why I thought tied eighth notes would be appropriate here.


Galen

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

Re: IRC freenode issue

[Jan Nieuwenhuizen]

David Kastrup writes:

> I thought that freenode changing to SSL-traffic only was supposed to
> deal with the Spam problem?  Or was that ineffective?

I have no idea.  All I know is that #lilypond still received lots of
spam.  Hopefully freenode fixes this so we can re-allow unregistered
users to post.

janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

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

Re: IRC freenode issue

[David Kastrup]

Jan Nieuwenhuizen  writes:

> As per
>
> https://lists.gnu.org/archive/html/guix-devel/2018-08/msg7.html
>
> I set /mode +q $~a on #lilypond.  This means that non-registered nicks
> can join but not post.  That's not great...hoping for a better solution.

I thought that freenode changing to SSL-traffic only was supposed to
deal with the Spam problem?  Or was that ineffective?

-- 
David Kastrup

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

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

[Torsten Hämmerle]

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

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



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

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



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

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



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

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

All the best and enjoy your week off
Torsten




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

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

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

[Thomas Morley]

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

Hi Torsten,

this weekend I'll have not much time and I'll be completely offline
next week for holidays.

That said...

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

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

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

The curvy positioning is bad, imho.
But I agree it might be a different issue.

> To illustrate this, I've switched off any padding values, put a box around
> the fingering numbers and gradually changed the font size from very small to
> big in order to be able to observe the evolution of fingering placement.
> I've used just one flat because of its straight left border.
>
> 
>
> Starting off with a very small font size, there's enough space for each
> fingering to take its ideal Y-position, exactly centred on its notehead.
>
>
> *Rule: A fingering must never get in between accidentals and noteheads.*
>
>
> *In (1)*, the fingering "1" hardly touches the blue line signifying the
> lower end of the flat accidental. It still can stick to its notehead.
> Fingerings 2, 3, and 4 clearly have to go outside the flat and are pushed
> away from the notehead because of The Rule.
>
> *In (2)*, the font size has been increased so that the "1" just slightly
> gets into the "forbidden" flat area and therefore is pushed away from the
> notehead, too.  The "5" still has enough space.
>
> *In (3) and (4)*, the increasing height of the numbers starts spreading them
> vertically, away from their original Y position.  In (4), it is clearly
> visible that the "1" does not interfere with the flat anymore, but still (!)
> keeps its outside position.
>
> *In (5)*, finally, all the fingering number keep a distance from their
> noteheads, even if the "1" and the "5" are actually quite far away from the
> accidental.
>
> The (intended) reason for this is that, even if there seems to be enough
> space in the direct vicinity of their noteheads, these fingerings stay
> "outside" because at their original Y position, they'd get in between
> accidentals and noteheads. That's the simple reason why they stay "outside":
> their X position is determined by the accidentals, calculated as if the
> fingerings had their original Y position (i.e. the notehead's Y position).
> In a second step, their Y position will be spread out due to stacking, while
> keeping the X position.
>
> If there are more than on accidentals involved (or sharps with their more
> complex left skyline), the stacked fingerings may take on alignments along a
> curved path.
>
> In the end, snap-radius is used to avoid very small irregularities by
> positioning the fingering in a straight line if they have "nearly" the same
> X position to avoid an irregular, look.
>
> But, as I said, I consider this expected behaviour, even if it seems odd at
> first glance.
> Would you agree?

Yes, so far. :)

Thanks,
  Harm

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

IRC freenode issue

[Jan Nieuwenhuizen]

As per

https://lists.gnu.org/archive/html/guix-devel/2018-08/msg7.html

I set /mode +q $~a on #lilypond.  This means that non-registered nicks
can join but not post.  That's not great...hoping for a better solution.

Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

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

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

[Torsten Hämmerle]

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


Hi Harm,

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

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

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

 

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


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


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

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

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

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

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

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

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

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

All the best,
Torsten



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

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

Re: Figured Bass discrepancy with Manual Lilypond & lyLuaTeX

[Urs Liska]

Please start new threads for new topics.


Am 11.08.2018 um 06:53 schrieb liebre...@grossmann-venter.com:

Thanks.
I assumed it wasnt code and some arbitrary form of quotation.
Bad assumption.
thanks that settles it.

To the other post.
Definitely three steps above in my browser.




On 2018-08-11 00:40, Brian Barker wrote:

At 00:09 11/08/2018 -0400, Nobody Noname wrote:

From the Lilypond manual,
"http://lilypond.org/doc/v2.19/Documentation/notation/figured-bass;

 I use the following code for figured bass.

(The code is 3-steps above "Predefined commands" at the end)

  \new Staff = "myStaff"
  \figuremode {
    <4>4 <10 6>8 s8
    <6 4>4 <6 4>
  }
  %% Put notes on same Staff as figures
  \context Staff = "myStaff"
  {
    \clef bass
    c4 c'8 r8 c4 c'
  }

If I compile it with Lilypond I get the attached image image-1 and 
with lyluatex I get attached image-2. Both image-1 and image-2 
disagree with what the manual shows the code should output. What do 
I do wrong ? [...]


You arbitrarily omitted the double angle brackets shown in the
example, which indicate simultaneous expressions.

Brian Barker


___
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: How to engrave a simple three-voice song in a single staff

[Jakob Schöttl]

Hi Lukas,

Thank you, that was exactly what I was looking for!

Best, Jakob

Am 10.08.2018 um 16:20 schrieb Lukas-Fabian Moser:
> Hi Jakob,
>
>> I'd like to have a simple three-voice traditional song in a single
>> staff.
>>
>> - same notes should be merged to one note
>> - the upper two voice should be merged to chords
>>
>
> Maybe something like:
>
> \version "2.19.80"
>
>
> \new Staff \with { printPartCombineTexts = ##f }
>   <<
>     \partcombine
>     \relative g' {
>   \partial 4 g4
>   g4 c8 b c4
>     }
>     \relative g' {
>   \partial 4 g4
>   e4. f8 g4
>     }
>   \\
>    \relative g' {
>  \partial 4 g4
>  c,4. d8 e4
>    }
>   >>
>
>
> But expect trouble if rhythms start to become independent.
>
> Best
> Lukas
>
> PS. I left the \partial in each voice - while it's unneccesary here,
> it might be useful to have it in each voice if you want to extract parts.

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

Re: Making slurs more visible

[Torsten Hämmerle]

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

Hi Galen,

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

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

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


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

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

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

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

HTH,
Torsten






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

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

Re: Making slurs more visible

[Malte Meyn]

Am 10.08.2018 um 21:42 schrieb Galen Menzel:

Hi all,

I have a score in which the following measure renders nicely when only 
the piano line is given:


However, when the vocal line is also given, the slurs above the 
bass-clef g eighth notes become very hard to see:


Presumably the vocal line alters the spacing of the bass-clef notes, 
putting enough space between them that lilypond decides to use smaller 
ties that fit between the note heads, rather than larger ties that span 
the tops of the note heads. But in this case I find the smaller ties 
look worse. Is there a simple way to direct lilypond to use the larger 
ties here?


Slightly off-topic but maybe helpful:

I would not notate the left hand rhythm as

4. 8~ 8 8~ 8 8

but as

4. 8~ 8 4 8

That’s easier to read for the player.

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