Re: Suggestion: Use non powers of 2 for tuplets

[Christian Masser]

Thanks for that lengthy answer, David!

Of course it's easy for me to find pros and cons without having the responsibility over such a big project. At the end of the day it's you devs that watch over the sanity and compatibility of Lilypond - and that's good this way. After all I just wanted to point out some potential positive side aspects where I saw the negative ones well covered, because I (still) think the idea has at least potential. :)

@Martín:

Except when it wouldn’t be easy to notate that way. In a 4/5 time what can easily be notated as \tuplet 5/4 { c2 d4 e4 } (an incomplete tuplet, which is what I would expect to see in print) would have to be notated as "c2,5 d5 e5" using this other notation. Other irrational time signatures would need such decimal numbers for some note values as well. It doesn’t seem to be more practical to deal with decimals than just writing what you intend Lilypond to print, in your case "c2 \tuplet 3/2 {d4 e }".  

When having multiple ways to do things it's always easy to find examples where one way is superior to the other. This in itself does not necessarily lead to one way being worse than the other. (And yes, "c2.5" doesn't make sense at all, even though it would be a mathematically well defined length.)

Anyway, that's more than I ever wanted to say on this topic. Hope you all have a nice weekend!

All the best

Christian

Am Sa., 27. März 2021 um 00:16 Uhr schrieb David Kastrup <dak@gnu.org>:

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