Re: Issue 2205 in lilypond: Breathing sign is positioned incorrectly after changing Staff or TabStaff size
Updates: Status: Fixed Comment #5 on issue 2205 by mts...@gmail.com: Breathing sign is positioned incorrectly after changing Staff or TabStaff size http://code.google.com/p/lilypond/issues/detail?id=2205 Sorry for the delay - pushed as 4e2c5af7db8d46116c25ff7ebf00c39d76c109b3. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1846 in lilypond: Improves horizontal spacing of axis groups that SpanBar grobs traverse
Updates: Status: Fixed Comment #22 on issue 1846 by mts...@gmail.com: Improves horizontal spacing of axis groups that SpanBar grobs traverse http://code.google.com/p/lilypond/issues/detail?id=1846 Pushed as b667b7fe1bf651b7373014204edbe0e68f17326e ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2177 in lilypond: Patch: Reverts public interface for simple spacer.
Updates: Status: Fixed Comment #18 on issue 2177 by mts...@gmail.com: Patch: Reverts public interface for simple spacer. http://code.google.com/p/lilypond/issues/detail?id=2177 Pushed as 50e6c85c2f12b45e02159e344ebc543139204748. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2180 in lilypond: beams are detached from stems
Updates: Status: Fixed Comment #17 on issue 2180 by mts...@gmail.com: beams are detached from stems http://code.google.com/p/lilypond/issues/detail?id=2180 Pushed as 99f6e642e2528e94abc16be12fa8b03590904929. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Tuplet Bracket Spacing Bug
\version "2.15.26"
\score
{
\new Staff \relative c''
{
\times 2/3 {c4\ff c c}
}
}
It looks like the bracket is making space for the dynamic, but the
dynamic is staying outside anyway. The same effect happens with beamed
tuplets, but in that case there's no bracket to move. It was
introduced sometime between 2.15.23 and 2.15.24 (I haven't narrowed it
down to the commit).
-Jay
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2225 in lilypond: Patch: Docs: Explain the difference between ritardando and rallentando
Updates: Labels: -Patch-review Patch-push Comment #3 on issue 2225 by colinpkc...@gmail.com: Patch: Docs: Explain the difference between ritardando and rallentando http://code.google.com/p/lilypond/issues/detail?id=2225 RE Carl's comment on Rietveld: given Patchy's imprimatur, please push. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2180 in lilypond: beams are detached from stems
Updates: Labels: -Patch-countdown Patch-push Comment #16 on issue 2180 by colinpkc...@gmail.com: beams are detached from stems http://code.google.com/p/lilypond/issues/detail?id=2180 Counted down to 20120117, please push. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2177 in lilypond: Patch: Reverts public interface for simple spacer.
Updates: Labels: -Patch-countdown Patch-push Comment #17 on issue 2177 by colinpkc...@gmail.com: Patch: Reverts public interface for simple spacer. http://code.google.com/p/lilypond/issues/detail?id=2177 Counted down to 20120117, please push. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1846 in lilypond: Improves horizontal spacing of axis groups that SpanBar grobs traverse
Updates: Labels: -Patch-countdown Patch-push Comment #21 on issue 1846 by colinpkc...@gmail.com: Improves horizontal spacing of axis groups that SpanBar grobs traverse http://code.google.com/p/lilypond/issues/detail?id=1846 Counted down to 20120117, please push. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2224 in lilypond: LM: clickable examples in the docs have stopped working.
Comment #2 on issue 2224 by julien.r...@gmail.com: LM: clickable examples in the docs have stopped working. http://code.google.com/p/lilypond/issues/detail?id=2224 Investigating points to this commit: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blobdiff;f=python/book_texinfo.py;h=939945164743be1c9c21ac2ce0639654f04a6b8a;hp=03f723754a43619cf055d82d9f89601ffeda3356;hb=81b5ad4f11cdb296c69fcd2259effbc75a3c9054;hpb=f9b28c30a3badc92aaacbb70c56e5114fc1d77ab which changes an explicit ".ly" to %(ext)s, but %(ext)s is the empty string if we look at the code in python/book_texinfo.py: # URG, makeinfo implicitly prepends dot to extension. # Specifying no extension is most robust. rep1['ext'] = '' So I suppose we could revert that part of the commit. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1873 in lilypond: Added glyphs for Kievan Notation
Comment #22 on issue 1873 by janek.li...@gmail.com: Added glyphs for Kievan Notation http://code.google.com/p/lilypond/issues/detail?id=1873 Ok, i understand that a patch file should be sent to James for manual checking. The changes are almost ready, there's only one small thing left - quarter notes glyphs bounding boxes are too small, which results in collision with text markup in attached file. Attachments: note-head-style.pdf 61.3 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2219 in lilypond: Set makeinfo and texi2html error limit to zero
Updates: Labels: -Patch-new Patch-waiting Comment #4 on issue 2219 by julien.r...@gmail.com: Set makeinfo and texi2html error limit to zero http://code.google.com/p/lilypond/issues/detail?id=2219 Waiting for master to catch up with staging ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2219 in lilypond: Set makeinfo and texi2html error limit to zero
Updates: Labels: Patch-new Comment #3 on issue 2219 by julien.r...@gmail.com: Set makeinfo and texi2html error limit to zero http://code.google.com/p/lilypond/issues/detail?id=2219#c3 Build: Strict error checking from makeinfo and texi2html (issue 2219). Run makeinfo and texi2html with --error-limit=0. http://codereview.appspot.com/5554043 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2220 in lilypond: Undefined references to node in translated manuals
Updates: Status: Fixed Labels: Fixed_2_15_27 Comment #5 on issue 2220 by julien.r...@gmail.com: Undefined references to node in translated manuals http://code.google.com/p/lilypond/issues/detail?id=2220 lilypond/translation has been merged into staging, so fixed (although master needs to catch up) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 856 in lilypond: links in Snippets appear to not work for snippets in multiple categories
Updates: Status: Fixed Owner: julien.r...@gmail.com Labels: -Priority-Low Fixed_2_15_25 Comment #2 on issue 856 by julien.r...@gmail.com: links in Snippets appear to not work for snippets in multiple categories http://code.google.com/p/lilypond/issues/detail?id=856 The fix to Issue 2221 fixed this. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1010 in lilypond: extract_texi_filenames misses special node names
Comment #1 on issue 1010 by julien.r...@gmail.com: extract_texi_filenames misses special node names http://code.google.com/p/lilypond/issues/detail?id=1010 ... The set command The-set-command The-set-command ... What should it look like instead? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1985 in lilypond: musicxml2ly: group-symbol none leads to bus error
Updates: Status: Started Labels: Patch-new Comment #1 on issue 1985 by janek.li...@gmail.com: musicxml2ly: group-symbol none leads to bus error http://code.google.com/p/lilypond/issues/detail?id=1985 patch by Patrick Schmidt here: http://codereview.appspot.com/5303063/ ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2229 in lilypond: Patch: Broadcast articulations not in EventChord
Issue 2229: Patch: Broadcast articulations not in EventChord http://code.google.com/p/lilypond/issues/detail?id=2229 This issue is now blocking issue 2070. See http://code.google.com/p/lilypond/issues/detail?id=2070 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2070 in lilypond: Patch: Don't wrap EventChord around rhythmic events by default.
Updates: Blockedon: 2229 Comment #23 on issue 2070 by d...@gnu.org: Patch: Don't wrap EventChord around rhythmic events by default. http://code.google.com/p/lilypond/issues/detail?id=2070 I think I have got the articulation business tackled in issue 2229. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 2229 in lilypond: Patch: Broadcast articulations not in EventChord
Status: New Owner: Labels: Type-Enhancement Patch-new New issue 2229 by d...@gnu.org: Patch: Broadcast articulations not in EventChord http://code.google.com/p/lilypond/issues/detail?id=2229 Broadcast articulations not in EventChord This is in preparation for issue 2070. Should not cause any differences in output with current parser. http://codereview.appspot.com/5528111 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2164 in lilypond: Learning Manual: Better explanation with updated example for \once tweak
Updates: Status: Verified Comment #7 on issue 2164 by elu...@gmail.com: Learning Manual: Better explanation with updated example for \once tweak http://code.google.com/p/lilypond/issues/detail?id=2164 (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 2167 in lilypond: Patch: Doc: selective point and click
Updates: Status: Verified Comment #6 on issue 2167 by elu...@gmail.com: Patch: Doc: selective point and click http://code.google.com/p/lilypond/issues/detail?id=2167 Verified in 2.15.26 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1935 in lilypond: Doc: internal ledger lines need to be documented in NR
Updates: Status: Verified Comment #16 on issue 1935 by elu...@gmail.com: Doc: internal ledger lines need to be documented in NR http://code.google.com/p/lilypond/issues/detail?id=1935 without diving deeper into it I don't catch how it works - but it does! ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2137 in lilypond: Patch: Doc: NR improve 'visibility' of 'q' operation
Updates: Status: Verified Comment #9 on issue 2137 by elu...@gmail.com: Patch: Doc: NR improve 'visibility' of 'q' operation http://code.google.com/p/lilypond/issues/detail?id=2137 (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 2093 in lilypond: Doc: NR alternativeNumberingStyle (fix issue 2059) needs to be documented
Updates: Status: Verified Comment #17 on issue 2093 by elu...@gmail.com: Doc: NR alternativeNumberingStyle (fix issue 2059) needs to be documented http://code.google.com/p/lilypond/issues/detail?id=2093 (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 2163 in lilypond: Web: Added 'Ripple' to easier-editing section
Updates: Status: Verified Comment #3 on issue 2163 by elu...@gmail.com: Web: Added 'Ripple' to easier-editing section http://code.google.com/p/lilypond/issues/detail?id=2163 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: wrong beamlet direction in 6/8 and 3/4 measure for dotted quaver and semiquavers
On 1/17/12 3:33 AM, "Martin Straeten" wrote: >here two examples: >BWV 544: >http://216.129.110.22/files/imglnks/usimg/4/4a/IMSLP01329-BWV0544.pdf >old Edition of Bach Gesellschaft This example shows examples of beaming the 3/8 unit it both two and three. In measures 3-6, the pedal is beamed in three (as LilyPond currently does it), then in measure 7 the pedal is beamed in two (as you have requested), presumably to show the pedal rhythm being different from the manual rhythm (which is in three). In measure 8, it's back to three, then in measure 9, back to two. In measure 13, the manual is beamed in two. In measure 14, the pedal is beamed in three. In measures 29 and 30, both the pedal and the manual are beamed in three. On the top of page 203 (I lost count of the measures), the manual is beamed in three. I have been unable to determine any rule for when it should be beamed in two and when it should be beamed in three. I think that for this piece, the old rule of "minimize the number of beamlets sticking out" would give the beaming in these editions. So perhaps we should add a property to turn on and off the "no beamlets sticking out" rule. Then it would be under user control. Thanks, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1629 in lilypond: Tuplet line collides with fingering
Updates: Status: Verified Comment #7 on issue 1629 by elu...@gmail.com: Tuplet line collides with fingering http://code.google.com/p/lilypond/issues/detail?id=1629 (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 2198 in lilypond: Document use of PATH statement in Windows
Updates: Status: Verified Comment #10 on issue 2198 by elu...@gmail.com: Document use of PATH statement in Windows http://code.google.com/p/lilypond/issues/detail?id=2198 (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 2211 in lilypond: illogical placement of the the Note in AU: -e,--evaluate section
Updates: Status: Verified Comment #2 on issue 2211 by elu...@gmail.com: illogical placement of the the Note in AU: -e,--evaluate section http://code.google.com/p/lilypond/issues/detail?id=2211 (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 2070 in lilypond: Patch: Don't wrap EventChord around rhythmic events by default.
Comment #22 on issue 2070 by d...@gnu.org: Patch: Don't wrap EventChord around rhythmic events by default. http://code.google.com/p/lilypond/issues/detail?id=2070 @mike: of course I'll get the terminology wrong: my amount of knowledge is just sufficient for buzzword juggling. Second option sounds better. I would prefer if I did not need to meddle with the music by tagging on "contained-in-event-chord" (which, if we want to be pedantic, would be the right kind of operation). Is there another way in which the EventChord can report an ArticulationEvent and have the NoteEvent iterator (?) know that it does not need to cater for the ArticulationEvent any more? Perhaps it should just iterate itself through its contained events and call a different iterator, or the same iterator with some "hidden argument"? It would be possible to create a copy of the NoteEvent with all articulations already treated by the EventChord iterator removed, but I would prefer avoiding this kind of additional copying. Just handing the NoteEvent engraver an additional list of ArticulationEvents it should just ignore sounds like a nicer option. It would likely not be a noticeable performance problem if this list was created per-EventChord rather than per-NoteEvent. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2070 in lilypond: Patch: Don't wrap EventChord around rhythmic events by default.
Comment #21 on issue 2070 by m...@apollinemike.com: Patch: Don't wrap
EventChord around rhythmic events by default.
http://code.google.com/p/lilypond/issues/detail?id=2070
Just a pedantic terminological thing: there isn't an EventChord engraver,
just an EventChord iterator. Iterators do different things than engravers
- iterators comb through music events to figure out how to send events to
engravers, and engravers receive events and do things with them.
If you want c-. to behave like -. but not in a context where
rhythmic events are not necessarily wrapped by event chords, after line 49
of event-chord-iterator.cc, you can do something like
mus->set_property("containing-event-chord", get_music ()->self_scm()).
Make sure to define the property in define-music-properties.scm. Then,
when you get to the new-fingering-engraver, you can test note_ev to see if
it has something stashed in the property "containing-event-chord" defined.
If not, that means that the note must be solo, in which case you can treat
the articulation differently.
Another solution would be to create an ArticulationEvent in the
simple-music-iterator if an event has an articulation array. When an event
hits this iterator, check to see if it has an articulation array. If it
does and does not have something set for "containing-event-chord", report
an ArticulationEvent via report_event (you can construct this event through
a Scheme callback).
The second option seems better than the first, as it won't require messing
with the engravers - they'll receive the same information they did before.
It's just that the iterator will create a new event.
I don't have time to test the patch this week, but hopefully that gives you
food for thought for ways to move forward with it.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2213 in lilypond: Update documentation for \footnotes in Notation Reference
Updates: Labels: Patch-review Comment #4 on issue 2213 by lilypond...@gmail.com: Update documentation for \footnotes in Notation Reference http://code.google.com/p/lilypond/issues/detail?id=2213#c4 Patchy the autobot says: LGTM. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2092 in lilypond: lily-git.tcl should using a "working" branch
Updates: Labels: Patch-needs_work Comment #24 on issue 2092 by lilypond...@gmail.com: lily-git.tcl should using a "working" branch http://code.google.com/p/lilypond/issues/detail?id=2092#c24 Patchy the autobot says: patch does not apply to master ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 2070 in lilypond: Patch: Don't wrap EventChord around rhythmic events by default.
Comment #20 on issue 2070 by d...@gnu.org: Patch: Don't wrap EventChord around rhythmic events by default. http://code.google.com/p/lilypond/issues/detail?id=2070 The last patch marks everything that can be an "articulation", namely an event attached to a single note inside of a chord, in a separate music type. The problem I need to address is that currently, c-. is equivalent to -., namely an articulation on a single-note chord, which is different from . We now have the ability of letting music functions operate _inside_ of a chord. A music function \fun with a single music argument can be called as <\fun c-.> and then it gets a single non-chord note event with an articulation. If it is called as \fun c-. outside of a chord, it gets a chord event containing a note-event c and a detached articulation . for the whole chord. Maintaining this context-dependent distinction of the call is not feasible for anything but trivial cases. I have experimented with several things in the front end creating the music expressions. The results add complexity and make things less predictable while providing compatibility for perhaps 80% of all programmatic use cases. So I don't want to do a half-baked job here. And that means that the equivalence c-. <=> -. should not be implemented in the parser. It should be established by the engravers, by having the EventChord engraver switch its children to "engrave as per-note articulation" mode, when they would let their articulations be engraved in "per-chord articulation" mode when outside of an EventChord (something which can currently not happen). This mechanism is not there at the moment. You are discussing what kind of events should inherently be able of doing a per-note reaction, and which kind of event should automatically trigger per-chord mode. And you say "But I don't know if this is really possible or not." It is currently possible (more or less in a hardwired way), and my problem is providing a way to _keep_ this distinction _without_ requiring an EventChord wrapped around even single notes. By implementing it at the engraver/iterator level rather than at they syntactic front end. I want to get to a state where the question "how does the music expression c-. look in Scheme" is not answered with "it depends on whether we are inside a chord or not". I want to have the music expression look the same. Period. The different behavior can then be established in the engravers. Your comment addresses the question "what should be allowed as a per-note articulation". That is not interesting to me right now: I just want to maintain the current behavior. If the current behavior should be changed, the change would look different with the current code, and with the code after this issue passes. Hopefully easier in the second case. But my current problem is not "what should we do", but rather "how". I don't know how to make engravers work differently with articulations inside of an EventChord rather than when encountered without such a wrapper. That's where I need help. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
