Re: Issue 1955 in lilypond: Patch: improving spacing over and below bar lines
Comment #6 on issue 1955 by k-ohara5...@oco.net: Patch: improving spacing over and below bar lines http://code.google.com/p/lilypond/issues/detail?id=1955 Do we want this change? Accidentals folded over the bar line seem to be acceptable. I made a survey using one example I know (Chopin Op28n19). It seems that engravers avoid overhanging the barline if there is space, but act similarly to Lilypond if the line is tight. Attachments: lilypond.png 9.7 KB Peters.png 19.4 KB Durand.png 27.1 KB Breitkopf.png 43.5 KB Schirmer_Kullak.png 15.2 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1955 in lilypond: Patch: improving spacing over and below bar lines
Comment #7 on issue 1955 by mts...@gmail.com: Patch: improving spacing over and below bar lines http://code.google.com/p/lilypond/issues/detail?id=1955 Hey Keith, Maybe I'm looking at the wrong part of the score (I have my eye on the D natural. In every single example it seems as if accidentals are not folded over the barline. I drew lines up from the barline and all of them cleared the accidental except the Schirmer, which lightly touches. I've attached the snippet compiled with the patch (for both compressed and normal spacing). I think that this patch brings LilyPond closer to Durand and Peters. I also think that the only way to have flexibility so that other results like Schirmer can be attained is to have bar-lines aware of accidentals. The spacing spanner and its associated methods can adjust the springs accordingly, but it is better that these accidentals be specially accounted for (in a separate commit after this one) than ignored. Attachments: keith-normal-spacing.png 22.8 KB keith-tight-spacing.png 22.7 KB ___ 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-countdown Patch-needs_work Comment #23 on issue 1567 by pkx1...@gmail.com: Add documentation for footnotes http://code.google.com/p/lilypond/issues/detail?id=1567 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1503 in lilypond: Feature request: simplify jazz chord display
Updates: Labels: -Patch-new Patch-review Comment #20 on issue 1503 by pkx1...@gmail.com: Feature request: simplify jazz chord display http://code.google.com/p/lilypond/issues/detail?id=1503 Passes Make, reg test diffs attached Attachments: Screenshot.png 217 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1572 in lilypond: Change chord name separator and inversion separator, separately
Updates: Labels: -Patch-needs_work Patch-review Comment #11 on issue 1572 by pkx1...@gmail.com: Change chord name separator and inversion separator, separately http://code.google.com/p/lilypond/issues/detail?id=1572 Passes Make, reg test diffs attached James Attachments: Screenshot.png 217 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1986 in lilypond: Patch: Fixes slope errors from incorrect X extents in Beam::print.
Updates: Labels: Patch-new Comment #19 on issue 1986 by mts...@gmail.com: Patch: Fixes slope errors from incorrect X extents in Beam::print. http://code.google.com/p/lilypond/issues/detail?id=1986#c19 Fixes NoteColumn vs SpanBar collisions. http://codereview.appspot.com/5323062 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2000 in lilypond: Patch: Fixes NoteColumn vs SpanBar collisions.
Updates: Labels: Patch-new Comment #9 on issue 2000 by mts...@gmail.com: Patch: Fixes NoteColumn vs SpanBar collisions. http://code.google.com/p/lilypond/issues/detail?id=2000#c9 Fixes NoteColumn vs SpanBar collisions. http://codereview.appspot.com/5323062 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1986 in lilypond: Patch: Fixes slope errors from incorrect X extents in Beam::print.
Comment #20 on issue 1986 by mts...@gmail.com: Patch: Fixes slope errors from incorrect X extents in Beam::print. http://code.google.com/p/lilypond/issues/detail?id=1986 Sorry - please ignore the last comment. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1943 in lilypond: lilypond after 2.15.8 fails on x86 Macs
Comment #21 on issue 1943 by gra...@percival-music.ca: lilypond after 2.15.8 fails on x86 Macs http://code.google.com/p/lilypond/issues/detail?id=1943 I'm open to trying them in the next release, but we can't build releases due to issue 1998. No clue on when that'll be fixed, sorry. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2011 in lilypond: configure doesn't like clang++
Status: Accepted Owner: Labels: Type-Maintainability Frog New issue 2011 by gra...@percival-music.ca: configure doesn't like clang++ http://code.google.com/p/lilypond/issues/detail?id=2011 llvm / clang++ is an awesome new compiler that has much better error checking, and occasionally produces faster code then g++. In my artifastring physical string modeling library, I get a 10% speed-up just from passing CXX=clang++ to configure -- seriously. No code changes, no build system changes; just *poof* 10% faster. lilypond's configure doesn't like that, because we check for GCC = 3.4, whereas llvm is at version 2.9. It would be nice if we did some kind of intelligent checking of this, so that llvm is fine. ../configure CXX=clang++ you can manually avoid this problem by modifying configure.in on lines 94 and 97. (GCC and GXX) I'm mainly interested in clang++ for the error checking. We *know* that we have odd memory problems in lilypond, and there's a lot of positive buzz on the internets about clang's improved error checking. Seems like a useful tool to bash against our code base. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2012 in lilypond: clang warning flower/file-cookie.cc
Status: Accepted Owner: Labels: Type-Maintainability Warning New issue 2012 by gra...@percival-music.ca: clang warning flower/file-cookie.cc http://code.google.com/p/lilypond/issues/detail?id=2012 /home/gperciva/src/lilypond/flower/file-cookie.cc:45:50: warning: implicit conversion changes signedness: 'int' to 'size_t' (aka 'unsigned int') [-Wsign-conversion] return Memory_out_stream::writer (file, buf, i); ~ ^ 1 warning generated. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2013 in lilypond: clang error flower/file-name.cc
Status: Accepted Owner: Labels: Type-Maintainability New issue 2013 by gra...@percival-music.ca: clang error flower/file-name.cc http://code.google.com/p/lilypond/issues/detail?id=2013 anybody know the C++ spec? haha, yeah right, nobody actually knows all the C++ spec. Correction: does anybody know the relevant part of the C++ spec to judge whether this is a valid error or not, and if so, how to fix it? should we just make something explicitly return a (void), or add a variable type, or...? In file included from /home/gperciva/src/lilypond/flower/file-name.cc:21: In file included from /home/gperciva/src/lilypond/flower/include/file-name.hh:23: /home/gperciva/src/lilypond/flower/include/std-vector.hh:197:36: error: 'T' does not refer to a value Compare less = lessT (), ^ /home/gperciva/src/lilypond/flower/include/std-vector.hh:193:19: note: declared here templatetypename T, typename Compare ^ /home/gperciva/src/lilypond/flower/include/std-vector.hh:197:40: error: expected expression Compare less = lessT (), ^ 2 errors generated. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2011 in lilypond: configure doesn't like clang++
Comment #1 on issue 2011 by d...@gnu.org: configure doesn't like clang++ http://code.google.com/p/lilypond/issues/detail?id=2011 I think the primary test to do here is checking that guile's stack-scanning conservative garbage collector (and its source code) get along with clang++. I should also be surprised if the flower tests throwing g++ 4.6.1 for a loop will be system independent enough to get along with clang++. Actually, the whole yaffut.hh/Boost inheritage seems totally crazy and likely unmaintainable to me. Perhaps we should file an issue for replacing it with something doing the intended job rather than something much more complex and unfathomable that is supposed to also cover our needs by accident. So it would be a good opportunity to throw that out, anyway. Throwing guile out, in contrast, seems more challenging. So it really is necessary to check its compatibility with clang++, or we have a non-starter. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2013 in lilypond: clang error flower/file-name.cc
Comment #1 on issue 2013 by d...@gnu.org: clang error flower/file-name.cc http://code.google.com/p/lilypond/issues/detail?id=2013 Uh, you _are_ aware that g++ throws tons of warnings on those files? If someone actually heeded the warnings, maybe clang++ would not be as sad about those files. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2013 in lilypond: clang error flower/file-name.cc
Comment #2 on issue 2013 by gra...@percival-music.ca: clang error flower/file-name.cc http://code.google.com/p/lilypond/issues/detail?id=2013 no, I was not aware. I thought that we'd already dealt with all g++ warnings on our code base. (maybe it was just that we'd done all warnings when we didn't include -Wall or -Wextra ?) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2013 in lilypond: clang error flower/file-name.cc
Comment #3 on issue 2013 by d...@gnu.org: clang error flower/file-name.cc http://code.google.com/p/lilypond/issues/detail?id=2013 make check in the flower subdirectory is the real offender here. Fortunately, it is quite fast. _If_ someone wanted to tackle this, he gets fast feedback from the compiler. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1955 in lilypond: Patch: improving spacing over and below bar lines
Comment #8 on issue 1955 by k-ohara5...@oco.net: Patch: improving spacing over and below bar lines http://code.google.com/p/lilypond/issues/detail?id=1955 Yep. Most of the examples I found use more space after the barline than LilyPond does. This makes the natural clear the extended barline without any extra space. However, out of these examples, only Breitkopf adjusted note-spacing to avoid hanging the accidental over the bar line. I couldn't find any other examples with a fatter accidental like a sharp on a high ledger line. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2011 in lilypond: configure doesn't like clang++
Comment #2 on issue 2011 by lemzw...@gmail.com: configure doesn't like clang++ http://code.google.com/p/lilypond/issues/detail?id=2011 Maybe this helps? http://git.savannah.gnu.org/cgit/autoconf-archive.git/tree/m4/ax_compiler_vendor.m4 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1955 in lilypond: Patch: improving spacing over and below bar lines
Comment #9 on issue 1955 by d...@gnu.org: Patch: improving spacing over and below bar lines http://code.google.com/p/lilypond/issues/detail?id=1955 This is all about visual balance. Accidentals usually are not a significant part of the optical structure, so letting them overhang other structures is totally natural. Things become different when the structures they overhang are close enough that they interact more visually with the accidental than with the supporting structure. In that case, you need to establish a distance that is about equally annoying as the increased distance between the base structures. So you have a balance between near-field interaction (like accidental/barline) and far-field interaction (like stem/barline). The near-field interaction gets weak with additional vertical distance (you don't want to let an accidental overhang right over a barline, but if it is far away, it does not matter that much). How much vertical distance? Depends on the verticality of the overhanging structure. Things like text and accidentals are not all that vertical. Stems are. So as a rough measure, take the spine of the overhanging structure. Take the vertical distance of its lower end to the aligning structure (like the barline). Divide by the height of spine. Multiply by the width of the spine. Multiply by a fudge factor to be determined by drinking lots of beer and staring at various overhanging pictures. That's the basic amount of overhang you can administer. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1503 in lilypond: Feature request: simplify jazz chord display
Comment #21 on issue 1503 by adam.spi...@gmail.com: Feature request: simplify jazz chord display http://code.google.com/p/lilypond/issues/detail?id=1503 Damnit. The last of the three diffs should not be there. I saw it during intermediate testing, and mentioned it in comment #15, but then it vanished when I did a final regression test run, so I assumed it was gone and deleted comment #15 to reduce noise. But looking back at the code now, I think I see why it's happening. I'll test a fix now ... ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1503 in lilypond: Feature request: simplify jazz chord display
Updates: Labels: -Patch-review Patch-needs_work Comment #22 on issue 1503 by carl.d.s...@gmail.com: Feature request: simplify jazz chord display http://code.google.com/p/lilypond/issues/detail?id=1503 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1572 in lilypond: Change chord name separator and inversion separator, separately
Updates: Labels: -Patch-review Patch-needs_work Comment #12 on issue 1572 by carl.d.s...@gmail.com: Change chord name separator and inversion separator, separately http://code.google.com/p/lilypond/issues/detail?id=1572 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1503 in lilypond: Feature request: simplify jazz chord display
Comment #23 on issue 1503 by adam.spi...@gmail.com: Feature request: simplify jazz chord display http://code.google.com/p/lilypond/issues/detail?id=1503 Yup, here's the fix: https://github.com/aspiers/lilypond/commit/6cd091dc39755c0b0cd1eeadc692530c846f78a8 Ideally that should be squashed back into the commit whose message is add slashChordSeparator, so that no single commit breaks the regression tests, but depending on how you handle this Rietveld issue, that may or may not be possible - I'll leave it up to you because I'm still learning the process. P.S. The above commit is in my github 'jazz' branch which I already rebased against the latest dev/staging. Probably doesn't make a difference but I thought I'd mention just in case. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2012 in lilypond: clang warning flower/file-cookie.cc
Comment #1 on issue 2012 by reinhold...@gmail.com: clang warning flower/file-cookie.cc http://code.google.com/p/lilypond/issues/detail?id=2012 That should be fixed by my second patch for issue 1890 (which I haven't yet had the time to commit, although it went through the countdown already)... ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2013 in lilypond: clang error flower/file-name.cc
Comment #5 on issue 2013 by reinhold...@gmail.com: clang error flower/file-name.cc http://code.google.com/p/lilypond/issues/detail?id=2013 Ah, I never looked at make check... A normal make triggers just 1 warning on 64bit an no warning on 32bit systems in the flower/ dir... Once I get a working lily build on myh updated ubuntu boxes (32 bit systems always crash randomly during mke or makeeiric), I might take a look. But I fully agree with David that the whole boost stuff should be thrown out soner rather than later. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2013 in lilypond: clang error flower/file-name.cc
Comment #6 on issue 2013 by reinhold...@gmail.com: clang error flower/file-name.cc http://code.google.com/p/lilypond/issues/detail?id=2013 Ah, I never looked at make check... A normal make triggers just 1 warning on 64bit an no warning on 32bit systems in the flower/ dir... Once I get a working lily build on myh updated ubuntu boxes (32 bit systems always crash randomly during mke or makeeiric), I might take a look. But I fully agree with David that the whole boost stuff should be thrown out soner rather than later. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1503 in lilypond: Feature request: simplify jazz chord display
Updates: Labels: -Patch-needs_work Patch-new Comment #24 on issue 1503 by carl.d.s...@gmail.com: Feature request: simplify jazz chord display http://code.google.com/p/lilypond/issues/detail?id=1503 Revised patch uploaded ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1572 in lilypond: Change chord name separator and inversion separator, separately
Updates: Labels: -Patch-needs_work Patch-new Comment #13 on issue 1572 by carl.d.s...@gmail.com: Change chord name separator and inversion separator, separately http://code.google.com/p/lilypond/issues/detail?id=1572 New patch uploaded ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2013 in lilypond: clang error flower/file-name.cc
Comment #7 on issue 2013 by gra...@percival-music.ca: clang error flower/file-name.cc http://code.google.com/p/lilypond/issues/detail?id=2013 I would rather see us go in the other direction: use more boost. But instead of (apparently?) copying a boost header file from version 1.0, use the installed boost libraries on the system. Many people are using boost, parts of it were accepted to the C++0x TR1 standard, and more parts are submitted for the TR2 standard. I think there's less chance of a serious flaw in boost than the chance of our custom code being flawed. Let's not re-invent the wheel, and let's take advantage of all the optimisations and bug-fixing that has already gone into boost. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2013 in lilypond: clang error flower/file-name.cc
Comment #8 on issue 2013 by d...@gnu.org: clang error flower/file-name.cc http://code.google.com/p/lilypond/issues/detail?id=2013 Please take a look at Issue 1875. The Boost fragment we pulled in and that is apparently used for just make check and nothing else, does an #include cxxabi.h in order to do C++ demangling for some reason. That's a _vast_ amount of complexity we are pulling in just for doing a basic test. And it _fails_ with g++-4.6.1. Just the above-mentioned include makes it fail when linking, except when you omit to generate inline functions. Is this supposed to be a regtest for Boost, for g++, or for Lilypond/flower? And what good is a regtest when nobody understands the complexity of the system and can interpret the failure correctly? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2013 in lilypond: clang error flower/file-name.cc
Comment #9 on issue 2013 by gra...@percival-music.ca: clang error flower/file-name.cc http://code.google.com/p/lilypond/issues/detail?id=2013 yaffut appears to be a small project by Jan and Rutger van Beusekom, which has not been updated since 2006. http://members.home.nl/rutger.van.beusekom/ https://launchpad.net/~yaffut I'd say that yaffut is the *opposite* of using boost. I mean, the idea of boost is to have well-tested, well-reviewed, safe, optimized C++ libraries. yaffut isn't part of boost; it's just calling... wait a moment. Isn't cxxabi.h part of libstdc++, not boost? That's what my google searches are telling me. ok, yaffut.hh says that it's distributed under the boost license, but that's the only boost-ness I can see about it. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2014 in lilypond: Patch: Improve HTML output of regression tests
Status: New Owner: Labels: Type-Enhancement Patch-new New issue 2014 by adam.spi...@gmail.com: Patch: Improve HTML output of regression tests http://code.google.com/p/lilypond/issues/detail?id=2014 Improve HTML output of regression tests - Use Javascript to enable filtering of table rows by type - Make sure git file compare cell contents are HTML-escaped - Fix some HTML validation issues http://codereview.appspot.com/5342042 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2013 in lilypond: clang error flower/file-name.cc
Comment #10 on issue 2013 by d...@gnu.org: clang error flower/file-name.cc http://code.google.com/p/lilypond/issues/detail?id=2013 Maybe. Anyway, the whole testing stuff including yaffut is, regardless of its nominal size, of eyes-glaze-over complexity. Totally going wild with templates, and going overboard with C++ demangling and what not. It is the sort of code we would _never_ want to admit into Lilypond itself because noone could hope to maintain it. And now we are plagued with having to debug this instead of the stuff it is supposed to be testing. Does not appeal to me. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2013 in lilypond: clang error flower/file-name.cc
Comment #11 on issue 2013 by gra...@percival-music.ca: clang error flower/file-name.cc http://code.google.com/p/lilypond/issues/detail?id=2013 agreed. And... unless my old eyes are fooling me... the .hh file contains an int main(), which returns an instance of the yaffut Factory? huh? I had no clue you could even *have* an int main() which returned a pointer. Or is this an abuse of the C or C++ standard? ... you know, I'm honestly wondering if yaffut.hh was a deliberate entry to the obfuscated C contest, or written on a dare while drunk and/or high. It really smells like the kind of thing that could be done in 50 lines of python (or perl, if that's your thing). I mean, what *is* that file doing? It only appears to be used in flower/test-file-name.cc... surely we don't have yaffut.hh in our source tree just to check if we can handle various types of filenames ??? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2015 in lilypond: Patch: Usability improvements to {doc,cg}-section.sh and corresponding section of CG
Status: New
Owner:
New issue 2015 by adam.spi...@gmail.com: Patch: Usability improvements to
{doc,cg}-section.sh and corresponding section of CG
http://code.google.com/p/lilypond/issues/detail?id=2015
Usability improvements to {doc,cg}-section.sh and corresponding section of
CG.
- Now honor LILYPOND_GIT, LILYPOND_BUILD_DIR, and LILYPOND_TEMPDOCS
environment variables (all optional).
- Provide usage help text if '-h' or '--help' or incorrect arguments
are passed.
- Output more helpful messages upon completion.
http://codereview.appspot.com/5342043/
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
No Midi Sound With Short Polyphonic Percussion Notation
Hey there!
There are at least three ways to enter polyphonic percussion music (see
examples below). However the first (easiest) approach does not produce any Midi
output in polyphonic parts.
% first example - no midi output starting from bar 2
\version 2.14.2
\score {
\new DrumStaff
\drummode {
bd4 sn4 bd4 sn4
{
\repeat unfold 16 hh16
} \\ {
bd4 sn4 bd4 sn4
}
}
\midi { }
\layout { }
}
% second example - no problem here
\version 2.14.2
\score {
\new DrumStaff
\new DrumVoice {
\drummode {
bd4 sn4 bd4 sn4
{
\voiceOne
\repeat unfold 16 hh16
}
\new DrumVoice {
\voiceTwo
bd4 sn4 bd4 sn4
}
}
}
\midi { }
\layout { }
}
% third example - no problem here
\version 2.14.2
\score {
\new DrumStaff
\new DrumVoice {
\drummode {
\oneVoice
bd4 sn4 bd4 sn4
\voiceOne
\repeat unfold 16 hh16
}
}
\new DrumVoice {
\drummode {
\voiceTwo
s1 bd4 sn4 bd4 sn4
}
}
\midi { }
\layout { }
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1955 in lilypond: Patch: improving spacing over and below bar lines
Comment #10 on issue 1955 by k-ohara5...@oco.net: Patch: improving spacing over and below bar lines http://code.google.com/p/lilypond/issues/detail?id=1955 LilyPond currently does something less sophisticated. There are beveled margins (yellow and blue lines) around bar lines and clefs and such, whose size is defined by 'skyline-vertical-padding. Graphical elements that clear these margins (or that stay out of the way like text and dynamics) may pass over the bar line. The problem comes with graphical elements from other staff-like contexts, especially Lyrics, because LilyPond has not yet decided how far away they will be. She tentatively assumes that Lyrics will be far enough from the staves to clear everything after the font-matter, but does not yet allow for the 'skyline-vertical-padding. In cases where the beveled margins extend beyond everything else on the staff, they can catch Lyrics, like the through above. Mike's patch (now at http://codereview.appspot.com/5323062) would replace the 'skyline-vertical-padding with an adaptive 'extra-spacing-height that prevents notes from moving over/under. It saves the trouble of considering Span Bars (issue 2000). Attachments: 1955.png 15.3 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2000 in lilypond: Patch: Fixes NoteColumn vs SpanBar collisions.
Updates: Labels: -Patch-new Patch-review Comment #10 on issue 2000 by pkx1...@gmail.com: Patch: Fixes NoteColumn vs SpanBar collisions. http://code.google.com/p/lilypond/issues/detail?id=2000 Passes Make but lots of reg test diffs http://lilypond-stuff.1065243.n5.nabble.com/Tracker-issue-2000-reg-test-diffs-td4962666.html James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1986 in lilypond: Patch: Fixes slope errors from incorrect X extents in Beam::print.
Updates: Labels: -Patch-new Patch-needs_work Comment #21 on issue 1986 by pkx1...@gmail.com: Patch: Fixes slope errors from incorrect X extents in Beam::print. http://code.google.com/p/lilypond/issues/detail?id=1986 Assume mistake last comment also means patch is still needing work after Keith's last comment http://codereview.appspot.com/5293060 James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1503 in lilypond: Feature request: simplify jazz chord display
Updates: Labels: -Patch-new Patch-needs_work Comment #25 on issue 1503 by pkx1...@gmail.com: Feature request: simplify jazz chord display http://code.google.com/p/lilypond/issues/detail?id=1503 Carl, sorry patch needs rebasing again -snip-- jlowe@jlowe-lilybuntu2:~/lilypond-git$ patch -p1 ../Desktop/issue5320074_11001.diff patching file Documentation/included/chord-names-jazz.ly patching file Documentation/notation/chords.itely patching file Documentation/notation/notation-appendices.itely patching file input/regression/chord-additional-pitch-prefix.ly patching file input/regression/chord-name-minor.ly patching file input/regression/chord-slash-separator.ly patching file input/regression/chords-funky-ignatzek.ly patching file ly/chord-modifiers-init.ly Hunk #1 FAILED at 23. Hunk #2 FAILED at 57. 2 out of 2 hunks FAILED -- saving rejects to file ly/chord-modifiers-init.ly.rej patching file ly/engraver-init.ly patching file scm/chord-ignatzek-names.scm patching file scm/define-context-properties.scm --snip-- james ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1572 in lilypond: Change chord name separator and inversion separator, separately
Updates: Labels: -Patch-new Patch-needs_work Comment #14 on issue 1572 by pkx1...@gmail.com: Change chord name separator and inversion separator, separately http://code.google.com/p/lilypond/issues/detail?id=1572 Carl, sorry patch needs rebasing again -snip-- jlowe@jlowe-lilybuntu2:~/lilypond-git$ patch -p1 ../Desktop/issue5320074_11001.diff patching file Documentation/included/chord-names-jazz.ly patching file Documentation/notation/chords.itely patching file Documentation/notation/notation-appendices.itely patching file input/regression/chord-additional-pitch-prefix.ly patching file input/regression/chord-name-minor.ly patching file input/regression/chord-slash-separator.ly patching file input/regression/chords-funky-ignatzek.ly patching file ly/chord-modifiers-init.ly Hunk #1 FAILED at 23. Hunk #2 FAILED at 57. 2 out of 2 hunks FAILED -- saving rejects to file ly/chord-modifiers-init.ly.rej patching file ly/engraver-init.ly patching file scm/chord-ignatzek-names.scm patching file scm/define-context-properties.scm --snip-- ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2014 in lilypond: Patch: Improve HTML output of regression tests
Updates: Status: Started Owner: adam.spi...@gmail.com Labels: -Patch-new Patch-review Comment #1 on issue 2014 by pkx1...@gmail.com: Patch: Improve HTML output of regression tests http://code.google.com/p/lilypond/issues/detail?id=2014 Passes make and no reg test diffs. James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1986 in lilypond: Patch: Fixes slope errors from incorrect X extents in Beam::print.
Updates: Labels: Patch-new Comment #22 on issue 1986 by mts...@gmail.com: Patch: Fixes slope errors from incorrect X extents in Beam::print. http://code.google.com/p/lilypond/issues/detail?id=1986#c22 Fixes slope errors from incorrect X extents in Beam::print. http://codereview.appspot.com/5293060 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2001 in lilypond: Patch: Patch series (available at branch dev/syntax) for more argument list power.
Updates: Labels: Patch-new Comment #5 on issue 2001 by d...@gnu.org: Patch: Patch series (available at branch dev/syntax) for more argument list power. http://code.google.com/p/lilypond/issues/detail?id=2001#c5 Patch series (available at branch dev/syntax) for more argument list power. Consists of the following patches in reverse order: programming-interface.itely: Explain new optional argument semantics and \default parser.yy et al: make \mark a musicfunction. parser.yy et al: make \time and \times musicfunctions. Replace \key with music function input/regression/optional-args-backup.ly: Test backing up of optional argument parts. Use the new fraction? predicate where appropriate. Implement fraction? predicate checking for pair of unsigned integers parser.yy: Allow numbers, fractions and \default as arguments. Common parts of function_arglist and function_arglist_closed are also factored out in order to avoid premature parser decisions. In closed music expressions (mostly in the context of optional arguments), numbers with units (3\cm) and wide fractions (3 / 4) are not recognized, but if the respective number is backed up because of a false predicate, they can still be used in that manner in a mandatory argument. As a consequence of moving most of the optional argument checking into predicates, the operator priority system could be vastly simplified. \default can be used to force the rest of an optional argument block to get skipped. It is the only way to skip optional arguments if they are not followed by a mandatory argument, since otherwise a skipped value could not be interpreted anywhere else in the argument list. parser.yy et al: make UNSIGNED a Scheme value token Move priority of \addlyrics and composite music below function arguments. Needed in order to make closed_music a subset of music recognizable without lookahead. http://codereview.appspot.com/5333051 ___ 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-needs_work Patch-review Comment #24 on issue 1567 by pkx1...@gmail.com: Add documentation for footnotes http://code.google.com/p/lilypond/issues/detail?id=1567 This still needs work but I need some decisions err.. decided and some more input from Mike. James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2001 in lilypond: Patch: Patch series (available at branch dev/syntax) for more argument list power.
Comment #6 on issue 2001 by d...@gnu.org: Patch: Patch series (available at branch dev/syntax) for more argument list power. http://code.google.com/p/lilypond/issues/detail?id=2001#c6 Patch series (available at branch dev/syntax) for more argument list power. Consists of the following patches in reverse order: programming-interface.itely: Explain new optional argument semantics and \default parser.yy et al: make \mark a musicfunction. parser.yy et al: make \time and \times musicfunctions. Replace \key with music function input/regression/optional-args-backup.ly: Test backing up of optional argument parts. Use the new fraction? predicate where appropriate. Implement fraction? predicate checking for pair of unsigned integers parser.yy: Allow numbers, fractions and \default as arguments. Common parts of function_arglist and function_arglist_closed are also factored out in order to avoid premature parser decisions. In closed music expressions (mostly in the context of optional arguments), numbers with units (3\cm) and wide fractions (3 / 4) are not recognized, but if the respective number is backed up because of a false predicate, they can still be used in that manner in a mandatory argument. As a consequence of moving most of the optional argument checking into predicates, the operator priority system could be vastly simplified. \default can be used to force the rest of an optional argument block to get skipped. It is the only way to skip optional arguments if they are not followed by a mandatory argument, since otherwise a skipped value could not be interpreted anywhere else in the argument list. parser.yy et al: make UNSIGNED a Scheme value token Move priority of \addlyrics and composite music below function arguments. Needed in order to make closed_music a subset of music recognizable without lookahead. http://codereview.appspot.com/5333051 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1986 in lilypond: Patch: Fixes slope errors from incorrect X extents in Beam::print.
Updates: Labels: -Patch-new Patch-review Comment #23 on issue 1986 by pkx1...@gmail.com: Patch: Fixes slope errors from incorrect X extents in Beam::print. http://code.google.com/p/lilypond/issues/detail?id=1986 Passes Make but lots of reg test diffs http://lilypond-stuff.1065243.n5.nabble.com/Tracker-1986-reg-tests-td4962636.html James ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1503 in lilypond: Feature request: simplify jazz chord display
Updates: Labels: -Patch-needs_work Patch-new Comment #26 on issue 1503 by carl.d.s...@gmail.com: Feature request: simplify jazz chord display http://code.google.com/p/lilypond/issues/detail?id=1503 Rebased off current master ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1572 in lilypond: Change chord name separator and inversion separator, separately
Updates: Labels: -Patch-needs_work Patch-new Comment #15 on issue 1572 by carl.d.s...@gmail.com: Change chord name separator and inversion separator, separately http://code.google.com/p/lilypond/issues/detail?id=1572 Rebased ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2016 in lilypond: Patch: Test commit -- add .sh file for testing
Status: New Owner: Labels: Type-Enhancement Patch-new New issue 2016 by carl.d.s...@gmail.com: Patch: Test commit -- add .sh file for testing http://code.google.com/p/lilypond/issues/detail?id=2016 Test commit -- add .sh file for testing Remove try and except due to syntax error. Change should only be local. http://codereview.appspot.com/5342046 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2016 in lilypond: Patch: Test commit -- add .sh file for testing
Comment #1 on issue 2016 by carl.d.s...@gmail.com: Patch: Test commit -- add .sh file for testing http://code.google.com/p/lilypond/issues/detail?id=2016 Oops -- I added this by mistake. I'm testing a change in git-cl. I'll delete it when I'm done. Thansk, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2015 in lilypond: Patch: Usability improvements to {doc,cg}-section.sh and corresponding section of CG
Updates:
Labels: Type-Maintainability Patch-needs_work
Comment #1 on issue 2015 by carl.d.s...@gmail.com: Patch: Usability
improvements to {doc,cg}-section.sh and corresponding section of CG
http://code.google.com/p/lilypond/issues/detail?id=2015
Rietveld patch is not uploaded properly because of bad mimetype for .sh
file.
Here's a patch to apply to git-cl, then upload again.
Attachments:
0001-Add-.sh-to-mime-types-for-upload.patch 646 bytes
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2016 in lilypond: Patch: Test commit -- add .sh file for testing
Updates: Status: Verified Comment #2 on issue 2016 by carl.d.s...@gmail.com: Patch: Test commit -- add .sh file for testing http://code.google.com/p/lilypond/issues/detail?id=2016 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
