#3 beam direction problem

[Dominique Fober]

beams are sometimes going the wrong direction.
The following guido code (or the attached file) illustrates
the problem.
%
% this is to illustrate the beaming problem
% with time signature like 3/8 in the first measure:
% the 16th note stem goes the wrong direction
% the second measure shows an erroneous stem direction
{
[ \clef<"g2"> \meter<"3/8">
f/8. g/16 a/8 b/8 d/16 e/8.
f/16 g/8. a/8
]
}

[Dominique Fober]

beam direction problem gmn file

[Dominique Fober]

Logged In: YES
user_id=657236

to solve the problem, the following should work:
since dates and durations are expresseed as rational numbers;
- let n be the denominator of the note that holds the beam
- let d be the denominator of the note duration
if n < d then the beam should go to the right
else the beam should go to the left

This is intuitively deduced from a rewriting rule that operates as
follow:
the beam direction problem appears when there is a single
beamed note (a 16th note after a dotted eight note for
example)
- rewrite the rythm without dots but using ties
- the beam direction into the rewritten rythm indicates the
direction for the single note.

[Jerome Berthet]

Logged In: YES
user_id=681713

Fixed by adding a method IsSyncopated() in the GREvent
class, and calling it from inside GRBeam.cpp.
IsSyncopated() compares the denominator of the normalized
duration fraction of a note and the denominator of the
non-denormalized fraction of its date. GRBeam call this
method to deduce if a beam should go leftward or rightward
from the stem of the note.

This fix only concerns the graphical representation (GR) of
music. It would be a good idea to have a beam direction cue
calculated and stored in the AR (and maybe a tag to force it).

It works now at least for common cases, it has not been
stress-tested yet.