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: Test.ly has no PDF output

[Knute Snortum]

I can confirm this behavior.

---
Knute Snortum
(via Gmail)


On Thu, Mar 26, 2020 at 2:41 PM Adam Aranyosi 
wrote:

> Hello,
>
> I've just installed the latest version of Lilypond on my Windows pc and
> when I drag and drop the test.ly file it has no PDF output. The log seems
> to be unfinished, but there is no error message. (The previous version
> worked perfectly.)
>
> Do you have any ideas how to solve this?
>
> Thanks in advance,
> Adam
>

Re: Isolated durations on rests

[David Kastrup]

Noeck  writes:

> Hi,
>
> is this behaviour intentional?
>
>   \version "2.20.0"
>   { r4 8 a b }

Yes.

> The "8" is equivalent to c'8.

Not really.  It remains unpitched.  Put it in some other context, and it
will assume a different pitch.

> I think I understand what happens: the isolated duration is given a
> default pitch c'.


> What I would expect is that it is another rest, equivalent to
>
>   { r4 r8 a b }
>
> Was this just easier to implement that way for isolated durations or is
> there another reasoning behind that behaviour?

A rhythm can contain rests.  If rests would be part of the system, you
could not write an unpitched rhythm that takes its pitch once you
precede it with something else.

Like

rhythm = { 4. r8 8 8 r4 }

\new Staff
<<
  { e''1 \rhythm } \\
  { c''1 \rhythm }
>>

-- 
David Kastrup

Re: Minimal horizontal space for melismata

[David Wright]

On Fri 27 Mar 2020 at 16:04:40 (+0100), Peter Crighton wrote:
> On Thu, 26 Mar 2020 at 10:14, Kevin Barry  wrote:
> > On Tue, 24 Mar 2020 at 15:06, Peter Crighton  wrote:
> > > I want the lyrics to be absolutely free of melismatic hyphens. How can I
> > make sure of that? I have ensured that the note heads take as little space
> > as they can (to my knowledge), but if it is either a short syllable and/or
> > a long melisma, the note heads still take up too much space, so hyphens
> > appear. See example below.
> >
> > You could try using underscores instead of hyphens so that the lyrics
> > are always tied to the first note and won't be split up. E.g., in your
> > example, use:
> > %%
> > Lyric = \lyricmode {
> >   Lorem _ ipsum _ dolor _ sit amet. _
> > }
> > %%
> > instead of using two hyphens (you need to add an underscore for every
> > syllable after the first - see the section "Multiple notes to one
> > syllable" in the docs for the details).
> 
> Unfortunately that’s not an option because I need the same \Lyrics variable
> in another, normal score – with hyphens – and cannot change it for this.
> It’s not so much a problem of ‘How do I get rid of the hyphens?’ rather
> than ‘How do I let the melisma note heads take up less space / the space of
> a solitary note head?’

[I haven't followed the discussion.]

If you put the lyrics into variables, segregate them into a separate
file which you \include, then it would be straightforward to replace
all the -- hyphenations (and any surrounding whitespace) into a
character of your choice, be it _, NBSP, or whatever, with sed to
create an alternative file that you \include in this situation.
You could run sed automatically in the script that runs LP, and
the file would be trashed after use (so you only maintain one file
of lyrics).

Cheers,
David.

Re: Isolated durations on rests

[David Wright]

On Fri 27 Mar 2020 at 20:51:16 (+0100), Noeck wrote:
> is this behaviour intentional?
> 
>   \version "2.20.0"
>   { r4 8 a b }
> 
> The "8" is equivalent to c'8. I think I understand what happens: the
> isolated duration is given a default pitch c'.
> What I would expect is that it is another rest, equivalent to
> 
>   { r4 r8 a b }
> 
> Was this just easier to implement that way for isolated durations or is
> there another reasoning behind that behaviour?

Well, a repeated note might have to be specified as deses'' or some such,
whereas a rest is likely to be just r. So this scheme saves some typing,
particularly for those who use absolute all the time.

(Personally I don't use lone durations.)

Cheers,
David.

Re: Lilypond 2.20 on Mac 10.15

[Hans Åberg]

> On 27 Mar 2020, at 18:53, Moritz Heffter  wrote:
> 
>> Try in Terminal
>>  export PATH=/usr/bin:/bin:/usr/sbin:/sbin
>> 
>> and then
>>  /opt/lilypond/bin/lilypond
> 
> Hmm, I have done that, but unfortunately without progress.

In the link below, the issue was solved by fixing the environment variable 
LIBRARY_SEARCH_PATHS. Have you set it? Type ‘env’ in Terminal, to make sure it 
is not set there.

https://stackoverflow.com/questions/18758837/xcode-quit-unexpectedly-for-my-project-not-in-xcode-4-6-3

Isolated durations on rests

[Noeck]

Hi,

is this behaviour intentional?

  \version "2.20.0"
  { r4 8 a b }

The "8" is equivalent to c'8. I think I understand what happens: the
isolated duration is given a default pitch c'.
What I would expect is that it is another rest, equivalent to

  { r4 r8 a b }

Was this just easier to implement that way for isolated durations or is
there another reasoning behind that behaviour?

Cheers,
Joram

Re: Proposal: Changing tremolo beam gap implementation

[Thomas Morley]

Am Fr., 27. März 2020 um 18:35 Uhr schrieb 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
> 

Hi Torsten,

for whole-note-tremolo there is taken care for not colliding with
left/right NoteHeads, even for 'gap = 0
If 'gap <= 2 then there is white space added, exactly as specified
(half of gap-size to left/right), measured from NoteHeads to Beam.

(1) Why should it be different if 'gap is greater than 2.0?
(2) Why should it be different for other note-durations?

Thus I think 'gap should always specify the _white_ space.


Btw, I stumbled across it while trying to code a custom-function
attempting to make whole-note-tremolo-beams avoid possible Dots to the
left and possible Accidentals to the right.

Any chance for a fix, while you're on it?


Many thanks,
  Harm

P.S. I crossposted to devel, not all are subscribed to the user-list

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

[Thomas Morley]

Am Fr., 27. März 2020 um 14:51 Uhr schrieb 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
>

Hi Torsten,

thanks for your findings!!

Though, setting Stem.thickness zero, results in consistent shortening
values on my maschine, _if_ 'gap <= 2.
With 'gap > 2 the deviation is indeed increased.

Though, setting Stem.thickness 50 results in _always_ consistent
behaviour, at least so far tested.

I can't imagine any reason for it, thus I'd say it qualifies for a bug.
Obviously you think alike, thanks for opening a ticket:
https://sourceforge.net/p/testlilyissues/issues/5868/


Best,
  Harm

Re: Lilypond 2.20 on Mac 10.15

[Moritz Heffter]

>> On 26 Mar 2020, at 19:03, Moritz Heffter  wrote:
>> 
>> Thanks for the information. I’ve reinstalled the 2.19 package and put 
>> /opt/lilypond/bin in the PATH. I can execute lilypond from the Terminal 
>> still getting the segmentation fault. But now with a different reason:
>> 
>> Termination Signal:Segmentation fault: 11
>> Termination Reason:Namespace SIGNAL, Code 0xb
>> 
>> The permissions for /opt and /opt/lilypond are ok. /opt/local doesn’t exist 
>> anymore, because I removed the port packages. And it seems that all 
>> necessary packages come with the lilypond installer. Is that right?
>> 
>> My PATH now looks the following:
>> /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/Library/Apple/usr/bin:/Users/username/Library/Python/3.7/bin:/opt/lilypond/bin
> 
> Try in Terminal
>  export PATH=/usr/bin:/bin:/usr/sbin:/sbin
> 
> and then
>  /opt/lilypond/bin/lilypond

Hmm, I have done that, but unfortunately without progress.

> The idea is to cut down as much as possible on the included binaries. The 
> MacPorts installer package should have full paths to all includes.

Ok, I got it. Even if there is nothing in PATH the error stays the same. It’s 
that „Namespace Signal“ error.

Sorry for the bad news. Is there anything else I could try? BTW, the 32-bit 
version works in a docker container.

Best,
Moritz

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: Default accidental style with timing off

[Fr. Samuel Springuel]

> On 26 Mar, 2020, at 7:50 PM, Mark Stephen Mrotek  wrote:
> 
> Fr. Samuel.
> 
> 1) The bar instructions are in printer's (curly) double quotes.

Sorry about that, my email client must have mangled them as they aren’t that 
way in the original document.  I’ve attached the original below.

> 2) The timing = ##f may be incorrectly written/located. See: 
> http://lilypond.org/doc/v2.19/Documentation/learning/gregorian-transcription-template.

That line is equivalent to the \set Score.timing = ##f in that template, just 
relocated to a context definition so as to facilitate putting all the settings 
in one place.  I don’t like that template because of how it scatters the 
settings in three places (a layout block which redefines several context 
defaults, the \include statement, and the aforementioned \set statement) and so 
I’m writing my own.  My intention is to have a single include file that will 
apply *all* the necessary changes when used.  I’m also trying to eliminate the 
\divisio… concept of gregorian.ly and instead using the more usual \bar 
mechanism.

I’ll point out, however that the indicated template has the same problems with 
accidentals.


✝✝
Fr. Samuel, OSB
(R. Padraic Springuel)
St. Anselm’s Abbey
4501 South Dakota Ave, NE
Washington, DC, 20017
202-269-2300
(c) 202-853-7036

PAX ☧ ΧΡΙΣΤΟΣ


accidental_style.ly
Description: Binary data

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

[David Kastrup]

Torsten Hämmerle  writes:

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

Sometimes it is hard to compare.  "Features" are often the outcome of
the architecture making something easy or hard or a fudgearound.  You
can increase their number by just investing more work against bad odds.

There has been quite a bit of tweaking added to LilyPond in recent years
and ways to make it more comfortable to end users, but the naked
"feature" sheet has not seen a lot of growth.

What is and what is not and what is well and not well supported is a
really complex landscape with music typesetting software.  As a
decision-maker, it's a so-so thing.

I'd expect Dorico to catch up eventually featurewise: it has the
advantage of being architectured by a team where several core members
had years of experience with the kind of thing causing problems in
Sibelius.

The main problem for me is that all that is sort-of shoulder-shrug
material.  For me the main incentive for using LilyPond is its
text-based input.  Checking off feature lists is comparatively
unimportant for me.  I'd expect this kind of choice to be similarly
orthogonal to feature sets for those deciding against using LilyPond
because of its text-based input.

-- 
David Kastrup

Re: Minimal horizontal space for melismata

[Peter Crighton]

On Thu, 26 Mar 2020 at 10:14, Kevin Barry  wrote:

> Hi Peter,
>
> On Tue, 24 Mar 2020 at 15:06, Peter Crighton 
> wrote:
> > I want the lyrics to be absolutely free of melismatic hyphens. How can I
> make sure of that? I have ensured that the note heads take as little space
> as they can (to my knowledge), but if it is either a short syllable and/or
> a long melisma, the note heads still take up too much space, so hyphens
> appear. See example below.
>
> You could try using underscores instead of hyphens so that the lyrics
> are always tied to the first note and won't be split up. E.g., in your
> example, use:
> %%
> Lyric = \lyricmode {
>   Lorem _ ipsum _ dolor _ sit amet. _
> }
> %%
> instead of using two hyphens (you need to add an underscore for every
> syllable after the first - see the section "Multiple notes to one
> syllable" in the docs for the details).


Unfortunately that’s not an option because I need the same \Lyrics variable
in another, normal score – with hyphens – and cannot change it for this.
It’s not so much a problem of ‘How do I get rid of the hyphens?’ rather
than ‘How do I let the melisma note heads take up less space / the space of
a solitary note head?’

--
Peter Crighton | Musician & Music Engraver based in Mainz, Germany
http://www.petercrighton.de

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

[Torsten Hämmerle]

Very nice.

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

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

Cheers,
Torsten





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

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

[Aaron Hill]

On 2020-03-27 7:08 am, Valentin Villenave wrote:

Hi everybody,
I know it’s off-topic but I wanted to share the news because, let’s be
honest, nobody in their right mind would want to miss it:
Yes!  It’s finally here!  The latest and brightest version of Sibelius
is out…  *And* it offers one particularly exciting, exclusive new
feature:
https://is.gd/x16C0B

… Oh wait, that’s the wrong link.  There you go:
https://is.gd/ussdKG

Seriously guys, how cool is that??


I especially like how they show Dorico's approach which is to add LV 
directly as an item whereas Sibelius requires two actions: create a tie 
and then convert the tie to LV.  Mind you, since an LV looks similar to 
a tie, I can easily see the technical justification for their design; 
but semantically, LV does not mean the same thing as a tie.  So what do 
you do when you need an LV when there is no subsequent note to which to 
tie?  Do you have to create an invisible note, add a tie, and then 
convert to LV?  Or does Sibelius already allow you to have dangling 
ties, and this feature is just shortening the visual extent?



-- Aaron Hill

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

[Shane Brandes]

They are really on the ball on that one.

-Shane

On Fri, Mar 27, 2020 at 10:09 AM Valentin Villenave 
wrote:

> Hi everybody,
> I know it’s off-topic but I wanted to share the news because, let’s be
> honest, nobody in their right mind would want to miss it:
> Yes!  It’s finally here!  The latest and brightest version of Sibelius
> is out…  *And* it offers one particularly exciting, exclusive new
> feature:
> https://is.gd/x16C0B
>
> … Oh wait, that’s the wrong link.  There you go:
> https://is.gd/ussdKG
>
> Seriously guys, how cool is that??
>
> Cheers,
> V.
>
>

An exciting new release… of Sibelius!!!

[Valentin Villenave]

Hi everybody,
I know it’s off-topic but I wanted to share the news because, let’s be
honest, nobody in their right mind would want to miss it:
Yes!  It’s finally here!  The latest and brightest version of Sibelius
is out…  *And* it offers one particularly exciting, exclusive new
feature:
https://is.gd/x16C0B

… Oh wait, that’s the wrong link.  There you go:
https://is.gd/ussdKG

Seriously guys, how cool is that??

Cheers,
V.

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: Strange gap-behaviour with whole-note tremolo Beams

[Thomas Morley]

Am Fr., 27. März 2020 um 13:48 Uhr schrieb Malte Meyn :
>
>
>
> Am 27.03.20 um 12:23 schrieb Thomas Morley:
> > I have no clue why this happens and where those added values came from.
> >
> > Any insights?
>
> Wild guess, to be tested: ll. 558 ff. of beam.cc.
>

Hi Malte,

I had a look, alas, with my close-to-zero knowledge of C++ I have still no clue.
Do you think it's a bug?
Or any Idea how to compensate those added values?

As last resort I could recreate Beam.stencil with a custom-stencil.
Though I really hope I can avoid it...

Thanks,
  Harm

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

[Malte Meyn]

Am 27.03.20 um 12:23 schrieb Thomas Morley:

I have no clue why this happens and where those added values came from.

Any insights?


Wild guess, to be tested: ll. 558 ff. of beam.cc.

Strange gap-behaviour with whole-note tremolo Beams

[Thomas Morley]

Hi all,

I tried to improve the code from
https://lists.gnu.org/archive/html/lilypond-user/2020-03/msg00265.html
but all my attempts resulted in inconsistent behaviour.

Thus I wrote some test-code, see bottom.

Obviously the beam is shortened while applying 'gap, though as soon as
'gap exceeds 2.0 a certain value is added and further increasing 'gap
by multiples of 0.1 leads to additions of 0.2 !?

Excerpt from terminal:

Applied gap: 1.7, shortens the Beam by: 1.7
Applied gap: 1.8, shortens the Beam by: 1.8
Applied gap: 1.9, shortens the Beam by: 1.9
Applied gap: 2.0, shortens the Beam by: 2.0
Applied gap: 2.1, shortens the Beam by: 2.107998
Applied gap: 2.2, shortens the Beam by: 2.307998
Applied gap: 2.3, shortens the Beam by: 2.507998
Applied gap: 2.4, shortens the Beam by: 2.707998

I have no clue why this happens and where those added values came from.

Any insights?

Thanks,
  Harm

Here the test-code (printed output of 5 pages is not interesting, look
at terminal-messages)

\version "2.20.0"

\paper { ragged-right = ##f indent = 0 }

#(define (tst gap)
  #{
\override Beam.after-line-breaking =
  #(lambda (grob)
 (let* ((sys (ly:grob-system grob))
(bound-left (ly:spanner-bound grob LEFT))
(bound-right (ly:spanner-bound grob RIGHT))
(left-nc (ly:grob-parent bound-left X))
(right-nc (ly:grob-parent bound-right X))
(left-nc-ext (ly:grob-extent left-nc sys X))
(right-nc-ext (ly:grob-extent right-nc sys X))
(max-beam-length (- (car right-nc-ext) (cdr left-nc-ext)))
(x-pos (ly:grob-property grob 'X-positions))
(beam-length (interval-length x-pos)))
   (format #t "\nApplied gap: ~a, shortens the Beam by: ~a"
 gap
 (- max-beam-length beam-length

\override Beam.gap = $gap

\repeat tremolo  #8 { a'16 a' }
  #})

$@(map (lambda (gap) (tst gap)) (iota 61 0 0.1))