newlandsvalley / purescript-abc-scores Goto Github PK

Although we'll have to figure out what to do when we hit a body part that just instructs us to change time signature.

(when the ABC has a Q header)

The Abc parser now leaves an empty bar at the end of each stage. This is necessary because there is only a starting bar line defined in each bar. We need to get hold of the barline in this final bar which may have an end-repeat instruction and somehow coalesce it into the penultimate bar, or perhaps display an empty VexFlow barstave to do this.

Noticeable if there are two quavers followed by the triplet - all 5 notes are beamed together. It would be clearer if they were separated, and is almost certainly caused by the beatsPerBeam parameter being set at 2 rather than 1 (which gives a more nartural beaming when triplets are absent).

For example in:

{G}(3ABc

The G grace note decorates each note in the triplet (not just the A).

3/2 is a strange time signature - because the beat is every half note which will usually not attract a beam across the entire beat. Perhaps the best compromise is to nominate a beam group of 1/4 - so at least eighth notes will be beamed together as quarter notes.

This is too squashed at the moment. Possibly increase by 50%.

i.e. where the final bar in ABC ends in :: then only the end repeat is shown.

In order to allow key and time signature changes to influence all following notes.

As introduced by ABC's 'T' symbol.

I've decided that each stave will be of the same length, possibly truncated if we try to fit in too many bars. This is OK because the module is for use in an editor and the user will simply move the overhanging stuff to a new stave line if necessary. This then should make it look nicer when we support individual bar staves of variable width.

(currently we just default to d!)

Depending on the number and type of its occupants.

AbcContext should only be used to thread the context through the translation and should not be used as a parameter to any of the VexFlow API methods that generate a score. This is because it tends to be an 'old' value that us used. Instead, copy the relevant state information to the output of the translation (usually BarSpec) and use this instead. This should ensure that the properly updated version is always used.

Particularly if the triplet crosses the beat.

My idea (roughly) is:

• Find the widest stave (ignore the stave bar that just extends the bar line to the desired width)
• Work out the percentage increase required to 'grow' smaller staves to this max width
• For all staves where the width is at least (70% ??) of this width, increase the width of each individual stave bar by this percentage.
• Possibly set the width of the final stave bar so that the total width is max (to avoid rounding errors)

(or else, of course, not to beam).

For example the text "| ABc | | def |" has a middle bar with no content. This produces two stave bars but with whitespace between them.

(need to take account of the scaling factor)

These should be supportable if they are entirely intra-bar. There will be a big problem supporting them across bars or even across staves. This is because abc-scores is built entirely around engraving the score of each bar individually. Whilst VexFlow supports slurs spanning bars with an interface that allows you to specify the beginning and end notes from each bar, this approach is extremely awkward here because, by the time you process the notes from the second bar, the notes from the first are no longer in the stack frame.

abc-scores is designed for use within an editor application, where the score is gradually growing. In such an environment, you obviously don't know how big the score is going to grow and so you must use a large enough canvas to accommodate any score.

However, if you right-justify the score, it is likely that you are approaching the finished result. It thus makes sense to add a function that recalculates the canvas configuration based on the dimensions of the justified score. If the user then continues to edit, the editor can go back to the original configuration.

Because it will be used in an editor which can load a succession of tunes.

These look straightforward when fully contained within a bar but I'm not sure how to provide a tie between bars. (Each bar is given its own staveBar).

These are standard signatures but modified with 'extra' sharps or flats. Perhaps we just give up and don't support them and return a translation error.

The sample tune displays an octave too high.

In ABC, you can add a backslash character at the end of a line to indicate that the next line will continue the current line. However we ignore it and produce separate staves for each line.

A Volta second repeat should end when it hits a double bar line. This happens if the double bar is the last bar but not if it occurs earlier in the stave.

At the moment, all stem directions lie above the note head, irrespective of the position of the notes in the bar. Not too sure why this is as the VexFlow tutorials indicate that this is calculated automatically in VexFlow.

i.e. they are always unilaterally ended by the end of the stave.

It just displays a horizontal line (mid -volta) and not the line terminated with a small vertical stroke (end volta). i.e. we need to recognise the end-volta state properly when we are shifting the bar ends forward when processing a completed stave.

Really we should take this from the denominator of the meter signature, but this may not be present. 1/8 seems a sensible default out in the wild.

Currently the bar width algorithm ignores inline headers

i.e. a BodyPart that just consists of an isolated header change. In some cases, these are given an entire stave but should be merged into the next score line. In other cases, they are ignored completely.

At the moment, only singly-dotted notes are supported. Double-dotted raise a translation error.

Auto-beaming is OK but a little too crude. We need to customise it further by doing more analysis of the beam groups in the PureScript layer. Currently there is just a single beam group, calculated from the number of beats per beam and the duration of each beat (i.e. the denominator of the time signature). These are passed separately to the JavaScript layer.

As a start, we need to add beamGroups to MusicSpec and, to begin with, calculate a single beam group in the same way, and then use this to calculate auto-beaming. And then we can remove time signature and beats per beam from the JavaScript interface.

All bar lines are single at the moment.

There are separate methods for engraving a bar according to whether or not the bar contains tuplets. These should be coalesced into a single function.

Fails to display the tuplet or broken rhythm properly.

I'd really like to rely on VexFlow's auto-beaming throughout but this doesn't beam quadruplets properly - joining only 3 of the 4 notes. Presumably it's taking it's instruction from the 6.

On the whole, auto-beaming in VexFlow works like this. You designate one or more 'beam groups' to the bar where a beam group is defined as a fraction of the bar where notes that occupy that fraction are to be beamed together. If you only designate a single beam group, then it is applied to all patterns of notes that inhabit the bar. Otherwise, as far as I can tell, you cycle through the groups until all notes are matched.

By and large, you want a beam group to correspond to a beat. This means you can calculate a single beam group very simply just from the time signature. So, for example, if you have a 9/8 time signature, each beat will occupy a 3/8 fraction; if you have a 2/4 time signature, each beat will occupy 1/4 and so on. For this reason, we use an algorithm that is (almost) entirely based on time signature as illustrated above.

However, very many bars have complexities. For example, in a reel or hornpipe (notated in 4/4) it is conventional to beam the notes for two beats together - i.e. the fraction is 2/4 or 1/2. But some bars if analysed more carefully would benefit from a compound group of (say) (1/4, 1/4, 1/2). Other complications arise when tuplets are present.

Would it be possible to come up with a good algorithm, cheap to compute, which improves on the basic default?