Re: Suggestion: Use non powers of 2 for tuplets

[David Kastrup]

Christian Masser <christian.masser@gmail.com> writes:

> Hi David!
>
> Fully understanding that you would probably be the one that would
> (have or not have to) implement this mess,

No, that isn't it.  I am not really all that conservative: there have
been loads of stuff I squeezed into the existing syntax, usually trying
to make sure that it fits logically there.

But LilyPond's concept of durations is solidly married to notational
conventions that are rooted in powers of two.  It is somewhat
normatively rooted in classical conventions (which means that the
representation for things like chant is overly rhythmically rigid and it
doesn't reflect the ambiguities of mensural notation) but in the end the
graphical symbols it picks for representing note lengths are tightly
related to the input, and the internal representation of music, again,
is both representative of the input and the graphical output.

> instead of trying to answer every single question you asked, I'd like
> to make a technical proposal of how those notes could be
> rendered. (And just for context: I very well understand, that Lilypond
> has to display music for other people to play, and I'm one of those
> guys that will try 10-20 different versions of a bar if I get the
> feeling that my idea isn't clearly put to paper - so I do understand
> that there's a difference between "c4. c4." and "\tuplet 2/3 { c4 c4
> }" ).
>
> The major problem behind the concept of single tuplet-parts like "c6" - or
> in the syntax we have right now: "\times 2/3 { c4 }" - is, that our western
> music has no common consensus of how to write unfinished tuplets. The way
> I've seen these written was with a "unfinished" bracket above it. (So the
> small line at the right end of the bracket was missing.) If you're
> interested in it, I should have a picture of the corresponding bars
> somewhere.
>
> My proposal would be:
> a) Display a note with length x using the largest base-2-note smaller than
> it. For example: c3 would be displayed using c2, c5/6/7 using c4,
> c9/10/11/etc. using c8 and so on.
> b) Display them with an open bracket above the note, showing the
> corresponding number above it, no groupings unless....
> c) Use '[' and ']' to manually group those notes. Maybe(!) automise
> grouping whenever note values add up to a base-2-value. (Or for example, if
> the time signature is quarter based, auto-group only when a multiple of a
> quarter is reached. Semi-quaver based? Auto-group only when a multiple of a
> semi-quaver is reached.)

Again: it is not LilyPond's job to invent notation.  If you have a
notation system and want to give LilyPond the capability of reflecting
parts of it in the input, one can see what would be required for making
music functions et al flexible enough to deal with a reasonable input
representation.

But I would consider it a mistake to nail this into a hardwired syntax
with a meaning not rooted in existing conventions.  What are we going to
do when conventions come into being that clash with what LilyPond has
chosen to do?

> I'm sure there are questions and corner cases I haven't thought about,
> but in general this would seem to me as a very sane default way to
> render these elements and I - personally and subjectively - would
> consider it a meaningful addition to Lilypond.

I wouldn't.  This is much more invasive than the
Completion_heads_engraver and we had tons of back-and-forth issues
picking compromise semantics for it (and its behavior is still
discontinuous and intentionally so).  And it is off by default.

> (And I also think that it would be very much in the spirit of
> Lilypond, but who am I to judge THAT?)  I understand at the same time
> that, given there is no convention right now, this might result in
> compatibility problems if in 10, 20 years there would be consensus
> about this and it would look completely different then Lilypond hat
> implemented it - but this is something I highly doubt.

It's not LilyPond's job to invent notation.

No matter who'd pick up the job, I'd consider it a bad idea.

-- 
David Kastrup