Re: Suggestion: Use non powers of 2 for tuplets, Suggestion: Use non powers of 2 for tuplets

2021-03-26 Thread Valentin Petzel
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,Suggestion: Use non powers of 2 for tuplets

2021-03-25 Thread Werner LEMBERG


> 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