Use fractions rather than Scheme pairs for \scaleDuration, timeSignatureFraction et al

Use fractions rather than Scheme pairs for \scaleDuration, timeSignatureFraction et al

[Keith, 2012-05-13 02:43:23]

http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythm...
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythm...
Documentation/notation/rhythms.itely:331: a4*2/3 gis a
Oh yes.  You had asked who were "some people" who use this construction.  It's
not just me this time; I also see it in other people's scores on mutopiaproject.
 
I'll admit that I used it to avoid the Lisp syntax in \scaleDurations #'(2 . 3)

http://codereview.appspot.com/6200068/diff/2001/Documentation/snippets/new/ch...
File
Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly
(right):

http://codereview.appspot.com/6200068/diff/2001/Documentation/snippets/new/ch...
Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly:25:
\scaleDurations 8/5 {
Somehow, this worked before the patch.  Not a problem, just an observation.

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll
File lily/lexer.ll (right):

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode487
lily/lexer.ll:487: {FRACTION}	{
Stupid question, but I can't figure it out.  Can we remove this pattern from the
rules for individual starting states, now that it is matched globally ?

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode528
lily/lexer.ll:528: {FRACTION}	{
?

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode573
lily/lexer.ll:573: {FRACTION}	{
?

[Keith, 2012-05-13 02:43:41]

Nice.

[dak, 2012-05-13 05:57:27]

http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythm...
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythm...
Documentation/notation/rhythms.itely:331: a4*2/3 gis a
On 2012/05/13 02:43:23, Keith wrote:
> Oh yes.  You had asked who were "some people" who use this construction.  It's
> not just me this time; I also see it in other people's scores on
mutopiaproject.
>  
> I'll admit that I used it to avoid the Lisp syntax in \scaleDurations #'(2 .
3)

\scaleDurations 2/3 would have worked from version 2.15.17 on (fractions in
function arguments).  The necessity of parser changes to allow for fractions in
property initializations caught me on the wrong foot: I would have imagined the
first patch set to work already.  This was supposed to be just a documentation
change.

http://codereview.appspot.com/6200068/diff/2001/Documentation/snippets/new/ch...
File
Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly
(right):

http://codereview.appspot.com/6200068/diff/2001/Documentation/snippets/new/ch...
Documentation/snippets/new/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly:25:
\scaleDurations 8/5 {
On 2012/05/13 02:43:23, Keith wrote:
> Somehow, this worked before the patch.  Not a problem, just an observation.

Yup.  As I said: 2.15.17 for function arguments (that's when \times 2/3 ...
became a regular function instead of a reserved word in the parser).

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll
File lily/lexer.ll (right):

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode487
lily/lexer.ll:487: {FRACTION}	{
On 2012/05/13 02:43:23, Keith wrote:
> Stupid question, but I can't figure it out.  Can we remove this pattern from
the
> rules for individual starting states, now that it is matched globally ?

I have not tried it.  We have separate rules for unsigned, possibly because 3.5
can means something else in some modes.  One should probably make sure that in
special situations, like figured bass or chordmode, the global parser change
does not cause trouble.

I have not really given it any thought yet, relying on the regtests to tell me
if I was hitting on the syntax of existing constructs.

If one tried simplifying this, one should make sure that rules still back up.

[janek, 2012-05-13 07:01:55]

I don't know the parser stuff (and no time to figure it out), but docs LGTM.

http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythm...
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/6200068/diff/2001/Documentation/notation/rhythm...
Documentation/notation/rhythms.itely:321: @code{*L*M/N}.  Such alterations
become part of the duration as such; if
"as such" makes me scratch my head.  What about 

"Multiplying factors may be combined: @code{*L*M/N}.  Such alterations become
part of the duration;"

?

[Trevor Daniels, 2012-05-13 07:20:33]

LGTM (with Janek's suggested change)

[Keith, 2012-05-13 18:00:25]

Still Nice.

http://codereview.appspot.com/6200068/diff/8001/Documentation/notation/rhythm...
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/6200068/diff/8001/Documentation/notation/rhythm...
Documentation/notation/rhythms.itely:323: duration taken from the preceding note
includes any scaling factor.
the duration is taken

[dak, 2012-05-14 10:32:11]

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll
File lily/lexer.ll (right):

http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode487
lily/lexer.ll:487: {FRACTION}	{
On 2012/05/13 02:43:23, Keith wrote:
> Stupid question, but I can't figure it out.  Can we remove this pattern from
the
> rules for individual starting states, now that it is matched globally ?

Well, now I tried.

GNU LilyPond 2.15.39
Changing working directory to: `./out-test'
Processing `quantize-duration-2.ly'
Parsing...
/usr/local/tmp/lilypond/input/regression/midi/quantize-duration-2.ly:47:10:
error: syntax error, unexpected '/'
  e'''4*41
          /192 r4*7/192 d4*41/192 r4*7/192 fis,4*89/192 r4*7/192 gis4*89/192 
/usr/local/tmp/lilypond/input/regression/midi/quantize-duration-2.ly:47:19:
error: syntax error, unexpected '/'
  e'''4*41/192 r4*7
                   /192 d4*41/192 r4*7/192 fis,4*89/192 r4*7/192 gis4*89/192 

[...]

So the answer to this question is: no.  Maybe it has to do with the starting
state specific UNSIGNED rules firing with priority then.  I'll try moving the
FRACTION rule up, but am sceptical that this will work out better, so just let's
keep the unchanged countdown on.

[dak, 2012-05-14 11:55:58]

On 2012/05/14 10:32:11, dak wrote:
> 
> So the answer to this question is: no.  Maybe it has to do with the starting
> state specific UNSIGNED rules firing with priority then.  I'll try moving the
> FRACTION rule up, but am sceptical that this will work out better, so just
let's
> keep the unchanged countdown on.

Did not work, either.  So reducing the number of rules is left as an exercise
for an ambitious reader.

[Keith, 2012-05-14 17:13:31]

On Mon, 14 May 2012 03:32:11 -0700, <dak@gnu.org> wrote:

> http://codereview.appspot.com/6200068/diff/2001/lily/lexer.ll#newcode487
> lily/lexer.ll:487: {FRACTION}	{
> On 2012/05/13 02:43:23, Keith wrote:
>> Stupid question, but I can't figure it out.  Can we remove this
> pattern from the
>> rules for individual starting states, now that it is matched globally
> ?

>
> So the answer to this question is: no.  Maybe it has to do with the
> starting state specific UNSIGNED rules firing with priority then.  I'll
> try moving the FRACTION rule up, but am skeptical that this will work
> out better, so just let's keep the unchanged countdown on.
>
> http://codereview.appspot.com/6200068/
>

Oops.  All the start conditions are declared exclusive, so global rules
only match when we are in start condition 'INITIAL'.  <*> rules would
match in comments, which is not wanted, so no combining of rules until
the start conditions that don't need to be exclusive are made inclusive.