Re: Issue 621 in lilypond: Dynamics should avoid cross-staff BarLines(e.g. GrandStaff, PianoStaff etc)
It is very tempting to make \override DynamicText #'extra-spacing-width = #'(-0.5 . 0.5) be the new default. I have been happily using this, and the regression tests are not harmed by the change. I think this would be a better default. We would need to rewrite the end of Learning Manual section 4.3.3 Tweaking output because it uses essentially this issue as the example needing to be tweaked ! It's section 4.4.3 that would be affected. We'd need to think of another example where it is preferable to space out the notes rather than stack outside-staff objects. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 621 in lilypond: Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff etc)
Comment #5 on issue 621 by perpeduu...@googlemail.com: Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff etc) http://code.google.com/p/lilypond/issues/detail?id=621 +1 for the extra-spacing-width, although it sounds more like a workaround. Can this be related to issue #910? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Eighth rest position dependent on other voice.
I'm not top posting.
Please pardon if this has already been reported;
I couldn't find mention of it in the bug tracker.
Expected Behavior:
When a rest follows a note, it appears on the
same line as the preceding note.
Observed Behavior:
The vertical position of the rest depends on
notes in a different voice. This occurs with
2.14.1 and 2.15.5.
Impact:
In some cases, the rest is pushed into the triplet
bar for no good reason.
In the code below, the rest is where it's expected:
\version 2.15.5
\paper{ ragged-right=##t }
\new Staff
\new Voice { \voiceOne {e''8 r} }
\new Voice { \voiceTwo {a'4} }
In the code below, the rest is higher than expected:
\version 2.15.5 % Also occurs in 2.14.1.
\paper{ ragged-right=##t }
\new Staff
\new Voice { \voiceOne {e''8 r} }
\new Voice { \voiceTwo {c''4} }
In the code below, the rest is where expected:
\version 2.15.5
\paper{ ragged-right=##t }
\new Staff
\new Voice { \voiceOne {e''8 r} }
\new Voice { \voiceTwo {c''8 r} }
The code below demonstrates why this is annoying: the rest is moved up
in a way that seems random
and also hampers readability.
\version 2.15.5
\paper{ ragged-right=##t }
hhRhythm = \drummode {\repeat unfold 4 \times 2/3 { hh8[ r hh] } }
rhythmOne = \drummode {
\override Beam #'damping = #+inf.0
bd4 \times 2/3 { sn8[ r bd] } bd4 sn4
}
\score {
\new DrumStaff
\override Score.SpacingSpanner #'spacing-increment = #5.5
\new DrumVoice = first { \voiceOne \hhRhythm }
\new DrumVoice = second { \voiceTwo \rhythmOne }
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: musicxml2ly.py conversion errors (two)
Ken Kellogg-Smith i.wri...@comcast.net wrote in message news:loom.20110716t012859-...@post.gmane.org... LilyPond version:v2.14.1 musicxml2ly.py file date: 6/12/2011 operating system: Windows XP 2002 SP2 text editor: jEdit I experimented with musicxml2ly by downloading a MusicXML-coded lead sheet (Scott Joplin's The Entertainer ) from the Wikifonia website (www.wikifonia.org). I used the resulting .ly file with LilyPond to create the .pdf sheet music file. I then reviewed musicxml2ly .ly source code, and compared the LY .pdf output file to the outputs of the download file generated by Finale Reader, museScore, and Wikifonia (Ghostwriter pre-release v8.57). Both musicxml2ly output files looked fine, but I did find two discrepancies. One of the discrepancies affected the music notation in the .pdf file, and the other only affected the output .ly source code itself. The discrepancies are as follows: 1. .ly source code: Internal measure numbering errors beginning at (jEdit) line 30 et. seq. musicxml2ly's measure numbering routine made two related discrepancies: (1) at line 30: measure #1 was identified as measure number #2, (2) at line 36: the measure number was duplicated (measure number 5 repeated). (Note: These two discrepancies are 'cosmetic' and had no impact on the .pdf output file. In fact, the second error self-corrected the initial measure numbering error in the .ly source code caused by the first error.) 2. .ly source code: At (jEdit) line 61: the text Fine is incorrectly put in measure 22 instead of measure 21. This discrepancy directly impacted the appearance of the .pdf output file. The correct location of the Fine text is measure 21, where according to the comparison programs it looks like the download file's arranger put it. Although Wikifonia's output file has the text written above the line in the score denoting repeat #2, Finale Reader and museScore both display that text under the line for repeat #2, above the staff, and right justified. The work being done on writing and testing musicxml2ly is very, very impressive! I hope my twi small findings will help a little. Very best regards, Ken Kellogg-Smith Ken, Can you create a minimal example that shows these bugs? -- Phil Holmes Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: musicxml2ly.py conversion errors (two)
Am Samstag, 16. Juli 2011, 01:31:05 schrieb Ken Kellogg-Smith: 1. .ly source code: Internal measure numbering errors beginning at (jEdit) line 30 et. seq. musicxml2ly's measure numbering routine made two related discrepancies: (1) at line 30: measure #1 was identified as measure number #2, (2) at line 36: the measure number was duplicated (measure number 5 repeated). Both are no bugs. The measure number printed is always the number of the NEXT following measure. The reason is that you can then easily replace the % by \barNumberCheck #. And measure number 5 is not repeated for different measures. Rather, it is simply printed twice, once before the \mark and once after the mark, which is, however, at the same barline, so no discrepancy appears. 2. .ly source code: At (jEdit) line 61: the text Fine is incorrectly put in measure 22 instead of measure 21. This discrepancy directly impacted the appearance of the .pdf output file. The problem is that the mxl file uses a simple text markup before a barline, while in LilyPond such text markups can only be attached to notes and the like. Thus, we have to wait for the next note to attach the markup. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Eighth rest position dependent on other voice.
Richard Giraud richa...@richardg.name wrote in message
news:loom.20110716t110250-...@post.gmane.org...
I'm not top posting.
Please pardon if this has already been reported;
I couldn't find mention of it in the bug tracker.
Expected Behavior:
When a rest follows a note, it appears on the
same line as the preceding note.
Observed Behavior:
The vertical position of the rest depends on
notes in a different voice. This occurs with
2.14.1 and 2.15.5.
Impact:
In some cases, the rest is pushed into the triplet
bar for no good reason.
In the code below, the rest is where it's expected:
\version 2.15.5
\paper{ ragged-right=##t }
\new Staff
\new Voice { \voiceOne {e''8 r} }
\new Voice { \voiceTwo {a'4} }
In the code below, the rest is higher than expected:
\version 2.15.5 % Also occurs in 2.14.1.
\paper{ ragged-right=##t }
\new Staff
\new Voice { \voiceOne {e''8 r} }
\new Voice { \voiceTwo {c''4} }
In the code below, the rest is where expected:
\version 2.15.5
\paper{ ragged-right=##t }
\new Staff
\new Voice { \voiceOne {e''8 r} }
\new Voice { \voiceTwo {c''8 r} }
The code below demonstrates why this is annoying: the rest is moved up
in a way that seems random
and also hampers readability.
\version 2.15.5
\paper{ ragged-right=##t }
hhRhythm = \drummode {\repeat unfold 4 \times 2/3 { hh8[ r hh] } }
rhythmOne = \drummode {
\override Beam #'damping = #+inf.0
bd4 \times 2/3 { sn8[ r bd] } bd4 sn4
}
\score {
\new DrumStaff
\override Score.SpacingSpanner #'spacing-increment = #5.5
\new DrumVoice = first { \voiceOne \hhRhythm }
\new DrumVoice = second { \voiceTwo \rhythmOne }
}
It looks to me as if this is correct behaviour. Elaine Gould's notation
manual says that rests can be displaced by the note in the other part, and
this is apparently what's happening. If you want to prevent it, you can use
the notation e''4\rest.
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Partcombine: full bar rests
Le 16/07/2011 03:42, Colin Campbell disait : On 11-07-14 12:14 PM, Jean-Charles Malahieude wrote: Hi all! Using the part combiner, I would prefer not to have to split a multimeasure rest or use tags in order to get what is on the second line. There were several new additions to the basic \partcombine command introduced fairly recently, JeanCharles. Here is a link to the online documents for Automatic Part Combining. I believe that you may find what you need there. Unfortunately not, unless I don't understand it. The structure I have is: 2 oboes, 2 violins, 1 viola, 1 continuo and a SATB choir with soloists. Full score: Oboe and violin 1 play most of the time alternatively and share the same staff. Same goes for oboe and violin 2. Vocal score: Reduction for Violins (combined on the same staff) and continuo (without figures). I there have to use tags in order to switch notes when the second gets higher than the first, and then better manage stems and beaming. And I use two other tags for managing line breaks in full score or parts. Cheers, Jean-Charles ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1766 in lilypond: Checks for grobs with circular parentage in the regtests
Updates: Labels: -Patch-new Patch-review Comment #2 on issue 1766 by pkx1...@gmail.com: Checks for grobs with circular parentage in the regtests http://code.google.com/p/lilypond/issues/detail?id=1766 Make is fine, three reg tests are different - trillspanner ones and 'black box' attached output: Attachments: reg_test.png 147 KB Reg_test_2.png 182 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1766 in lilypond: Checks for grobs with circular parentage in the regtests
Updates: Labels: -Patch-review Patch-needs_work Comment #3 on issue 1766 by percival.music.ca: Checks for grobs with circular parentage in the regtests http://code.google.com/p/lilypond/issues/detail?id=1766 The trillspanner test loses space between the grace noteheads and the following normal note. The previous version reserved space for the final parenthesis; in the new version, that parenthesis collides with the notehead. black-box testing just appears to be weird. I suspect I made a copypaste error; I'll look into this and ignore that test for this comparison. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 621 in lilypond: Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff etc)
Comment #6 on issue 621 by k-ohara5...@oco.net: Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff etc) http://code.google.com/p/lilypond/issues/detail?id=621 although it sounds more like a workaround. Well, the purpose of 'extra-spacing-width' is to specify how much space to allow for the item when spacing columns of notes. The current default for DynamicText says don't allow any horizontal space at all for me; I will move vertically to make room but that strategy does not work for bar-lines. Issue 910 is a little related, but I should probably be solved a different way. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1567 in lilypond: Add documentation for footnotes
Updates: Labels: Patch-review Comment #4 on issue 1567 by pkx1...@gmail.com: Add documentation for footnotes http://code.google.com/p/lilypond/issues/detail?id=1567 Hello, Patch has been uploaded here http://codereview.appspot.com/4751045 Ummm... It's been a while since I used makelsr.py with snippets in ../Documentation/new, and while the patch compiles doc with no problems, the .py script has touched all the other snippets (probably expected) and these have all ended up in the patch as well with their one line changed. Is this right? Anyway..have at it. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
