Hi David!
Fully understanding that you would probably be the one that would (have or
not have to) implement this mess, 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.)
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. (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.
And after all: If the user doesn't like the way the notes are rendered,
there's always the possibility to use the conventional methods of \times
and \tuplet.
Hope this helps to convey my 2 cents a little bit clearer. :)
All the best
Christian
Am Fr., 26. März 2021 um 22:21 Uhr schrieb David Kastrup <d...@gnu.org>:
> Christian Masser <christian.mas...@gmail.com> writes:
>
> > Just adding my two cents to this debate. In my humble opinion it's pretty
> > clear what "12" in this context means as Lilypond's syntax is always
> about
> > the divisor. c4 is always a quarter of a whole note. Therefore c12 would
> > always be a twelth of a whole note, thus a third of a quarter note.
>
> You mean, an eighth triole? Or an eighth sextuplet?
> And c7 would always be a seventh of a whole note.
>
> How would this print? LilyPond does not only produce MIDI, you know.
> With this in mind, why should input like "c3" yield an error if it's
> > otherwise very consistend with the syntax and definitely unambiguous?
>
> It is unambiguous? Is it a half note triplet? Or a sextuplet in 2/1
> time? To be printed with a bracket or not?
> (And the dots also don't pose problems in a mathematical sense, as
> > it's clearly defined, that one dot prolonges the note by a half of
> > it's value, two dots by a half and a quarter and so on.)
>
> You are confusing the sonics with the visuals. LilyPond would not be
> free to replace c4. c4. with \tuplet 2/3 { c4 c4 } and vice versa even
> though the MIDI would sound the same.
> Things like these should be easy in Lilypond, considering it's sheer
> > flexibility and hackability. And if I were a composer writing in 5/6,
> > i would probably be happy if I could just write "c2 d6 e6 |".
>
> Problem is that LilyPond is not the one playing the music, but it
> produces a print that somebody has to play. And when there is no
> notation corresponding to the input, LilyPond will have a hard time
> suggesting how to play things.
>
--
> David Kastrup
>
