Re: autoBeamOff bug
Yes, but manual beaming is really tedious and error-prone, and the
existing autobeaming already does a great job. The standard for vocal
music is to not beam notes unless there is a melisma, and in that case
the same rules apply as for instrumental music. Autobeaming is the
natural solution, and coupling autobeaming with melismas really cleans
up vocal scores. I know this from typesetting 150+ pages using the
style I've described and generating the lilypond input from that. I
started out using manual beaming, and that was really ugly. The score
was dominated by formatting, not by music. Switching to using
melismas and toggling autobeaming helped quite a bit, and adding a
macro to simplify that made the vocal parts as easy to enter as the
instrumental parts.
- Russ
On Apr 3, 2005 10:34 PM, Erlend Aasland [EMAIL PROTECTED] wrote:
On Apr 3, 2005 6:55 PM, Russ Ross [EMAIL PROTECTED] wrote:
Also, what do you think of adding syntax like what I've described to
better support vocal music? a8[[ b c]] d is much more pleasant than
\autoBeamOn a8\melisma c b\melismaEnd \autoBeamOff d, and it is
Did you read the manual (page 13, 83 and 84)? [ and ] sets manual beams:
\autoBeamOff a8 c b c a[ b c] d
Erlend
pretty common in vocal music.
Thanks,
Russ
On Mar 30, 2005 10:25 PM, Russ Ross [EMAIL PROTECTED] wrote:
There seems to be a bug in \autoBeamOff. If it is issued in the
middle of a sequence of notes that would be beamed together, it
doesn't take effect until after the end of that group. It seems that
the correct behavior should be to stop automatic beaming at the point
where the command is issued. It poses a particular problem for me
with some (partially) generated input.
Here's an example showing the problem:
\version 2.5.15
\score {
\relative c' {
\autoBeamOn d'8 cis d b cis b cis ais |
b ais b d~ d \autoBeamOff cis d b |
}
}
The final d cis d b sequence is beamed in the current code, but it
shouldn't be.
Thanks,
Russ
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: autoBeamOff bug
I tried fixing this problem with mixed results. This small patch to
lily/auto-beam-engraver.cc:
267c267,268
if (b)
---
bool on = to_boolean (get_property (autoBeaming));
if (b || !on)
did the job in most instances, but it happened to fail in the first
case I tested, which included an \autoBeamOff immediately followed by
\autoBeamOn. I was hoping to be a break in the beaming at this point,
but since the autoBeaming property had been updated twice by the
time the consider_end function was called, it amounted to a no-op.
In vocal parts, autobeaming generally coincides with melismata. I
usually turn autobeaming off so that a single word or syllable matches
a single, unbeamed note. When a word is held, I turn on a melisma and
I also turn on autobeaming, which matches the conventions of my source
manuscript (Bach). Because this is so common, I use a shorthand in
my own work, namely [[ to start a melisma/autobeaming group, and ]] to
end it. Then I run a perl script to expand those into the
corresponding lilypond commands as part of my build process.
This leads regularly to the situation above, where one melisma group
is followed immediately by another, which manifests itself as
\autoBeamOff followed directly by \autoBeamOn. Note that \noBeam
isn't suitable here, as the notes on both sides may be in beaming
groups.
Is there a way to work around this? Or better yet, a way to fix it?
It seems like autoBeamOff needs to trigger some kind of an event
rather than just setting a property.
Also, what do you think of adding syntax like what I've described to
better support vocal music? a8[[ b c]] d is much more pleasant than
\autoBeamOn a8\melisma c b\melismaEnd \autoBeamOff d, and it is
pretty common in vocal music.
Thanks,
Russ
On Mar 30, 2005 10:25 PM, Russ Ross [EMAIL PROTECTED] wrote:
There seems to be a bug in \autoBeamOff. If it is issued in the
middle of a sequence of notes that would be beamed together, it
doesn't take effect until after the end of that group. It seems that
the correct behavior should be to stop automatic beaming at the point
where the command is issued. It poses a particular problem for me
with some (partially) generated input.
Here's an example showing the problem:
\version 2.5.15
\score {
\relative c' {
\autoBeamOn d'8 cis d b cis b cis ais |
b ais b d~ d \autoBeamOff cis d b |
}
}
The final d cis d b sequence is beamed in the current code, but it
shouldn't be.
Thanks,
Russ
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
autoBeamOff bug
There seems to be a bug in \autoBeamOff. If it is issued in the
middle of a sequence of notes that would be beamed together, it
doesn't take effect until after the end of that group. It seems that
the correct behavior should be to stop automatic beaming at the point
where the command is issued. It poses a particular problem for me
with some (partially) generated input.
Here's an example showing the problem:
\version 2.5.15
\score {
\relative c' {
\autoBeamOn d'8 cis d b cis b cis ais |
b ais b d~ d \autoBeamOff cis d b |
}
}
The final d cis d b sequence is beamed in the current code, but it
shouldn't be.
Thanks,
Russ
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: failed assertion in 2.3.18
I tested 2.3.20 and it still crashes on a bunch of scores. - Russ On Wed, 29 Sep 2004 21:06:39 +0100, Russ Ross [EMAIL PROTECTED] wrote: I'm getting segmentation faults now, with those two scores and with several other smaller ones. Not sure if its related to the fix or something different. I can successfully compile several others, so it is probably something more than a completely broken installation on my machine. One of the scores that causes it to crash is here: http://www.russross.com/music/lilypond-crash.tar.gz It contains two files and can be compiled using: lilypondfullscore.ly This is the full version of the score I used to generate the original test case. It had the failed assert before and has the segfault now. - Russ On Wed, 29 Sep 2004 01:37:22 +0200, Erik Sandberg [EMAIL PROTECTED] wrote: On Thursday 23 September 2004 18.33, Russ Ross wrote: I just compiled 2.3.18 on a Debian system and got this error: lilypond: ../flower/include/array.hh:149: T ArrayT::elem_ref(int) const [with T = void*]: Assertion `i =0isize_' failed. Seems to be fixed in 2.3.19. Can you verify with your big scores? Erik ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: failed assertion in 2.3.18
I'm getting segmentation faults now, with those two scores and with several other smaller ones. Not sure if its related to the fix or something different. I can successfully compile several others, so it is probably something more than a completely broken installation on my machine. One of the scores that causes it to crash is here: http://www.russross.com/music/lilypond-crash.tar.gz It contains two files and can be compiled using: lilypond fullscore.ly This is the full version of the score I used to generate the original test case. It had the failed assert before and has the segfault now. - Russ On Wed, 29 Sep 2004 01:37:22 +0200, Erik Sandberg [EMAIL PROTECTED] wrote: On Thursday 23 September 2004 18.33, Russ Ross wrote: I just compiled 2.3.18 on a Debian system and got this error: lilypond: ../flower/include/array.hh:149: T ArrayT::elem_ref(int) const [with T = void*]: Assertion `i =0isize_' failed. Seems to be fixed in 2.3.19. Can you verify with your big scores? Erik ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
failed assertion in 2.3.18
I just compiled 2.3.18 on a Debian system and got this error:
lilypond: ../flower/include/array.hh:149: T ArrayT::elem_ref(int)
const [with T = void*]: Assertion `i =0isize_' failed.
I got a similar error on 2.2.2 and 2.2.5 under Cygwin. I was working
with a rather large source file, so I started removing parts and
deleting measures until I came up with the smallest example that still
crashed it; if I remove any more measures from this (beginning, end,
or middle), it compiles fine. I haven't tried any changes other than
removing things, so an even simpler example may be possible.
The example is included below.
Thanks,
Russ
\version 2.3.18
sopranoNotes = \relative c'' {
cis4 cis b2~ |
b r |
R1*4 |
r2 e,2 |
fis4 gis a gis |
}
sopranoLyrics = \lyricmode {
schwe -- re B\urd __
wohl
an dem Kreu -- ze
}
organoEContinuoBassNotes = \relative c {
e16( gis) gis( fis) fis( e) e( dis) dis( cis) cis( b) g'4~ |
g16 d-. d( cis) cis( b) b( ais) ais4 r |
r16 b'-. b( fis) fis( a) a( b,) b4 r |
r16 e-. e( b) b( d) d( e,) e4 r |
r16 a'-. a( gis) gis( fis) fis( eis) eis4 r |
r16 fis,-. fis( a) a( cis) cis( e) dis8 e cis a |
cis8 r dis r gis,16 gis'-. gis( fis) fis( e) e( b') |
b4 r8 b, fis'4 r8 gis |
}
\score {
\new StaffGroup \simultaneous {
\context Staff = sopranoStaff
\context Voice = sopranoVoice {
\time 4/4
\clef treble
\key e \major
\sopranoNotes
}
\lyricsto sopranoVoice \new Lyrics \sopranoLyrics
\context Staff = organoEContinuoBassStaff {
\time 4/4
\clef bass
\key e \major
\organoEContinuoBassNotes
}
}
\paper {}
}
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
lyrics problems: Bar_engraver, ß (SS), ü, hyphens
I've just compiled Lilypond 2.3.18 and noticed a couple of differences in lyrics output: Before (in 2.2.x) I'd put this in my \paper section to prevent lyrics overlapping bar lines: \context \LyricsContext \consists Bar_engraver convert-ly changes \LyricsContext to \Lyrics but this no longer seems to work. I now have lyrics overlapping bar lines in numerous old scores. The second things I noticed was with the German ß character which now seems to be rendered SS. Not sure if this is a problem with my setup, or a bug that has been introduced to Lilypond. I'm including ß directly, not using some variation of the TeX/LaTeX \SS. \u used to give a ü character, but now it seems to give a u with a hyphen (or something) overlapping it. Has the syntax for these changed, or do I have something wrong in my setup? Finally, hyphens within words are not always displaying properly. Where before they would be centered between two syllables, now they sometimes stick to the second syllable. These seem to happen generally in my old scores, but if you'd like a specific example of any of these issues I'd be happy to pick out a sample. Thanks, Russ ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lyrics problems: Bar_engraver, ß (SS) , ü, hyphens
Finally, hyphens within words are not always displaying properly.
Where before they would be centered between two syllables, now they
sometimes stick to the second syllable.
I don't think I have seen this problem. Could you find an example?
Certainly; here's a snippet from a recitative that shows the problem:
\version 2.3.18
altoNotes = \relative c'' {
a8 d, c' b b b r fis |
dis dis dis e fis r r b, |
}
altoLyrics = \lyricmode {
J\un -- ger t\o -- richt strei -- ten, daß
die -- ses from -- me Weib mit
}
\score {
\simultaneous {
\context Staff = altoStaff
\context Voice = altoVoice {
\autoBeamOff
\clef treble
\key b \minor
\altoNotes
}
\lyricsto altoVoice \new Lyrics \altoLyrics
}
\paper {}
}
In this example Jün -- ger and tö -- richt both show the problem,
rendering as something like Jün -ger and tö -richt respectively.
If you comment out the second measure, the problem is corrected: as
the first measure expands the hyphens move to the center.
By coincidence, the example also happens to include both a 'ß' and two
'ü's that render incorrectly, which you indicated was a known issue
with character encodings.
Thanks,
Russ
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
heuristics for picking neutral stem directions
I've been setting a large choral/orchestral work and noticed one way in which the default output from LilyPond is suboptimal. I'd like to request a feature to address this, and I think it fits nicely with the philosophy of output being correct by default. When the stem direction of a note or group of notes is neutral (a single note on the middle line or a group like a8[ b c] in the treble clef) the current policy is to always set the direction arbitrarily, either by system default or by user choice. A better default (which could be overriden on demand) would be to have some affinity with the notes around in. In particular, a few rules like: * If the note (or group of notes) is surrounded on both sides by notes with stems in one direction, set the direction of that note or group of notes to match. * If the note is adjacent to a rest on one side and notes on the other side, emulate the stem direction of the adjacent notes. * When the directions of adjacent note stems are different, look for natural boundaries like bar lines, major beats, etc., and favor matching the stem direction of notes with the least significant boundary, i.e., favor changing the stem direction over a measure break or major beat to provide a visual distinction over the break and greater affinity with the other nearby notes. would go a long way to improving the default output. I'm not sure exactly what the rules should be, but even a few simples ones would do a lot of good. I've come across many cases where the default LilyPond output differs in this respect from the classic score I am using as my source. I'm not familiar with the code base, but hopefully this would be a relatively low impact feature as the decisions are all fairly local. Thanks, Russ ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
