Measure-based fixed scaling

[curran]

I believe the "Omniglass" PR #73 kind of implements this - when you click out of the brushed region, the scaling is always constant (the window size is fixed), which I believe is the crux of this feature (if my memory serves me well on what this issue is about).

[seemantk]

@curran, can we close this ticket in that case?

[curran]

@seemantk Actually, I think this is the same as the recent issue that Jesse brought up, where each measure should be a fixed width. I don't think we can close it quite yet.

To clarify, I think to close this ticket we need to make it so the widths of the bars are fixed through the mensuration changes here:

In this screenshot we can see that the width changes (because note time is in terms of beats). When the mensuration changes, apparently the time occupied by one beat also changes, such that the time occupied by one measure stays the same.

I was trying to think of how we can implement this. We'll need to somehow correlate which notes fall into which mensurations, and divide the time (or something) based on which mensuration it is. The simplest way might be to try coming up with a function that will take as input a time in "beat time", and output a time in "absolute time" taking into account mensuration changes. Once we have a function like this, we can just pass all of the start time and end time values through it before rendering.

[curran]

Adding my thoughts/notes on working through the implementation here.

The above is what gets output from

  console.log(proll.barlines.map(function (d){
    return d.mensuration;
  }));

I think this data can be used to scale the time values for the notes.

Assumption: where "mensuration" is undefined, we can assume it has the same value as it did previously.

Assumption: "C|" means 4/4 time signature, "3" means 3/4 time signature.

Idea for implementation: replace the starttime values for all the notes to be in units of "fractions of a measure". How the note gets scaled will depend on the cumulative mensuration changes leading up to that note. Some examples:

Mensuration of "C|" for the first measure:

• 1 → 0
• 2 → 0.25
• 3 → 0.5
• 4 → 0.75

Mensuration of "3" for the first measure:

• 1 → 0
• 2 → 0.3333
• 3 → 0.6666

Once the starttime values are transformed, I believe we can just pass the resulting dataset in through the visualization and everything will "just work" - except the barlines will not be scaled properly.

Actually, this change would greatly simplify how we handle the barlines in terms of rendering them as well as computing their ticks. Since bars will be consistently spaced after this change, we can simply just use standard D3 axes for the lines and labels.

Let's confirm that there's no desire to ever render the piece with beat-based scaling. I'm not 100% sure I should clobber what we have now. Maybe there should be another check box to switch between beat-based scaling and measure-based scaling? This is a question for Jesse I think.

[curran]

As a first step, we can fill in the mensurations for all bars based on the last known value:

  var mensuration;
  console.log(proll.barlines.map(function (d){
    return mensuration = (d.mensuration || mensuration);
  }));

[curran]

Discovered a truism that holds for all bars that may come in handy:

(+d.label) === (i + 1)

[curran]

As the next step, we convert mensuration symbols to their "number of beats per bar" equivalent:

[curran]

Here we go, I think this is the scaling we're after: https://github.com/sul-cidr/josquin-ribbon/pull/117/commits/56dbfdbedb138baf962cbfa6d94e646e4412f1a6

[curran]

Judging by the number of beats in this note that occupies a complete measure in "C|" time,

I believe the correct number of beats per bar for "C|" time is 8, not 2 or 4 as I previously thought.

[curran]

Just discovered that the number of beats per measure for mensuration "3" is 12 (jos1913).

[seemantk]

This is looking great, @curran!

I think I see how we can rescale the image properly after switching.

do the ribbons need to be recalculated as well? :/

[curran]

@seemantk Yes, unfortunately I neglected the Ribbons. Will investigate.