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 <d...@gnu.org>:
> Christian Masser <christian.mas...@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
>
