Bug: restarting staff destroys DynamicLineSpanner.staff-padding after line break

[Trevor Bača]

Hi,

Restarting the staff during the lifespan of a multisystem
DynamicLineSpanner destroys the value of DynamicLineSpanner properties
(like staff-padding) that were set when the DynamicLineSpanner was created.

In the MWE below, the hairpin should exhibit staff-padding equal to 10
staff spaces below all four systems; but the value of staff-padding is lost
at the point (in system 2) that the staff is restarted; we see evidence of
this after the next line break (in systems 3 and 4) where no staff padding
appears.

%%% BEGIN %%%

\version "2.19.82"

\new Staff
{

\override DynamicLineSpanner.staff-padding = 10
c'1
\p
\<
c'1
c'1
\break

c'1
\stopStaff
\startStaff
c'1
c'1
\break

c'1
c'1
c'1
\break

c'1
c'1
c'1
\f

}

\paper
{
indent = 0
ragged-right = ##t
system-system-spacing.minimum-distance = 30
}

%%% END %%%

[image: restart-staff-dynamic-line-spanner-bug.png]


Thanks,

Trevor.

-- 
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: LilyPond 64-bit version for a Mac

[Hans Åberg]

> On 6 Mar 2019, at 04:20, Austin Blaser  wrote:
> 
> Regarding the iOS App Store: Oh yeah I forgot about the licensing: definitely 
> a potential deal breaker.

Isn't it enough to distribute the sources along with the app, as with Stockfish
https://stockfishchess.org/download/



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

Re: Discussion about Lilypond(for GSoC 2019 project)

[Karlin High]

On 3/6/2019 12:02 PM, AKSHITA TYAGI wrote:
What I think is that it should work on more languages. Like India, 
Chinese etc these are the countries that are really found of music and 
use of Lilypond would increase if it is available in more languages.


More translations sounds like a welcome effort. There is already one 
listed for Chinese.  But I am not 
aware of anything currently being done for any of India's languages.


I am thinking that a translation project also needs ongoing maintenance 
work, as new material gets added to LilyPond. A GSoC project would be 
just a starting point.


And it will be fun to see musical notations to music. like one form 
his/her own notations on Lilypond and it is translated to real music.

Please let me know what you think about the ideas.


LilyPond currently has MIDI output, which other tools can convert to 
audio or even video formats. "Translating to real music" - can you 
further explain what result you want to have?


For other kinds of Asian notation, LilyPond has seen some work for 
Chinese Jianpu notation, and a request for Bengali Swaralipi is 
currently "shelved" for lack of resources.




--
Karlin High
Missouri, USA

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

Discussion about Lilypond(for GSoC 2019 project)

[AKSHITA TYAGI]

Hi,
I have been studying about Lilypond and it seems to be a very good program.
But it work for only a limited number of languages.
What I think is that it should work on more languages. Like India, Chinese
etc these are the countries that are really found of music and use of
Lilypond would increase if it is available in more languages.
And it will be fun to see musical notations to music. like one form his/her
own notations on Lilypond and it is translated to real music.
Please let me know what you think about the ideas.

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

Re: weird error with \repeat tremolo

[N. Andrew Walsh]

Hi Aaron

On Wed, Mar 6, 2019 at 4:11 PM Aaron Hill  wrote:

>
> The bug would seem to be that LilyPond is not allowed to increase the
> length of a stem to accommodate StemTremolo grobs with notes that are
> beamed.  Or perhaps, it is allowed but is failing to do so.  Either way,
> the code that expects to have enough room incorrectly computes a
> degenerate interval, which eventually results in the failed assertion.
>

Not knowing a single thing about Lily's underlying code, I nevertheless
agree that it's something like this. Lily *also* does not extend stems on
un-beamed notes, leading to collisions between flags and tremolo glyphs.

Cheers,

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

Re: weird error with \repeat tremolo

[Aaron Hill]

On 2019-03-06 6:24 am, David Kastrup wrote:

Aaron Hill  writes:


On 2019-03-06 4:15 am, N. Andrew Walsh wrote:

Hi Aaron,

here's another example that causes the error:

\version "2.19.82"

\relative c'' {
  \time 4/16
  gis'32[ e c a \repeat tremolo 8 { fis64] }
}

Again, it seems related to collisions between beams and tremolo
glyphs. But
here, the 32nd-notes should force the bottom beam low enough that
there's
room for them, yet for whatever reason it fails anyway.


It doesn't force the beam low enough.  That is because your sequence
of notes prefers a stem-down beaming which means that the final note
will have the shortest stem length.  If you manually switch to stem-up
(i.e. use "^[") then it works fine because there is enough length.

Sticking with stem-down behavior, you would have to raise the F# up
minimally to the high D:


\version "2.19.82"
\relative c'' { gis'32_[ e c a d8:64] }


This will fail on any note in between.


Well, we have a failed assertion error.  Failed assertions mean that
there is a condition that the programmer does not expect possible to
occur in a score and that makes it likely internal data is corrupted to
a degree where continuing would be unsafe.

Since you can come up with a description of what causes this problem to
occur, it should be possible to devise and implement a safe strategy 
for

the program to continue.

This would take one of three options:
a) output is as good as can be reasonably expected given the input ->
just do it
b) output is bad, to be expected given the input -> do it, give a
warning
c) output is bad, not to be expected by the user given the input ->
do it, give a warning or possibly a programming error
d) output is likely bad, we don't know how the condition came about but
can continue safely -> do it, give a programming error

Something like that.


Of course.  I was not discounting that there is a fault in programming 
that needs addressing.  Perhaps I should have led my post with the 
following (asterisks for emphasis):


It doesn't force the beam low enough *to work around existing buggy 
behavior*.


The bug would seem to be that LilyPond is not allowed to increase the 
length of a stem to accommodate StemTremolo grobs with notes that are 
beamed.  Or perhaps, it is allowed but is failing to do so.  Either way, 
the code that expects to have enough room incorrectly computes a 
degenerate interval, which eventually results in the failed assertion.



-- Aaron Hill

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

Re: weird error with \repeat tremolo

[David Kastrup]

Aaron Hill  writes:

> On 2019-03-06 4:15 am, N. Andrew Walsh wrote:
>> Hi Aaron,
>>
>> here's another example that causes the error:
>>
>> \version "2.19.82"
>>
>> \relative c'' {
>>   \time 4/16
>>   gis'32[ e c a \repeat tremolo 8 { fis64] }
>> }
>>
>> Again, it seems related to collisions between beams and tremolo
>> glyphs. But
>> here, the 32nd-notes should force the bottom beam low enough that
>> there's
>> room for them, yet for whatever reason it fails anyway.
>
> It doesn't force the beam low enough.  That is because your sequence
> of notes prefers a stem-down beaming which means that the final note
> will have the shortest stem length.  If you manually switch to stem-up
> (i.e. use "^[") then it works fine because there is enough length.
>
> Sticking with stem-down behavior, you would have to raise the F# up
> minimally to the high D:
>
> 
> \version "2.19.82"
> \relative c'' { gis'32_[ e c a d8:64] }
> 
>
> This will fail on any note in between.

Well, we have a failed assertion error.  Failed assertions mean that
there is a condition that the programmer does not expect possible to
occur in a score and that makes it likely internal data is corrupted to
a degree where continuing would be unsafe.

Since you can come up with a description of what causes this problem to
occur, it should be possible to devise and implement a safe strategy for
the program to continue.

This would take one of three options:
a) output is as good as can be reasonably expected given the input ->
just do it
b) output is bad, to be expected given the input -> do it, give a
warning
c) output is bad, not to be expected by the user given the input ->
do it, give a warning or possibly a programming error
d) output is likely bad, we don't know how the condition came about but
can continue safely -> do it, give a programming error

Something like that.

-- 
David Kastrup

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

Re: weird error with \repeat tremolo

[Aaron Hill]

On 2019-03-06 4:15 am, N. Andrew Walsh wrote:

Hi Aaron,

here's another example that causes the error:

\version "2.19.82"

\relative c'' {
  \time 4/16
  gis'32[ e c a \repeat tremolo 8 { fis64] }
}

Again, it seems related to collisions between beams and tremolo glyphs. 
But
here, the 32nd-notes should force the bottom beam low enough that 
there's

room for them, yet for whatever reason it fails anyway.


It doesn't force the beam low enough.  That is because your sequence of 
notes prefers a stem-down beaming which means that the final note will 
have the shortest stem length.  If you manually switch to stem-up (i.e. 
use "^[") then it works fine because there is enough length.


Sticking with stem-down behavior, you would have to raise the F# up 
minimally to the high D:



\version "2.19.82"
\relative c'' { gis'32_[ e c a d8:64] }


This will fail on any note in between.

Note that manually setting the beam positions does not help as this 
effects things *after* the programming error has already happened.  
Meaning, you can change the beam positions all you want, but the default 
values are the ones that matter w.r.t. the failing assertion.  Here we 
force the beam positions into an impossible case that still compiles:



\version "2.19.82"
\relative c'' {
  \override Beam.positions = #'(-1.5 . -0.5)
  gis'32_[ e c a d8:64]
}


This works because there was enough room for the grobs when the internal 
calculations were occurring.  Afterwards we \overrode what was computed 
to produce the overlapping grobs.


In a previous thread, I showed how Beam.beam-thickness and 
StemTremolo.beam-thickness can impact things.  Here's yet another 
property: Beam.length-fraction.  Again, examine the following which 
includes cases that would fail if the length-fraction were increased:



\version "2.19.82"
{
  \override Beam.length-fraction = #1.081
  \relative c'' { gis'32_[ e c a d8:64] }
  \override Beam.length-fraction = #0.986
  \relative c'' { gis'32_[ e c a c8:64] }
  \override Beam.length-fraction = #0.890
  \relative c'' { gis'32_[ e c a b8:64] }
  \override Beam.length-fraction = #0.795
  \relative c'' { gis'32_[ e c a a8:64] }
  \override Beam.length-fraction = #0.711
  \relative c'' { gis'32_[ e c a g8:64] }
  \override Beam.length-fraction = #0.711
  \relative c'' { gis'32_[ e c a fis8:64] }
}


Of course, this produces ugly results and is not a good workaround.

But I think I have found a much better workaround.  As I have been 
presuming, the issue has to do with not having enough room for the stem 
length to accommodate both the Beam and StemTremolo grobs.  We need a 
way to tell LilyPond that it can *increase* the stem length as needed.  
This is done by using Stem.details.stem-shorten with negative values.  
Consider the following:



\version "2.19.82"
{
  \override Stem.details.stem-shorten = #'(+inf.0)
  \relative c'' { gis'32_[ e c a d8:64] }
  \override Stem.details.stem-shorten = #'(0.176)
  \relative c'' { gis'32_[ e c a c8:64] }
  \override Stem.details.stem-shorten = #'(-0.324)
  \relative c'' { gis'32_[ e c a b8:64] }
  \override Stem.details.stem-shorten = #'(-0.824)
  \relative c'' { gis'32_[ e c a a8:64] }
  \override Stem.details.stem-shorten = #'(-1.324)
  \relative c'' { gis'32_[ e c a g8:64] }
  \override Stem.details.stem-shorten = #'(-1.574)
  \relative c'' { gis'32_[ e c a fis8:64] }
}


There is an interesting pattern that shows up.  Most of these limit 
values are exactly 0.5 away from each other, which makes a lot of sense 
when you consider that the notes are half a staff space apart.


The final result is not perfect, as we would expect a degree of 
shortening to occur on beamed notes.  But that can be trivially fixed:



\version "2.19.82"
{
  \override Stem.details.stem-shorten = #'(-1.574)
  \override Beam.positions = #'(-3 . -5.5)
  \relative c'' { gis'32_[ e c a fis8:64] }
}



-- Aaron Hill

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

Re: weird error with \repeat tremolo

[N. Andrew Walsh]

Hi Aaron,

here's another example that causes the error:

\version "2.19.82"

\relative c'' {
  \time 4/16
  gis'32[ e c a \repeat tremolo 8 { fis64] }
}

Again, it seems related to collisions between beams and tremolo glyphs. But
here, the 32nd-notes should force the bottom beam low enough that there's
room for them, yet for whatever reason it fails anyway.

Oh well. I guess I'll just force manual beaming as a workaround for now.

Thanks for the help,

A

On Mon, Feb 25, 2019 at 12:11 PM Aaron Hill 
wrote:

> On 2019-02-25 2:15 am, Thomas Morley wrote:
> > Am Mo., 25. Feb. 2019 um 11:02 Uhr schrieb N. Andrew Walsh
> > :
> >>
> >> Hi Aaron,
> >>
> >> On Mon, Feb 25, 2019 at 10:50 AM Aaron Hill 
> >> wrote:
> >>You could try manually lengthening
> >>>
> >>> the stem to see if it helps as a possible workaround.
> >>
> >>
> >> I've gone all the way out to
> >>
> >>  \once \override Beam.positions = #'(-20 . -24)
> >>
> >> and still get the error, so I don't think tweaking stem length is
> >> going to help. Any idea what the error might be? Is there a bug
> >> report?
> >>
> >> Thanks for the help,
> >>
> >> A
> > Some discussion here:
> > https://lists.gnu.org/archive/html/bug-lilypond/2019-02/msg0.html
>
> I was so certain I had posted to the bug alias on this issue, but I
> cannot find it.  It was a pretty big write up too, testing lots of
> things.  But I am feeling like I must have dreamt it, since there's no
> trace.  :-/
>
>
> > Here another minimal:
> >
> > \relative c'' {
> >   %\voiceOne
> >   d16. d32 \repeat tremolo 4 { b32 }
> > }
> >
> > Looks like the error happens only if stems are pointing down, thus
> > above compiles fine if voiceOne is uncommented.
>
> The issue doesn't seem to be precisely stem direction.  You can trigger
> it with this:
>
> 
> \version "2.19.82"
> { a32 8..:32 }
> 
>
> If you change the note to g, then it works.  Lower notes result in a
> longer stem, which is why I had thought it might have something to do
> with stem length.
>
> But then I found that beam-thickness can affect things too:
>
> 
> \version "2.19.82"
> { \override Beam.beam-thickness = #0.488934 a32 8..:32 }
> 
>
> This fails, but change the thickness to #0.488935 or higher and it
> works.
>
> 
> \version "2.19.82"
> { \override StemTremolo.beam-thickness = #0.465801 a32 8..:32 }
> 
>
> Again, this will fail, but *lower* the thickness to #0.465800 and it
> works.
>
> -- Aaron Hill
>
> ___
> 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: Roman Numeral rehearsal marks?

[N. Andrew Walsh]

Hi Aaron

On Wed, Mar 6, 2019 at 11:51 AM Aaron Hill  wrote:

> >
> > \mark produces RehearsalMark grobs.  These are usually at the \Score
> > level, so you can either \override where you use \mark, or you can do
> > it within \layout:
> >
> > 
> > \version "2.19.82"
> > \layout { \context { \Score
> >   \override RehearsalMark.font-size = #6 % Default is #2
> > }
>

thanks for the tip! That's exactly what I was looking for!

Cheers,

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

Re: Roman Numeral rehearsal marks?

[Aaron Hill]

On 2019-03-06 2:48 am, Aaron Hill wrote:

On 2019-03-06 2:37 am, N. Andrew Walsh wrote:

Hi List,

also on this issue (I still have Roman numerals, which works fine for 
me):
is there a way to format the size/weight of the "\mark \default" 
character?
Mine aren't much larger than regular text markups, and I'd like to 
have

some control over the presentation.


\mark produces RehearsalMark grobs.  These are usually at the \Score
level, so you can either \override where you use \mark, or you can do
it within \layout:


\version "2.19.82"
\layout { \context { \Score
  \override RehearsalMark.font-size = #6 % Default is #2
} }
{ \mark "Lorem" b'4 4 4 4
  \once \override Score.RehearsalMark.font-size = #9
  \mark "Ipsum" b'2 2 }



Sorry, was typing too quickly and got a curly brace in the wrong spot.  
Fixed inline above.


-- Aaron Hill

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

Re: Roman Numeral rehearsal marks?

[Aaron Hill]

On 2019-03-06 2:37 am, N. Andrew Walsh wrote:

Hi List,

also on this issue (I still have Roman numerals, which works fine for 
me):
is there a way to format the size/weight of the "\mark \default" 
character?

Mine aren't much larger than regular text markups, and I'd like to have
some control over the presentation.


\mark produces RehearsalMark grobs.  These are usually at the \Score 
level, so you can either \override where you use \mark, or you can do it 
within \layout:



\version "2.19.82"
\layout { \context \Score {
  \override RehearsalMark.font-size = #6 % Default is #2
} }
{ \mark "Lorem" b'4 4 4 4
  \once \override Score.RehearsalMark.font-size = #9
  \mark "Ipsum" b'2 2 }



-- Aaron Hill

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

Re: Roman Numeral rehearsal marks?

[N. Andrew Walsh]

Hi List,

also on this issue (I still have Roman numerals, which works fine for me):
is there a way to format the size/weight of the "\mark \default" character?
Mine aren't much larger than regular text markups, and I'd like to have
some control over the presentation.

Cheers,

A

On Wed, Oct 24, 2018 at 6:48 PM N. Andrew Walsh 
wrote:

> PS- update: I figured out the problem, so now it's resolved (and in the
> process dropped an \include that was loading a whole bunch of libraries I
> turned out not to need, saving on compile time as well).
>
> Thanks again!
>
> On Wed, Oct 24, 2018 at 6:39 PM N. Andrew Walsh 
> wrote:
>
>> Hi Thomas, Ben
>>
>> for some reason, neither of your codes seem to work: I always get arabic
>> numerals in a box if I use \mark \default. I think something is overriding
>> that setting elsewhere in my config files; I'll try to track it down. The
>> MWE Ben sent works just as I want it to on its own, but not in the main
>> document. I'll have to do some digging.
>>
>> Thanks!
>>
>> A
>>
>> On Wed, Oct 24, 2018 at 5:10 PM Thomas Morley 
>> wrote:
>>
>>> Am Mi., 24. Okt. 2018 um 17:02 Uhr schrieb Ben <
>>> soundsfromso...@gmail.com>:
>>>
>>> > This should be what you need (see attached)
>>>
>>> We do have 'number-format', so one could do:
>>>
>>> #(define-public (format-roman-mark-numbers mark context)
>>>   (make-bold-markup (number-format 'roman-upper mark)))
>>>
>>> #(define-public (format-boxed-roman-mark-numbers mark context)
>>>   (make-bold-markup (make-box-markup (number-format 'roman-upper mark
>>>
>>> \layout {
>>>   \context {
>>> \Score
>>> markFormatter =
>>>   %#format-roman-mark-numbers
>>>   #format-boxed-roman-mark-numbers
>>> %% 2.21.0
>>> %markFormatter = #(format-mark-generic '(roman box bold mixedcase))
>>>   }
>>> }
>>> {
>>> \mark \default
>>> R1
>>> \mark \default
>>> R1
>>> }
>>>
>>> Cheers,
>>>   Harm
>>>
>>> ___
>>> 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