scriabin-op66.krn: adding dynamics has caused rendering problems

[bel28kent]

Since adding dynamics, the rendering of scriabin-op66.krn is off.

Before dynamics:

After dynamics:

[craigsapp]

There seems to be a rhythmic or spine problem around measure 168 which I am looking for.

But otherwise, this strange notation typically indicates that the dynamic was placed in a **kern spine instead of a **dynam spine. If you remember which dynamic was added which started the problem, that is the dynamic that needs to be moved to the correct spine (I'll look for that after studying if there is a problem in or around measure 168.

[craigsapp]

The problem is that the p at the start of measure 168 is placed in the **kern spine one column to the right, and needs to be moved one column to the left (line 1875):

Also on line 2652 there is a p in the **kern data:

.           [8.qGG#\    .           16qGG#XLL   p           .

Line 2941:

.           .           .           8cccnJ      pp    

fortes on lines 2371 and 2373:

2371 .           .           4A-X        f           .
2372 !           !           !           !LO:DY:b=3  !
2373 .           16%3BB-X    .           f           .

mf on line 3984:

3984 .           [16c-X      .           mf          .

I found these by extracting **kern data on the command-line and then searching for dynamics within it (tab-p and tab-f):

extractx -i kern input.krn > only-kern.krn

If you fix these dynamics (I don't know which staff they should go on, so you get to fix them) and the notation is still having funny gaps before the first beat, there is still likely something non-kern in a kern spine somewhere (I can look for it if you cannot find it because sometime it is tricky to locate).

[bel28kent]

There was one more. Here is how I found it using hum-parser:

> ,require hum-parser.rkt
> (define 66-path "../../Desktop/Mysterium/op66/scriabin-op66.krn")
> (define 66-spines (spine-parser (path->hfile 66-path)))
> (define 66-kern (filter (λ (s) (string=? KERN (type-spine (global-spine-tokens s)))) 66-spines))
> (define (dynam-filter lot)
    (filter (λ (t) (regexp-match? #px"^[pmsfz<>\\[\\]\\(\\)]+$" (token-token t))) lot))
> (map (λ (s) (map dynam-filter (global-spine-tokens s))) 66-kern)

This outputs lists of tokens for each spine, with non-dynamic stuff filtered out. This leads to empty lists, except for this, which was in staff1:

(list (token ">" "SpineData" 1905))

[craigsapp]

At some point I should ignore obvious non-kern spine data in **kern and instead print a warning about it in the console so that the funny spaces at the starts of measures that grow over time do not happen. The complication is that f is legitimate **kern data for F4 pitch, but if there are notes with rhythms but an f without, then that is a clue that the f is probably a **dynam.

Here is a legitimate use of only f in a **kern token:

[View in VHV]

When I convert to MEI to display in VHV, I make them quarter notes with no stems (for use in displaying chant notation):

<layer xml:id="layer-L1F1N1" n="1">
 <note xml:id="note-L2F1" dur="4" oct="4" pname="c" stem.visible="false" accid.ges="n" />
 <note xml:id="note-L3F1" dur="4" oct="4" pname="d" stem.visible="false" accid.ges="n" />
 <note xml:id="note-L4F1" dur="4" oct="4" pname="e" stem.visible="false" accid.ges="n" />
 <note xml:id="note-L5F1" dur="4" oct="4" pname="f" stem.visible="false" accid.ges="n" />
 <note xml:id="note-L6F1" dur="4" oct="4" pname="g" stem.visible="false" accid.ges="n" />
 <note xml:id="note-L7F1" dur="4" oct="4" pname="a" stem.visible="false" accid.ges="n" />
 <note xml:id="note-L8F1" dur="4" oct="4" pname="b" stem.visible="false" accid.ges="n" />
 <note xml:id="note-L9F1" dur="4" oct="5" pname="c" stem.visible="false" accid.ges="n" />
</layer>