Open mscuthbert opened 1 year ago
I think it makes sense to have beam slope terminology follow the stem in terms of which way is up (higher on the screen). It's always confusing because 'up is down' in many logical ways (y coordinate for instance).
Ah that does make sense. Maybe it just needs a comment on various places.
Beams applied to notes that are far apart and require stem extensions end up sloping in the wrong direction:
the problem gets worse the farther the notes are off the staff or apart.
I spent about an hour trying to diagnose the problem today, but ran into wall after wall, until a "pre-problem" hit me and that's where I stopped today:
Beam.slope
is backwards (regardless of stem direction) -- a positive Beam.slope value slopes DOWNWARD from left to right, while a negative Beam.slope value slopes UPWARDS! This explained why I couldn't diagnose the problem -- all the outputs from various routines kept looking sane, until I realized at the end that the slopes are pointing in the wrong direction.This misuse of "slope" is probably where the bug crept in -- someone (could've been me...) notices a problem in a particular case and fixes it not realizing that the slope is backwards from what it should be.
I'm willing to work on the problem since it affects my software, but first wondering: for Vexflow 5, can I switch slope so that positive slopes slant upwards and negatives slant downwards? This will likely help me find the bug.
Most use of
slope
is on private or protected variables, but there are a few places where slope is exposed.Myke