On 2012-10-07 23:38, Joseph Rushton Wakeling wrote:
On 10/07/2012 11:29 PM, Reinhold Kainhofer wrote:
http://lsr.dsi.unimi.it/LSR/Item?id=482
http://lsr.dsi.unimi.it/LSR/Item?id=817
I implemented those functions for MusicXML import. Note, however, that
lilypond
does not automatically use those, you have to manually set them as
shown in the
snippets.
Do I understand right that these functions are entirely manual overrides
-- that they specify what to print (either a note-value, or the entire
ratio) without reference to the actual tuplet underneath?
No, the formatter functions that I wrote use the tuplet fraction. The
override does not contain the values of the tuplet fraction, just the
note types. E.g.
\once \override TupletNumber #'text =
#(tuplet-number::append-note-wrapper
tuplet-number::calc-denominator-text "4")
\times 2/3 { c8 c8 c8 c8 c8 c8 }
This will print 3{4}, where the 3 comes from the tuplet fraction and
only the base note duration is set in the override.
Or the more general case:
\once \override TupletNumber #'text =
#(tuplet-number::fraction-with-notes "4." "8")
\times 2/3 { c4. c4. c4. c4. }
This will print a tuplet number
3{4.}:2{8}
where the 3 and the 2 comes from the \times command and only the note
durations are specified in the override. There is, however, no check
whether the fraction with the durations makes sense and matches the real
tuplet (in most cases, it will not).
There are, however, also formatter functions that override also the
tuplet fraction.
This is what I'm getting at, you see -- I'd like to see a \tuplet
command that takes the information I've given about the tuplet ratio and
units and translates that _automatically_ into the correct notation.
I don't think that fully automatic tuplet notation will work in all cases.
However, there is certainly enough to think about a more general tuplet
command in lilypond. The formatting functions are already there, what's
missing is the input syntax.
I'm not trying to dismiss your work, it's just that I'm leery of purely
manual notational overrides because there's always a risk of screwing
things up if you later revise the piece and forget to also revise the
override (there's a similar problem IIRC with the current solution to
customized subsidiary beam-breaking).
It's not purely manual overrides... (But still enough rope to hang
yourself in the way you describe).
Cheers,
Reinhold
--
------------------------------------------------------------------
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
