Hello Hans,
sorry for the delay. I had private matters to take care of - but in the
meantime I've incorporated several of your thoughts in my document
already ...
Am 11.11.2017 um 22:53 schrieb Hans Åberg:
On 11 Nov 2017, at 22:29, Urs Liska <li...@openlilylib.org> wrote:
Am 11.11.2017 um 22:11 schrieb Hans Åberg:
On 11 Nov 2017, at 21:32, Urs Liska <li...@openlilylib.org> wrote:
AFAICS a tuplet suspends/shadows/interrupts the beatStructure. The regular
processing of the measure should ignore a tuplet, and the tuplet should be
handled separately.
Each full tuplet group behaves like a mini-measure with its own beaming
pattern, though the general structure is the same. The beaming is then as of
the written notes values, not the actual timing values implied.
Exactly. And that's what LilyPond currently (explicitly) does wrong.
I think the feature that one may enter just the note value and not a full
tuplet group leads into the wrong track. If one should have that feature,
I think so, as I've often encountered music with mixed meters of, say,
4/4 plus one eighth triplet (i.e. 4/4 + 1/12).
for correct beaming, one should first reduce it to full tuplet groups, and then
apply its local beatStructure.
I'm not sure how that would apply if the tuplet group isn't complete,
like in my example given in the previous paragraph.
From the results I assume that the beaming code suffers from the same misconception as
the code in beaming-pattern: tuplets are recalculated and processed according to their
*absolute position* in the measure. That means that an event that happens to occur on a
beat of the measure's beat structure is treated like an event on a beat, which is
incorrect. Instead the tuplet should get a "virtual" beat structure.
In the example we have a 3/2 tuplet giving three crotchets over two. So any
beaming (and subdivisions) should be based on an assumed beatStructure of three
crotchets. That way the eight notes would automatically beamed together because
they represent one crotchet.
Each tuplet should have its own local beatStructure. A sextuplet should have by
default a 3 3 beatStructure, if not explicitly overridden.
With sextuplets I've come to the conclusion that it's possible to shorten the
fractions - together with the tupletSpannerDuration.
\tuplet 6/4 4 is equivalent (in terms of beaming) to \tuplet 3/2 8. The same is
true for \tuplet 12/8 4 => \tuplet 3/2 16, so I think it's a general rule.
Hindemith, "Elementary Training", p. 116, suggests that 6 8th notes beamed
together should be musically interpreted as two groups of three 8th notes, which also can
be written as two triplets. However, one can also have the 2+2+2 beaming, in which case
it cannot be reduced to two triplets, instead it is a single one.
So, in LilyPond, I think would be more natural to have a local beatStructure
where one can indicate different pattern like (6), (3 3), (2 2 2), etc.
Generally speaking a tuplet should be treated according to the
visible/generic/unscaled durations of the content while the remaining parts of
the measure simply ignore it, i.e. pick up at their usual Moment after the
tuplet.
Indeed, the beaming is as if the tuplet group did not exist but with a local
beatStructure, taking up the amount notation space as indicated by the tuplet
total time.
This local beatStructure can be inferred from the tuplet definition. If the
tuplet is \tuplet 3/2 4 (as in my initial example) the resulting local
beatStructure is:
- baseMoment 1/4 / 2 = 1/8
- beatStructure #'(3)
A single tuplet always has such an unary beatStructure whose baseMoment is
derived from the tuplet denominator and span, and whose repetition
(beatStructure entry) is the tuplet numerator.
This is just an interpretation for standard CPP music. One can other patterns
as well, if one so like, and that is the case to irregular tuplets, say a
quintuplet could be (5), (2 3) or (3 2), just as for measures.
This is something I hadn't thought of but that makes sense when thinking
about it. I would have seen triplets always as 3*1 and quintuplets
always 5*1, and I'd said a sextuplet *is* another way of writing two
triplets. But of course it would be an unrealistic limitation to
restrict LilyPond to that.
So my current understanding is:
* A tuplet should be treated like a "local measure" with a local
"beatStructure"
* This measure is isolated from the surrounding beatStructure
That means, if a tuplet starts at the second 32th note of a measure,
or at the third quaver of a nested tuplet within a triplet, it will
get its regular local beatStructure, and its beaming and beam
divisions are totally unrelated to where the stems occur in absolute
time.
* The local structure applies to beaming, beam subdivisions, (and more?)
* The tuplet is divided into a number of base moments that direcctly
corresponds to the tuplet numerator. A sextuplet is always divided
into six base moments. (This is different from the regular beat
structure of a measure where we are free to choose arbitrary base
moments.)
* Like with the existing beatStructure there is a default grouping of
base moments into beats per numerator (3, 5, 7 are not grouped by
default, 6 is (3 3), 12 is (3 3 3 3)) but that can be overridden by
the user.
Multiple identical tuplets can either be considered as sequential elements or as a larger
"local measure":
\tuplet 3/2 4 {
c8 c c c c c
}
can also be seen as
- baseMoment 1/8
- beatStructure #'(3 3)
I think suffices to implement beaming for full tuplet groups, each treated as a
separate entity with its own beatStructure. Other things could be implemented
later if so wanted, but for a start, it might just be complication.
What I was talking about is not a question about features but about how
to handle the material as efficiently as possible. The most
straightforward way would probably be to treat every single tuplet as a
single local beat structure. But it might be more efficient to deal with
consecutive equal tuplets as one single entity. But I'm not clear about
that yet.
Urs
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
