Re: Suggestion: Use non powers of 2 for tuplets
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 :
> Christian Masser 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
Re: Suggestion: Use non powers of 2 for tuplets
On 3/26/21, 5:41 PM, "lilypond-user on behalf of Valentin Petzel"
wrote:
Your points about beaming and grouping are reasonable, but the idea is not
replacing tuplet with such a notation, but making such notation easier. And
there are many cases where the default grouping by beat structure is pretty
much what you want. In the worst case one can simply group the notes
manually,
which is still much faster than doing lots of different tuplets and hiding
the
Brackets (if you do a piece that frequently changes between division 2 and
division 3 this takes a stupid amount of time!)
You could easily write your own music function to write in division 3.
\inThree {c8 c c}
Or \"in3"{c8 c c}
Or \in³{c8 c c}
Your function could do whatever you would like to do about hiding brackets or
anything else you wanted to do.
And it wouldn't require rewriting LilyPond's parser. Or hardwire
non-conventional notation into LilyPond's core.
Carl
Re: Suggestion: Use non powers of 2 for tuplets
Valentin Petzel writes: > I’m not really sure why you’d call it invasive. It would change > nothing about the way Lilypond works, but just add power to the input > language. The input language is a comparatively direct representation of the music expressions, so you are not adding power to the input language but are declaring a part of the input language that is to bypass LilyPond's concept of music. > Your points about beaming and grouping are reasonable, but the idea is > not replacing tuplet with such a notation, but making such notation > easier. And there are many cases where the default grouping by beat > structure is pretty much what you want. In the worst case one can > simply group the notes manually, which is still much faster than doing > lots of different tuplets and hiding the Brackets (if you do a piece > that frequently changes between division 2 and division 3 this takes a > stupid amount of time!) LilyPond gives you music functions and other tools for programmatically creating music from input, and that is essentially what you want to do here. -- David Kastrup
Re: Suggestion: Use non powers of 2 for tuplets
I’m not really sure why you’d call it invasive. It would change nothing about the way Lilypond works, but just add power to the input language. Your points about beaming and grouping are reasonable, but the idea is not replacing tuplet with such a notation, but making such notation easier. And there are many cases where the default grouping by beat structure is pretty much what you want. In the worst case one can simply group the notes manually, which is still much faster than doing lots of different tuplets and hiding the Brackets (if you do a piece that frequently changes between division 2 and division 3 this takes a stupid amount of time!) Cheers, Valentin signature.asc Description: This is a digitally signed message part.
Re: Suggestion: Use non powers of 2 for tuplets
Christian Masser 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
Re: Suggestion: Use non powers of 2 for tuplets
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 :
> Christian Masser 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
>
Re: Suggestion: Use non powers of 2 for tuplets
> 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 |".
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 }".
—Martín.
www.martinrinconbotero.com (http://www.martinrinconbotero.com)
>
> On Mar 26, 2021 at 10:23 PM, mailto:d...@gnu.org)> wrote:
>
>
>
> Christian Masser (mailto: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
>
>
Re: Suggestion: Use non powers of 2 for tuplets
Christian Masser 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
Re: Suggestion: Use non powers of 2 for tuplets
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. And c7 would always be a seventh of a whole note. With this in mind, why should input like "c3" yield an error if it's otherwise very consistend with the syntax and definitely unambiguous? (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.) On the contrary side, it may lead to all the issues outlined by many of you already, like Lilypond having to define a standard grouping - which probably doesn't align with the grouping of 8th beams - or guess the grouping, and define functions to change it, and so on. Also it almost certainly would introduce new problems users might run into. A practical point of view that also might be considered is the one of contemporary music. Just one example, because I happend to perform the piece, is the opera "Powder her face" by Thomas Adès, that uses e.g. 5/6 time signature (mostly for singular bars, with a lot of time signature changes!) - which looks very odd at beginning. But: once you're through the thought process it's far easier to read than writing "5/4" and adding the relation that "the new quarter note equals a quarter triplet of the bar before" and vice versa after a single bar of music. 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 |". Christian Am Fr., 26. März 2021 um 18:22 Uhr schrieb David Kastrup : > Kevin Barry writes: > > > I think the convenience of this feature does not justify the added > > complexity. > > It's mostly the conceptual vagueness that is the problem here. There > are no actual note values corresponding graphically to the input in an > unambiguous manner, so LilyPond would need to do the equivalent of a > MIDI-to-notation converter in picking a visual representation (and there > are even things like composers disagreeing about whether septuplets are > 7 in the space of 4 or 7 in the space of 8). > > Does 12 mean sextuplets or triplets? What is the meaning of 12.. ? > It's just far too muddy domain to make a major part of the syntax. > > -- > David Kastrup > >
Re: Suggestion: Use non powers of 2 for tuplets
Kevin Barry writes: > I think the convenience of this feature does not justify the added > complexity. It's mostly the conceptual vagueness that is the problem here. There are no actual note values corresponding graphically to the input in an unambiguous manner, so LilyPond would need to do the equivalent of a MIDI-to-notation converter in picking a visual representation (and there are even things like composers disagreeing about whether septuplets are 7 in the space of 4 or 7 in the space of 8). Does 12 mean sextuplets or triplets? What is the meaning of 12.. ? It's just far too muddy domain to make a major part of the syntax. -- David Kastrup
Re: Suggestion: Use non powers of 2 for tuplets
I think the convenience of this feature does not justify the added complexity. Kevin
Re: Suggestion: Use non powers of 2 for tuplets
Le 26/03/2021 à 14:26, Jean Abou Samra a écrit : Le 26/03/2021 à 12:43, Werner LEMBERG a écrit : For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7 for 8*7/8, 9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2 and so on. LilyPond is a notation program first, and your proposal does not map to notation since tuplets also involve choices of beaming and division. There's a lot of music that contains tuplets (mainly triplets) without tuplet numbers. Such a notation would simplify things. I actually fail to see this as a compelling use case. This was an accidentally sent part of a draft of the previous message. Sorry for the noise.
Re: Suggestion: Use non powers of 2 for tuplets
Le 26/03/2021 à 12:43, Werner LEMBERG a écrit : For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7 for 8*7/8, 9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2 and so on. LilyPond is a notation program first, and your proposal does not map to notation since tuplets also involve choices of beaming and division. There's a lot of music that contains tuplets (mainly triplets) without tuplet numbers. Such a notation would simplify things. I actually fail to see this as a compelling use case.
Re: Suggestion: Use non powers of 2 for tuplets
Hello!
Currently Lilypond only supports powers of 2 for specifying duration. Could we
use the other numbers for common divisions?
For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7 for 8*7/8,
9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2 and so on.
This would be quite useful, especially for the divisions of three (*3/2),
because stuff like this
e8*2/3 dis cis cis8. dis16 e8*2/3 dis cis cis8. dis16
Is not really nice to enter, while
e12 dis cis cis8. dis16 e12 dis cis cis8. dis16
would be much less effort.
Cheers, Valentin
Thank you for proposing your ideas! That said,
I admit some skepticism to this particular
proposal, see below.
These things are done during parsing, and I don’t know if there is any way to
pass flags or tokens to the parser. If it is possible, one could try to pass a
rounding flag, or one might even be able to modify this such that the user can
pass a scheme function for parsing. But I do not know enough about the parser
to know if such stuff is possible (the problem here is that the file that is
being parsed would have to tell the parser how to parse it, which can be quite
a hen and egg problem).
The parser does already have such capabilities.
For example, you can define your own note
names -- so why not your own durations after all.
Le 26/03/2021 à 12:43, Werner LEMBERG a écrit :
For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7
for 8*7/8, 9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2
and so on.
LilyPond is a notation program first, and your proposal does not map
to notation since tuplets also involve choices of beaming and
division.
There's a lot of music that contains tuplets (mainly triplets) without
tuplet numbers. Such a notation would simplify things.
In my experience, the triplets in question most often
come in a chain. The three-argument form of \tuplet
(as in \tuplet 3/2 8 { c16 c c c c c }) helps with
those cases.
Having special durations equivalent to multipliers
defeats separation of content and layout through
non-semantic markup since you can't get the tuplet
brackets and numbers back.
I'll also have to admit that my first thought when
reading the original post was: FRACTRAN++!
The point is: smart does not mean user-friendly;
often to the contrary in fact.
Best regards,
Jean
PS: https://esolangs.org/wiki/Fractran++
Re: Suggestion: Use non powers of 2 for tuplets
Werner LEMBERG writes:
>>> For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7
>>> for 8*7/8, 9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2
>>> and so on.
>>
>> LilyPond is a notation program first, and your proposal does not map
>> to notation since tuplets also involve choices of beaming and
>> division.
>
> There's a lot of music that contains tuplets (mainly triplets) without
> tuplet numbers. Such a notation would simplify things.
There are differences in weight and beaming for triplets and sextuplets
that formally come in the same duration. Just like there is a
difference in
\tuplet 2/3 { c4 c4 }
and
{ c4. c4. }
Musical notation (and thus LilyPond) writes down more than what appears
in the MIDI.
--
David Kastrup
Re: Suggestion: Use non powers of 2 for tuplets
>> For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7 >> for 8*7/8, 9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2 >> and so on. > > LilyPond is a notation program first, and your proposal does not map > to notation since tuplets also involve choices of beaming and > division. There's a lot of music that contains tuplets (mainly triplets) without tuplet numbers. Such a notation would simplify things. Werner
Re: Suggestion: Use non powers of 2 for tuplets
Valentin Petzel writes: > Hello! > > Currently Lilypond only supports powers of 2 for specifying > duration. Could we use the other numbers for common divisions? > > For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7 for > 8*7/8, 9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2 and so > on. LilyPond is a notation program first, and your proposal does not map to notation since tuplets also involve choices of beaming and division. > This would be quite useful, especially for the divisions of three (*3/2), > because stuff like this > e8*2/3 dis cis cis8. dis16 e8*2/3 dis cis cis8. dis16 > Is not really nice to enter, It also is distracting to read (even if Baroque autographs tend to omit tuplet numbers like that). Use \tuplet instead. > while e12 dis cis cis8. dis16 e12 dis cis cis8. dis16 would be much > less effort. It does not indicate what note values to use visually. If we only wanted to produce Midi, we'd not need to distinguish cis and des either. -- David Kastrup
Re: Suggestion: Use non powers of 2 for tuplets, Suggestion: Use non powers of 2 for tuplets
Hello Werner, I just suggested these value as this seems to be what is commonly found with music (and it is rhythmically viable nontheless). Basically we’re rounding a division to the nearest power of 2 (it does not make a lot of sense to use 7 4th notes or something like 15 8th notes for such subdivisions, since 7 8th notes or 15 16th notes would be much closer). A pseudo code for this: (number) → (duration): Lower = 2**ilog(number, 2) Upper = Lower*2 If (number - Lower <= Upper - number) return Lower*number/Lower Else return Upper*number/Upper These things are done during parsing, and I don’t know if there is any way to pass flags or tokens to the parser. If it is possible, one could try to pass a rounding flag, or one might even be able to modify this such that the user can pass a scheme function for parsing. But I do not know enough about the parser to know if such stuff is possible (the problem here is that the file that is being parsed would have to tell the parser how to parse it, which can be quite a hen and egg problem). Cheers, Valentin signature.asc Description: This is a digitally signed message part.
Re: Suggestion: Use non powers of 2 for tuplets
Hello, Does \scaleDurations not already fit the bill? See the section "Scaling durations" at http://lilypond.org/doc/v2.22/Documentation/notation-big-page On 2021-03-26 02:19, Valentin Petzel wrote: Hello! Currently Lilypond only supports powers of 2 for specifying duration. Could we use the other numbers for common divisions? For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7 for 8*7/8, 9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2 and so on. This would be quite useful, especially for the divisions of three (*3/2), because stuff like this e8*2/3 dis cis cis8. dis16 e8*2/3 dis cis cis8. dis16 Is not really nice to enter, while e12 dis cis cis8. dis16 e12 dis cis cis8. dis16 would be much less effort. Cheers, Valentin
Re: Suggestion: Use non powers of 2 for tuplets,Suggestion: Use non powers of 2 for tuplets
> Currently Lilypond only supports powers of 2 for specifying > duration. Could we use the other numbers for common divisions? > > For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7 > for 8*7/8, 9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2 > and so on. > > This would be quite useful, especially for the divisions of three > (*3/2), because stuff like this > > e8*2/3 dis cis cis8. dis16 e8*2/3 dis cis cis8. dis16 > > Is not really nice to enter, while > > e12 dis cis cis8. dis16 e12 dis cis cis8. dis16 > > would be much less effort. Sounds like a nice idea. However, I think that your values have a flaw. I think it should rather be 2 3 2*3/2 4 5 4*5/4 6 4*6/4 = 4*3/2 7 4*7/4 <=== 8 9 8*9/8 10 8*10/8 = 8*5/4 11 8*11/8 12 8*12/8 = 8*3/2 ... to be algorithmically derivable. Maybe the user should be able to set up exceptions, but this might need a lot of changes. Werner
Re: Suggestion: Use non powers of 2 for tuplets
You are on your own on that one. I think it just leads to the unpleasant chaos of having to look up what those mean in a table somewhere after you have forgotten why you put that into your score. -Shane On Thu, Mar 25, 2021 at 10:20 PM Valentin Petzel wrote: > Hello! > > Currently Lilypond only supports powers of 2 for specifying duration. > Could we > use the other numbers for common divisions? > > For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7 for > 8*7/8, > 9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2 and so on. > > This would be quite useful, especially for the divisions of three (*3/2), > because stuff like this > e8*2/3 dis cis cis8. dis16 e8*2/3 dis cis cis8. dis16 > Is not really nice to enter, while > e12 dis cis cis8. dis16 e12 dis cis cis8. dis16 > would be much less effort. > > Cheers, Valentin
