Re: Gets the beam collision engraver to handle autobeams (issue4287061)
On Mar 22, 2011, at 7:22 PM, n.putt...@gmail.com wrote: > On 2011/03/20 12:00:34, MikeSol wrote: >> This is now fully functional. >> The only issue is that, for auto-beams, I don't have a good method yet > for >> keeping note-heads that are part of the beam out of the covered grobs > list. >> This is doable, though - I just have to think of the cleanest way. > > Before you attempt that, can you think of a cleaner way to implement the > basic functionality which doesn't involve creating a dummy grob? > > Cheers, > Neil OK, idea: In the auto beam engraver, every time a beam is created, a variable called timestep_ticker_ gets reset to 0 and increments by +1 for every timestep passed until the beam is completed (or junked if the beam is junked). This is stashed as an internal property called "timesteps-spanned." Then, in the beam collision engraver, there is a vector *> called covered_grobs_queue_ that stores vectors of all acknowledged grobs (clefs, note-heads, accidentals, etc.) for a given timestep (with an empty vector being assigned for a acknowledged-grobless timestep). This vector is cleared at every barline (w/ appropriate deletes for the pointers to vectors). When an autobeam is completed (which we'll know because it will be announced during the same timestep as its end-grob), we look at the property timesteps-spanned and iterate through covered_grobs_queue_ starting from covered_grobs_queue_.size () - timesteps_spanned to the end, adding its contents to the grob array covered-grobs. Does this seem like a good idea? It'd need some tweaking to deal w/ covered interior grobs & to avoid code dups, but I think it's clean. Cheers, Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
On Mar 22, 2011, at 11:28 AM, bordage.bertr...@gmail.com wrote:
> Of course, I agree that we should get rid of the two-pass algorithm. But
> it's really tricky to do it the clean way :o\
>
I will jump on the bandwagon here in saying that I too strongly dislike the
two-pass algorithm, but I dislike scrunched footnotes even more. To me, the
question is: is it worth it to have a 40ish-line kludgy implementation of
something as a placeholder for a better implementation, or should one hold out
until the better implementation? Given that the better implementation here
will require revamping how and when top-level markups are calculated (if not
markups in general), which will effect more than just footnotes (it'll have a
benefit for \on-the-fly as well), and given that most users will likely want
automatic numbering, I think it's important to get this in LilyPond before
tackling the markup problem.
> As the issues I pointed out need deep changes, I think the two-pass
> algorithm is better than nothing.
>
Agreed (see above).
> For the moment, we can also avoid these issues by displaying footnotes
> another way.
> For instance (without using this numbering patch) :
>
> \markup \footnote \line { a \raise #0.5 \tiny 1 } \line { 1. b }
> \markup \footnote \line { c \raise #0.5 \tiny 14 } \line { 14. d }
>
> This seems to be a good solution. We can even use this syntax instead :
>
> \markup { a \footnote \raise #0.5 \tiny 1 \line { 1. b } }
>
You're absolutely right. For someone who wants linear footnotes, this is
relatively easy to keep tabs on. For someone who wants footnotes to reset when
pages reset, if they are absolutely certain that a given footnote will fall on
page X, this is doable by hand as well.
> http://codereview.appspot.com/4244064/diff/40002/scm/define-markup-commands.scm
> File scm/define-markup-commands.scm (right):
>
> http://codereview.appspot.com/4244064/diff/40002/scm/define-markup-commands.scm#newcode1856
> scm/define-markup-commands.scm:1856: (markup-y-ext (ly:stencil-extent
> markup-stencil Y))
> Why is this defined ? I can't find its use.
It's vestigial - I'll scrub it.
*Parting Shot*
My approach to footnotes is heavily influenced by my work as a composer, so I
have implemented them based on a way that is useful in contemporary music
scores (I'm thinking Ligeti's Nouvelles aventures). For critical editions,
there are manifold improvements that should be made, such as:
1) The ability for the same symbol in several different places on a page
to apply to the same footnote.
2) As Bertrand previously suggested, the ability for footnotes to be laid
out more compactly.
3) The ability for in-line annotations to be typeset differently (i.e. as
a markup above a note), which is likely doable 100% from scheme and may be more
LSR work than source work.
However, in thinking about all of these things, LilyPond verges dangerously
close on duplicating a lot of functionality that is already part of LaTeX. If
someone wants floats, tables, and equations in their score as well, then at a
certain point, trying to incorporate these things into LilyPond stops making
sense (not unlike David Byrne).
To me, the big question seems: to what extent is it worth it for LilyPond to
implement robust markup functions that make text behave more like it
would/could in TeX-based languages, and if it is worth it, are there any
libraries that will save us the hassle of implementing all this stuff?
Cheers,
MS___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes accidental suggestions in the beam collision engraver (issue4271054)
On Mar 22, 2011, at 9:51 PM, Han-Wen Nienhuys wrote: > On Tue, Mar 22, 2011 at 7:54 PM, Neil Puttock wrote: >> On 22 March 2011 22:48, m...@apollinemike.com wrote: >> >>> Would an acceptable alternative be giving the TrillPitchAccidental the >>> inline-accidental-interface? >> >> Sounds good to me. > > Sorry - I was confused. I was thinking that trill-pitch-interface was > applied to accidentals directly above or below the 'tr' symbol. > > Nevertheless, I think it is good to be explicit about the difference > between accidental-interface (the function of an accidental) and > inline-accidental-interface (the accidental symbols that get printed > on the staff.) Pushed. fe21cb68b77e99a6d0cf89dbf9313400456d1163 Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds automatic numbering to footnotes. (issue4244064)
On Mar 22, 2011, at 7:35 PM, Neil Puttock wrote: > On 10 March 2011 10:06, m...@apollinemike.com wrote: >> On Mar 9, 2011, at 10:17 PM, n.putt...@gmail.com wrote: > >>> Does `annotation-whiteout' do anything special? If not, the existing >>> property `whiteout' should suffice. >>> >> >> It puts a whiteout only around the annotation instead of whiting out the >> entire grob (line + annotation). > > You're only using it for automatic numbering, so it could be > incorporated into the markup command instead. > > If you still think it's necessary though, you need to rethink the way > the whiteout's being applied; currently, you're applying > `stencil-whiteout' to the evaluated markup, then setting 'text to the > new value. You can't do this since it's a property type mismatch: > 'text expects markup, not a stencil. A workaround would be to create a markup in page-layout-problem.cc, in which case my question would be: is there a clean way to create markups on the C++ side, or should I create a public scheme function & call it from the C++ side? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Re: strange instrument name bug
Dear Haipeng, Am Mittwoch, 23. März 2011, 01:01:44 schrieb 胡海鹏 - Hu Haipeng: > I meant to show a bug that the instrument name in the GrandStaff collide > with the instr names in its child staves, but the following file gives no > instr name in the grand staff level, although I find the engraver is added > in the engraver-init.ly. What's wrong? That's simply a bug in lilypond's engraver-init.ly file. In particular, a GrandStaff was allowed to only contain Staff contexts, but no RhythmicStaff. As a consequence, no GrandStaff was ever created (as Francisco also noticed, there was no brace shown, either) and all the RhythmicStaff contexts were placed directly into the StaffGroup... Here is a patch against the latest git version for review by the other developers. If there are no objections, I'll push it in a few days: http://codereview.appspot.com/4275068 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Allow other types of staves than only Staff inside a GrandStaff... (issue4275068)
Applied to 2.13.56 and shows a change in hara-kiri-tabstaff.ly Added issue #1577 on bug-lilypond to track this. http://codereview.appspot.com/4275068/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: strange instrument name bug
On 11-03-23 06:17 AM, Reinhold Kainhofer wrote: Dear Haipeng, Am Mittwoch, 23. März 2011, 01:01:44 schrieb 胡海鹏 - Hu Haipeng: I meant to show a bug that the instrument name in the GrandStaff collide with the instr names in its child staves, but the following file gives no instr name in the grand staff level, although I find the engraver is added in the engraver-init.ly. What's wrong? That's simply a bug in lilypond's engraver-init.ly file. In particular, a GrandStaff was allowed to only contain Staff contexts, but no RhythmicStaff. As a consequence, no GrandStaff was ever created (as Francisco also noticed, there was no brace shown, either) and all the RhythmicStaff contexts were placed directly into the StaffGroup... Here is a patch against the latest git version for review by the other developers. If there are no objections, I'll push it in a few days: http://codereview.appspot.com/4275068 Cheers, Reinhold Added issue 1577 to track, ran basic tests against the patch. We may be setting a speed record here! Colin -- The test of our progress is not whether we add more to the abundance of those who have much, it is whether we provide enough for those who have too little. -Franklin D. Roosevelt, 32nd US President (1882-1945) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 1569: Bad behavior of NoteNames context (issue4312043)
LGTM http://codereview.appspot.com/4312043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: 48-hour notice for small but important fixes
Friday, 1pm. Allow other types of staves than only Staff inside a GrandStaff http://codereview.appspot.com/4275068/ downstem 64th and 128th flag touchup http://codereview.appspot.com/4273074/ Fix 1569: Bad behavior of NoteNames context http://codereview.appspot.com/4312043/ Once those are in, we'll have another release candidate, unless any other Critical issues are discovered between now and then. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Clarification for \null in \header markups
I am making a patch for some updates for Titles and Headers and a para in the doc currently says: "Text fields left unset in a \header block are replaced with \null markups so space is not wasted" Then there is an @c from Mark Polesky asking if this is true? I wondered if anyone knew or if it even matters that we state this or not. James <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
