Re: How to force tempo markings on single line

[Jacques Menu]

Hello,

Or also:

\score {
  \new Staff {
\set Score.skipBars = ##t
\markLengthOn
\tempo "Allegro con moto" 4 = 120
R1*8
\tempo "Adagio sostenuto" 4 = 50
R1*8
  }
}

JM

> Le 3 nov. 2015 à 07:26, Pierre Perol-Schneider 
>  a écrit :
> 
> Hi, 
> How about:
> 
> \version "2.18.2"
> 
> \score {
>   \new Staff {
> \set Score.skipBars = ##t
> \override Score.MetronomeMark.extra-spacing-width = #'(-0.0 . 0.4)
> \override Score.MetronomeMark.extra-spacing-height = #'(-inf.0 . +inf.0)
> \tempo "Allegro con moto" 4 = 120
> R1*8
> \tempo "Adagio sostenuto" 4 = 50
> R1*8
>   }
> }
> 
> Cheers,
> Pierre
> 
> 2015-11-03 0:38 GMT+01:00 H. S. Teoh  >:
> I'm generating parts from an orchestral score, and am running an issue
> where long tempo markings over collapsed multi-measure rests would force
> the text to stack up in an ugly way on top of each other. Is there some
> way of telling lilypond to prefer stretching the horizontal width of the
> bars instead? Almost minimal example:
> 
> \version "2.18.2"
> \score {
> \new Staff {
> \set Score.skipBars = ##t
> \tempo "Allegro con moto" 4 = 120
> R1*8
> \tempo "Adagio sostenuto" 4 = 50
> R1*8
> }
> }
> 
> 
> T
> 
> --
> English has the lovely word "defenestrate", meaning "to execute by
> throwing someone out a window", or more recently "to remove Windows from
> a computer and replace it with something useful". :-) -- John Cowan
> 
> ___
> 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

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

Re: Valse des Sylphes - Charles GOUNOD

[Johan Vromans]

On Mon, 2 Nov 2015 23:18:08 +0100
Malte Meyn  wrote:

> Hi, I don’t have the time to look at the whole score. But the f sharp in 
> m. 1 is wrong. Maybe you or someone else should check again the whole 
> piece for correct pitches.

Listening to the midi often quickly reveals false pitches.

-- Johan

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

Re: How to force tempo markings on single line

[Malte Meyn]

Am 03.11.2015 um 00:38 schrieb H. S. Teoh:

I'm generating parts from an orchestral score, and am running an issue
where long tempo markings over collapsed multi-measure rests would force
the text to stack up in an ugly way on top of each other. Is there some
way of telling lilypond to prefer stretching the horizontal width of the
bars instead?


There is a way: It’s the command \markLengthOn

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

Re: How to force tempo markings on single line

[Pierre Perol-Schneider]

Oops, totally forgot this one!

2015-11-03 8:38 GMT+01:00 Jacques Menu :

> Hello,
>
> Or also:
>
> \score {
>   \new Staff {
> \set Score.skipBars = ##t
> \markLengthOn
> \tempo "Allegro con moto" 4 = 120
> R1*8
> \tempo "Adagio sostenuto" 4 = 50
> R1*8
>   }
> }
>
> JM
>
> Le 3 nov. 2015 à 07:26, Pierre Perol-Schneider <
> pierre.schneider.pa...@gmail.com> a écrit :
>
> Hi,
> How about:
>
> \version "2.18.2"
>
> \score {
>   \new Staff {
> \set Score.skipBars = ##t
> \override Score.MetronomeMark.extra-spacing-width = #'(-0.0 . 0.4)
> \override Score.MetronomeMark.extra-spacing-height = #'(-inf.0 .
> +inf.0)
> \tempo "Allegro con moto" 4 = 120
> R1*8
> \tempo "Adagio sostenuto" 4 = 50
> R1*8
>   }
> }
>
> Cheers,
> Pierre
>
> 2015-11-03 0:38 GMT+01:00 H. S. Teoh :
>
>> I'm generating parts from an orchestral score, and am running an issue
>> where long tempo markings over collapsed multi-measure rests would force
>> the text to stack up in an ugly way on top of each other. Is there some
>> way of telling lilypond to prefer stretching the horizontal width of the
>> bars instead? Almost minimal example:
>>
>> \version "2.18.2"
>> \score {
>> \new Staff {
>> \set Score.skipBars = ##t
>> \tempo "Allegro con moto" 4 = 120
>> R1*8
>> \tempo "Adagio sostenuto" 4 = 50
>> R1*8
>> }
>> }
>>
>>
>> T
>>
>> --
>> English has the lovely word "defenestrate", meaning "to execute by
>> throwing someone out a window", or more recently "to remove Windows from
>> a computer and replace it with something useful". :-) -- John Cowan
>>
>> ___
>> 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
>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How to force tempo markings on single line

[Pierre Perol-Schneider]

Hi,
How about:

\version "2.18.2"

\score {
  \new Staff {
\set Score.skipBars = ##t
\override Score.MetronomeMark.extra-spacing-width = #'(-0.0 . 0.4)
\override Score.MetronomeMark.extra-spacing-height = #'(-inf.0 . +inf.0)
\tempo "Allegro con moto" 4 = 120
R1*8
\tempo "Adagio sostenuto" 4 = 50
R1*8
  }
}

Cheers,
Pierre

2015-11-03 0:38 GMT+01:00 H. S. Teoh :

> I'm generating parts from an orchestral score, and am running an issue
> where long tempo markings over collapsed multi-measure rests would force
> the text to stack up in an ugly way on top of each other. Is there some
> way of telling lilypond to prefer stretching the horizontal width of the
> bars instead? Almost minimal example:
>
> \version "2.18.2"
> \score {
> \new Staff {
> \set Score.skipBars = ##t
> \tempo "Allegro con moto" 4 = 120
> R1*8
> \tempo "Adagio sostenuto" 4 = 50
> R1*8
> }
> }
>
>
> T
>
> --
> English has the lovely word "defenestrate", meaning "to execute by
> throwing someone out a window", or more recently "to remove Windows from
> a computer and replace it with something useful". :-) -- John Cowan
>
> ___
> 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: Pair of eyes needed

[tisimst]

Alberto Simões-2 wrote
> Just finished a transcription of a simple piece (four pages, for piano).
> I took all my care to correctly transcribe it, but I would love if 
> someone could help proofreading it.
> ...
> If you are willing to help, you do not need to mess with the lilypond 
> code. You can just annotate somehow the PDF, and I'll fix the code.

Alberto,

Looks pretty good. See my attached PDF for a small handful of specific
comments.

Best,
Abraham

valse-with-comments.pdf
  



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Pair-of-eyes-needed-tp183047p183055.html
Sent from the User mailing list archive at Nabble.com.

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

Using Stem.french-beaming causes segfault

[Jean Menezes da Rocha]

Hello,

I am trying to compile a score and its parts using lilypond version
2.19.30. If I activate french-beaming (using \override Stem.french-beaming
= ##t in the \context \Staff), the program returns a segfault. When
french-beaming is not active, the compilation runs nicely. I have attached
to this message one of the .ly files that is suffering from this problem
(there are others that cause the same issue) and a full output/backtrace
from gdb.
When trying to compile using 2.18.2, the problem is the same.

Thanks for your attention!

-- 
Jean Menezes da Rocha
Compositor
Professor -- Faculdades Est
Mestre e Doutorando em Composição pela Universidade Federal da Bahia

\version "2.18.2"

ufermata = { \once \override Score.RehearsalMark.break-visibility = #begin-of-line-invisible
\mark \markup { \musicglyph #"scripts.ufermata" } 
}

PartPOneVoiceOne = { \relative c{
\numericTimeSignature
\tempo \markup {
  \concat {
"Agitado, obsessivo ("
\smaller \general-align #Y #DOWN \note #"4." #1
" = 84)"
  }
}
\clef "bass" \time 7/8
r2. e8\mf[(
dis->-.)] r d[( cis->-.)] r g[( aes
a!->-.)] r des,4. r8 ees[
\time 5/8
d'!->( cis-.)] r c->[( b-.)]
g->-. r aes[( bes c]
des\staccatissimo) r4 d8->[( ees-.)]
c16->[( des d ees] e8-.) r c,-.[
\time 7/8
g'->] r e'->[( dis-.)] a->[( gis g-.)]
\time 6/8
d'4._\markup{ \dynamic mf \italic espressivo } c
e, a
f'4( \times 2/3 {e16[f e]} dis8-.) r4
cis8-.[ e-. gis-.] d4-> r8
r\mp[ e,-. e-.] r[ e-. e-.]
\time 9/8
e-. r4 r8[ e-. e-.] r[ e-. e-.]
\time 6/8
f'4.\mf ees
\time 9/8
g, des'~ des8 r4
\time 6/8
c,8--[ r16 f8-- r16] r\<[ g( b c e gis 
\time 4/16
a cis e\sfz) r\shortfermata]
\time 7/8
fis8\staccatissimo\sfz r4 r2
e,4\mf( dis cis4.)
c!8->[( des-.)] g,->[( aes-.)] dis,-.[ e-. c-.]
\time 6/8
aes''4.~_\markup{ \italic espressivo } aes!~
aes8-.[ r g~] g16[ fis d8 f]
r8[ e16( f e) c] ees4.
c,8.[ g' a cis]
f4\< \times 2/3 {e16[( f e]} dis4) r8
b4 \times 2/3 {ais16[( b ais]} a!4.)
g8.\f[ d' fis ais]
b8-.[ r ais-.] fis-.[ a-. c,,-.]
g'8.[ d' f! aes]
g4.~ g~
g8 r4 d8^\markup{"pizz."}_\mf[ a e]
d4.\laissezVibrer fis\laissezVibrer
a\laissezVibrer gis\laissezVibrer
r8 gis4 gis gis8
b8 c4 c c8
c,4.\laissezVibrer\sfz c\laissezVibrer\sfz
r4. \times 3/2 { ais'8^\markup{ "arco" }_\markup{ \dynamic mf \italic espressivo }[( b]}
c8[ des c] b-.)[ r g'(]
fis8.[ f e) bes]
a4 c16->[( bes)] f8 e4
d8-.\<[ d16( e fis8-.)] g16[( a bes8-.) c16( des]
\times 3/4 {d8)[ g, c, bes']} \times 3/4 {a8[ a' d, g,]}
c,4.~\!_\markup{ \dynamic sfzp } c
f8->-.\mf[ f( ges] aes8->-.)[ r aes-.]
g[( a bes)] d,[( ees f]
g[a bes)] d,[( ees f]
g4.\<~) g
a-- d--
cis->\f~ cis
R8*6*3
\bar "||"
\time 2/4
\tempo \markup {
  \concat {
(
\smaller \general-align #Y #DOWN \note #"16" #1
" = "
\smaller \general-align #Y #DOWN \note #"16." #1
)
  }
}
e,4..^\markup {"pizz."}_\mf e16
b'4.. c16
a4.. e16
e4\laissezVibrer c'\laissezVibrer
b\laissezVibrer a\laissezVibrer
g4.. g16
e4.. e16
c4.. c16
b'4\laissezVibrer c\laissezVibrer
cis\laissezVibrer fis,\laissezVibrer
e4.. e16
f!4.. f16
fis4.. g16
a4.. b16
e,4\laissezVibrer g\laissezVibrer
c\laissezVibrer fis\laissezVibrer
d\laissezVibrer\< bes\laissezVibrer
g\laissezVibrer e\laissezVibrer
d-.\!_\markup{ \dynamic f \italic sempre } c16[ g' g aes]
aes4-. g16[ d' d ees]
ees8-.[ r16 ees,] d4\laissezVibrer
g-. d'16[ ees ees a]
a4-. d,16[ a' a bes]
bes8-.[ r16 bes,] ees4\laissezVibrer
c,\laissezVibrer f\laissezVibrer
dis\laissezVibrer e\laissezVibrer
gis\laissezVibrer d\laissezVibrer
b'\laissezVibrer ais\laissezVibrer
e\laissezVibrer dis\laissezVibrer
d!-. c16[ g' g aes]
aes4-. g16[ d' d ees]
ees8-.[ r16 ees,] d4\laissezVibrer
g-. d'16[ ees ees a]
a4-. d,16[ a' a bes]
bes8-.[ r16 d,] ees4\laissezVibrer
c,\laissezVibrer f\laissezVibrer
e\laissezVibrer dis\laissezVibrer
gis\laissezVibrer d\laissezVibrer
b'\laissezVibrer ais\laissezVibrer
e\laissezVibrer dis\laissezVibrer
d!\laissezVibrer des\laissezVibrer
c2\laissezVibrer\sfz
c2\laissezVibrer\sfz
d'4--^\markup {"arco"}_\mf bes--
g-- e--(
dis--) b'--
f!--\<( e--
des2\sfz~)
des \bar "||" \ufermata
\cadenzaOn
\override TextScript.extra-offset = #'(0 . 4)
s4*36-\markup {\fill-line {\whiteout \pad-markup #0.5 \bold "TACET - Oboé solo"}}
\revert TextScript.extra-offset
\bar "||" \ufermata
\cadenzaOff
\time 3/4
\tempo \markup {
  \concat {
"Lírico ("
\smaller \general-align #Y #DOWN \note #"4" #1
" ~ 80)"
  }
}
e4_\markup{ \dynamic mf \italic 

Valse des Sylphes - Charles GOUNOD

[Alberto Simões]

Hello

After your precious help, I consider my task of transcribing this music 
complete. Of course, I am happy to fix any issue:


  https://github.com/ambs/music/tree/master/Gounod/ValseDesSylphes

Best regards,
Alberto

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

Re: Valse des Sylphes - Charles GOUNOD

[Malte Meyn]

Hi, I don’t have the time to look at the whole score. But the f sharp in 
m. 1 is wrong. Maybe you or someone else should check again the whole 
piece for correct pitches.


Am 02.11.2015 um 22:44 schrieb Alberto Simões:

Hello

After your precious help, I consider my task of transcribing this music
complete. Of course, I am happy to fix any issue:

   https://github.com/ambs/music/tree/master/Gounod/ValseDesSylphes

Best regards,
Alberto



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

Re: Pair of eyes needed

[Michael Gerdau]

> If you are willing to help, you do not need to mess with the lilypond
> code. You can just annotate somehow the PDF, and I'll fix the code.

I'm not that used to editing in PDF, therefor I will give measures as
of the PDF:

I have found one missing note:
in Bar 169 in the left hand there is missing a c'2. in the chord

The following remarks are more a matter of taste thing:
you have left out quite a few advisory/cautionary accidentials, mostly
for grace notes, that appear in the original:
Bar 38 gis'' grace right hand
Bar 41 cis'' grace right hand
Bar 43 cis'' grace right hand
Bar 49 d''8 right hand (in Bar 43 you have this natural)
Bar 49 cis'' grace right hand (same as in Bar 43)
Bar 76 cis''4 right hand

I'm aware these accidentials/naturals aren't strictly required. However
some may help clarifying the intention.

Bar 121: the cresc hairpin starts 1 quarter note earlier than the original
Bar 124: the decr hairpin ends 1 quarter note earlier than the original
Bar 134: the decr hairpin ends 1 quarter note earlier than the original

For both decr hairpins you could just not end them explicitly (i.e remove
the \!)

I would use whole measure Rests in Bars 157-160 in the left hand by
replacing the r2. with R1*3/4

I would prefix the tie between Bar 162/163 with a '_' to force it
downwards.

Bar 200 the natural in front of the second b''4 could be removed.

Last not least the original had another empty bar in both hands. I don't
know wether that's part of the original manuscript or just for editorial
reasons.

If you decide to add that empty bar, use full bar rests R1*3/4.

Kind regards,
Michael
-- 
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

signature.asc
Description: This is a digitally signed message part.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Valse des Sylphes - Charles GOUNOD

[Michael Gerdau]

> Hi, I don’t have the time to look at the whole score. But the f sharp in
> m. 1 is wrong. Maybe you or someone else should check again the whole
> piece for correct pitches.

Correct and I did not spot that while I did my proofreading...
[I did check the whole piece for correct pitches]

Kind regards,
Michael
-- 
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

signature.asc
Description: This is a digitally signed message part.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

How to force tempo markings on single line

[H. S. Teoh]

I'm generating parts from an orchestral score, and am running an issue
where long tempo markings over collapsed multi-measure rests would force
the text to stack up in an ugly way on top of each other. Is there some
way of telling lilypond to prefer stretching the horizontal width of the
bars instead? Almost minimal example:

\version "2.18.2"
\score {
\new Staff {
\set Score.skipBars = ##t
\tempo "Allegro con moto" 4 = 120
R1*8
\tempo "Adagio sostenuto" 4 = 50
R1*8
}
}


T

-- 
English has the lovely word "defenestrate", meaning "to execute by
throwing someone out a window", or more recently "to remove Windows from
a computer and replace it with something useful". :-) -- John Cowan

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

Re: scholarly/annotate

[Craig Dabelstein]

No problem Urs. Thanks for all you do.

Craig


On Mon, 2 Nov 2015 at 17:54 Urs Liska  wrote:

> Oops, sent instead of saved ...
> I'll have to return to this later.
>
>
> Am 2. November 2015 08:50:39 MEZ, schrieb Urs Liska :
>>
>> Hi Craig,
>>
>> actually I see there's nothing *I* have to look into right now. Rather
>> you should tell me what you would like to achieve. Tell me what - from your
>> experience with an actual project - would be good to have in ScholarLY.
>> While not exactly rich in time I'm more than ready to bring this package
>> further.
>>
>> So far custom properties are just translated into key-value properties to
>> the LaTeX command. It's then the task of LaTeX to do something useful with
>> them. As I said the current set-up simply guarantees that
>>
>> Am 29.10.2015 um 22:58 schrieb Craig Dabelstein:
>>
>> Thanks Urs. I'm working on a 900-page score from 1842 and
>> scholarly/annotate is proving invaluable. Thanks for all your hard work on
>> this.
>>
>> Craig
>>
>>
>> On Thu, 29 Oct 2015 at 18:05 Urs Liska < 
>> u...@openlilylib.org> wrote:
>>
>>> I'll have to try this on a PC, but for now two remarks:
>>>
>>> You seem to have misplaced the space before \transposition so this can't
>>> be expected to produce anything meaningful.
>>>
>>> The custom properties that end up in the optional argument (square
>>> brackets) don't have any implementation so far. This is jzst a state where
>>> you can enter arbitrary stuff in the annotation and have *valid* LaTeX
>>> produced.
>>>
>>> Please remind me if I fail to come back to this.
>>>
>>> Urs
>>>
>>> Am 29. Oktober 2015 08:45:06 MEZ, schrieb Craig Dabelstein <
>>> craig.dabelst...@gmail.com>:
>>>
 Dear Urs (or any other Annotate experts),

 I have created this entry in my input file, taking the idea from the
 example given on git:

 \criticalRemark \with {
 message = "Originally \\textit{Flauti in F} which is an E\flat\
 transposition."
 original-instrument-key = \key ef \major
 original-score-key = \key c \major
   }

 Can anyone tell me how this should translate into the latex file? Is it
 expected to produce a real key signature in the latex file?

 The console output produces:

   \criticalRemark \with {

 Measure 1184, beat 1

 Context: Flute 1

 Affected Item: NoteHead

 Message: Originally \textit{Flauti in F} which is an E\flat\
 transposition.

 original-instrument-key: Key: #

 original-score-key: Key: #


 The .inp file produces:


 \criticalRemark

[original-score-key={Key: #},

 original-instrument-key={Key: #}]

 {1184}{1}

 {Flute 1}

 {NoteHead}

 {Originally \textit{Flauti in F} which is an E\flat\ transposition.}

 How would you have this display in your latex Critical report?

 I hope this makes sense.

 All the best,

 Craig



 *Craig Dabelstein*
 e: craig.dabelst...@gmail.com
 
 

>>> --

 lilypond-user mailing 
 listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user

 -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>>> gesendet.
>>>
>> --
>>
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Using Stem.french-beaming causes segfault

[Jean Menezes da Rocha]

Sorry for replying to my own message so hastily, but making further tests I
may have found something
interesting:
I have many beams going over rests. If I remove every manual beaming over
rests, the problem disappears
and everything works fine (except for the fact that beaming over rests is
important information in my music).
It looks like some bug that breaks the french-beaming functionality when
beams extend over rests. I tried
disabling the stemlets to see if they had anything to do with this issue,
but the segfault persisted.

Best regards!

On Mon, Nov 2, 2015 at 8:07 PM, Jean Menezes da Rocha <
j...@menezesdarocha.info> wrote:

> Hello,
>
> I am trying to compile a score and its parts using lilypond version
> 2.19.30. If I activate french-beaming (using \override Stem.french-beaming
> = ##t in the \context \Staff), the program returns a segfault. When
> french-beaming is not active, the compilation runs nicely. I have attached
> to this message one of the .ly files that is suffering from this problem
> (there are others that cause the same issue) and a full output/backtrace
> from gdb.
> When trying to compile using 2.18.2, the problem is the same.
>
> Thanks for your attention!
>
> --
> Jean Menezes da Rocha
> Compositor
> Professor -- Faculdades Est
> Mestre e Doutorando em Composição pela Universidade Federal da Bahia
>



-- 
Jean Menezes da Rocha
Compositor
Professor -- Faculdades Est
Mestre e Doutorando em Composição pela Universidade Federal da Bahia
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Using Stem.french-beaming causes segfault

[Malte Meyn]

Am 02.11.2015 um 23:07 schrieb Jean Menezes da Rocha:

Hello,

I am trying to compile a score and its parts using lilypond version
2.19.30. If I activate french-beaming (using \override Stem.french-beaming
= ##t in the \context \Staff), the program returns a segfault. When
french-beaming is not active, the compilation runs nicely. I have attached
to this message one of the .ly files that is suffering from this problem
(there are others that cause the same issue) and a full output/backtrace
from gdb.
When trying to compile using 2.18.2, the problem is the same.

Thanks for your attention!



Please try to find a minimal example that produces the same error.
1. Try to reduce it to as few notes as possible (by commenting out large 
chunks of music or even whole staves and testing whether the error still 
appears).
2. Try to reduce unnecessary articulations, clefs, complex score 
structure, paper and layout settings, etc. that don’t contribute to the 
error.


The result can look like this:

\version "2.19.30"

{
  \override Stem.french-beaming = ##t
  r8[ g r]
}

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

Re: Using Stem.french-beaming causes segfault

[Jean Menezes da Rocha]

Thanks for the tip, Malte! When trying to produce a minimal example I was
able to find the exact condition that causes this issue: when a beamed
group of 16ths *ends with* a rest, the segfault is produced.
For instance, the code

\relative c' {
  \override Stem.french-beaming=##t
  c16[ d e r]
}

produces a segfault, while neither

\relative c' {
  \override Stem.french-beaming=##t
  c16[ d e f]
}

or

\relative c' {
  \override Stem.french-beaming=##t
  r16[ d e f]
}

produce the error.

What now???

Thanks for your attention!

On Mon, Nov 2, 2015 at 8:25 PM, Jean Menezes da Rocha <
j...@menezesdarocha.info> wrote:

> Sorry for replying to my own message so hastily, but making further tests
> I may have found something
> interesting:
> I have many beams going over rests. If I remove every manual beaming over
> rests, the problem disappears
> and everything works fine (except for the fact that beaming over rests is
> important information in my music).
> It looks like some bug that breaks the french-beaming functionality when
> beams extend over rests. I tried
> disabling the stemlets to see if they had anything to do with this issue,
> but the segfault persisted.
>
> Best regards!
>
> On Mon, Nov 2, 2015 at 8:07 PM, Jean Menezes da Rocha <
> j...@menezesdarocha.info> wrote:
>
>> Hello,
>>
>> I am trying to compile a score and its parts using lilypond version
>> 2.19.30. If I activate french-beaming (using \override Stem.french-beaming
>> = ##t in the \context \Staff), the program returns a segfault. When
>> french-beaming is not active, the compilation runs nicely. I have attached
>> to this message one of the .ly files that is suffering from this problem
>> (there are others that cause the same issue) and a full output/backtrace
>> from gdb.
>> When trying to compile using 2.18.2, the problem is the same.
>>
>> Thanks for your attention!
>>
>> --
>> Jean Menezes da Rocha
>> Compositor
>> Professor -- Faculdades Est
>> Mestre e Doutorando em Composição pela Universidade Federal da Bahia
>>
>
>
>
> --
> Jean Menezes da Rocha
> Compositor
> Professor -- Faculdades Est
> Mestre e Doutorando em Composição pela Universidade Federal da Bahia
>



-- 
Jean Menezes da Rocha
Compositor
Professor -- Faculdades Est
Mestre e Doutorando em Composição pela Universidade Federal da Bahia
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Pair of eyes needed

[Alberto Simões]

Thank you, and thank you Michael Gerdau too.

Will make fixes later tonight.
Alberto

On 02/11/2015 08:31, tisimst wrote:

Alberto Simões-2 wrote

Just finished a transcription of a simple piece (four pages, for piano).
I took all my care to correctly transcribe it, but I would love if
someone could help proofreading it.
...
If you are willing to help, you do not need to mess with the lilypond
code. You can just annotate somehow the PDF, and I'll fix the code.

Alberto,

Looks pretty good. See my attached PDF for a small handful of specific
comments.

Best,
Abraham

valse-with-comments.pdf




--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Pair-of-eyes-needed-tp183047p183055.html
Sent from the User mailing list archive at Nabble.com.

___
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: Pair of eyes needed

[Alberto Simões]

On 02/11/2015 07:19, Johan Vromans wrote:

On Sun, 1 Nov 2015 21:27:52 +
Alberto Simões  wrote:


If you are willing to help, you do not need to mess with the lilypond
code. You can just annotate somehow the PDF, and I'll fix the code.

Small nitpick: *you* did the transcribing, LilyPond did the typesetting.
"Transcribed with LilyPond" would imply (to me, at least) that you fed the
document to LP and LP did the rest.

Suggested replacement: "Transcribed by Alberto Simões for GNU LilyPond".



it was late in the night, thanks! :-)
Alberto

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

Re: Q regarding best practice with \relative

[Michael Gerdau]

> > Is there something like a "best practice" w/r to the use of \relative?
> > Or why does this difference exist ?

[long and extensive explanation skipped]

> So there's not really a "best practice" but rather one that requires
> least choice-making for those not interested in making more choices than
> necessary.

Thanks alot for this rather detailed explanation. Things now make some
sense to me and I will eventually make up my mind as to which notation
I personally do prefer.

Kind regards,
Michael
-- 
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

signature.asc
Description: This is a digitally signed message part.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user