Drum notation? - Githubissues

ghost commented 6 years ago

Hello, wonderful developers of Audiveris!

I try to scan my drums sheets from my music school but after a processing, the hi-hat notes (noted with crosses), do not appear on the resulting file; am I missing some configuration? I tried to search for "drums" in your wiki and documentation, is it an expected behavior, a limitation or an error I did?

Thanks for your help :)

~SPJ

Jojo-Schmitz commented 2 years ago

No, "origin" is your fork on GitHub. If git remote -v doesn't also show https://github.com/Audiveris/audiveris.git, something is wrong there, and you'd need to add that.

I believe it'd be git remote add upstream https://github.com/Audiveris/audiveris.git

hbitteur commented 2 years ago

Sorry Brian, I can't help you on these git commands. I have reached my incompetency level. :-)

My advice is simply to make a backup of your folder before attempting any of these commands.

A git status command will list the files you have added or modified. According to your previous messages, the number of impacted files should be rather low. So, in any case, you should be able to replicate these modifications (a basic diff command would help you).

brian-math commented 2 years ago

Thanks Hervé. I will make a backup before proceeding with Jojo-Schmitz's suggestions. I have taken a pause for a few days to read up on git and the commands involving branching, origin, upstream, etc. I am making good progress and just need to find some time to implement them. Once I do, I will post a new PR from/to the corrected branches.

hbitteur commented 2 years ago

Hi Brian,

Back to the choice of musical font, could you have a look at Bravura font (SMuFL compliant) For example at https://w3c.github.io/smufl/latest/tables/shape-note-noteheads.html

This is not a font installed by default, but first check if you can find all your needs there.

Jojo-Schmitz commented 2 years ago

Bravura however is the reference font for SMuFL, the IMHO only font guaranteed to be 100% complete. (and that's why e.g. MuseScore uses it as the fallback for missing glyphs in all other fonts it supports)

hbitteur commented 2 years ago

@Jojo-Schmitz The question is: Can we find the needed symbols for drum notation in this SMuFL font? I have tried, not systematically I agree, but I haven't found them.

I will get in touch with Daniel Spreadbury.

Jojo-Schmitz commented 2 years ago

If they are not in Bravura, they are not in SMuFL. And vice versa.

hbitteur commented 2 years ago

@brian-math Since Bravura can fit our needs for drum notation, I propose to take care of migrating music font from MusicalSymbols to Bravura.

I will first work on "development" branch for all users, especially a bunch of modifications in Symbols class.

Then I will port the same modifications to the "drum-scores" branch (where you have already added half a dozen of new symbols in Symbols class).

Doing so, both development and drum-scores branches should be OK regarding Bravura. Does this retrofit make sense ?

brian-math commented 2 years ago

Does this retrofit make sense ?

@hbitteur I think this makes perfect sense.

hbitteur commented 2 years ago

FYI, I just pushed a first version of support for multiple measure rests (long horizonlal bars together with a measure count value). It is a partial support: detection and handling by the OMR engine and export to MusicXML.

Question: Even though the information seems correctly exported in MusicXML (see this page and that page), the way both MuseScore and Finale handle this feature is surprising: they seem to ignore the measure count value and always create a single measure with a whole rest.

OMR UI still needs to be augmented to allow assignment / modification, edition of these new entities. This is planned for the next version.

Code is available in "multiple-rest" branch created off of "development" branch.

brian-math commented 2 years ago

@hbitteur Here is how MuseScore outputs a 3-bar rest in "uncompressed .musicxml" format. (BTW, the MuseScore export menu also includes an option for "uncompressed (outdated) .xml", although the handling of a multi-bar rest seems identical in both versions.)

<measure number="2" width="0.00">
  <attributes>
    <measure-style>
      <multiple-rest>3</multiple-rest>
      </measure-style>
    </attributes>
  <note print-object="no">
    <rest measure="yes"/>
    <duration>48</duration>
    <voice>1</voice>
    </note>
  </measure>
<measure number="3" width="0.00">
  <note print-object="no">
    <rest measure="yes"/>
    <duration>48</duration>
    <voice>1</voice>
    </note>
  </measure>
<measure number="4" width="0.00">
  <note print-object="no">
    <rest measure="yes"/>
    <duration>48</duration>
    <voice>1</voice>
    </note>
  </measure>

[Edited to change a "5" to "3" in line 4 of the code.]

hbitteur commented 2 years ago

@brian-math Here we have 3 (three) measures, the first one contains a multiple-rest for 5 (five) measures. I suppose there is a typo, could you confirm?

The following 2 measures are not printed but do exist in the MusicXML stream. This would mean that for say a multiple-rest of 28, we would have to define 1+27 measure elements in the MusicXML stream! Can you point me where this behavior is specified in MusicXML reference documentation?

brian-math commented 2 years ago

Ah yes, that 5 was a typo by me. The example score I used had a 5-bar rest starting in bar 5, and to make my comment shorter I tried to change it to a 3-bar rest starting in bar 2. I forgot to change one 5 to a 3.

hbitteur commented 2 years ago

The following 2 measures are not printed but do exist in the MusicXML stream. This would mean that for say a multiple-rest of 28, we would have to define 1+27 measure elements in the MusicXML stream! Can you point me where this behavior is specified in MusicXML reference documentation?

I think I have an answer to my own question. Found on Makemusic forum where Michael Good says:

Yes, you must have all the measures included in all the parts, no matter what the notation.
This is true for multi-measure rests as it is for parts that don't display on certain pages of an orchestral score.

There's no need to change the measure numbers in a multiple-rest.
If you have a 3 bar rest starting at bar 4, those 3 bars have measure numbers 4, 5, and 6, and measure 7 will start the display after the multi-measure rest.

hbitteur commented 2 years ago

OK, MusicXML now contains the dummy measures needed by a multiple measure rest. See commit 6ab859f49be1cab8f3fc2cc2a22dd5cec8c75d5a in "multiple-rest" branch. Please pull.

brian-math commented 2 years ago

Would you consider adding code to recognize measure repeats next? It seems that this might be similar to recognizing multi-measure rests.

hbitteur commented 2 years ago

Measure repeats are already implemented: repeat signs on left or right side, as well as endings. OCR'ing the ending number (e.g. "2.") is often not satisfactory and may require manual adjustment. Could you elaborate on what is missing?

brian-math commented 2 years ago

@hbitteur I'm referring to one-bar and two-bar repeat signs, as described in items 2 and 3, and shown in examples 6 and 5, at https://dictionary.onmusic.org/terms/4804-repeat. One-bar repeats are very common in percussion scores, and two-bar repeats are not uncommon. Note that the 2-bar repeat sign does not always have a numeral "2" above it.

hbitteur commented 2 years ago

I didn't know these signs. Thanks for this. It should not be very difficult to implement: a matter or recognizing the two fixed-shape symbols. Could you provide me with several examples I could use to train the glyph classifier?

brian-math commented 2 years ago

Here is one to get you started. I don't know what program produced this output, do you? It has more of a "hand-written" appearance than the (usual) MuseScore font. I think Audiveris may have difficulty with some aspects of this, so it would be good to give it some training--I have a lot of PDF scores by this same transcriber. JustWhatINeeded_TheCars_redeyepercussion.com.pdf

I'll try to find a MuseScore score with 1-bar and 2-bar repeat signs. (Mostly when I transcribed a drum part into MuseScore myself, I tried to avoid these signs and just copied and pasted the actual notes from the bar[s] before.) If necessary I can adapt some existing scores to use these signs.

IFeelGood_JamesBrown_redeyepercussion.com.pdf December1963(Oh,_What_A_Night)_Four_Seasons_musescore.pdf New_Kid_In_Town_Eagles_musescore.pdf Heartache_Tonight_Eagles_musescore.pdf

hbitteur commented 2 years ago

I found the SMuFL symbols Now, where are these symbols located: middle of measure width (case 1), right on measure bar (case 2). Is there any specification for the measure locations?

brian-math commented 2 years ago

The 1-bar repeat should be centered vertically and horizontally in the middle of an otherwise empty measure. The diagonal slash extends from line 2 to line 4 of the score, and the dots lie in spaces 2 and 3.

The 2-bar repeat should be (horizontally) approximately centered on top of the bar line between two otherwise empty measures.

I haven't ever seen a 4-bar repeat, but I suppose it would also be horizontally centered on top of a bar line (in the middle of 4 empty bars?)

Jojo-Schmitz commented 2 years ago

MuseScore support 2 and 4 measure repeats only in the current development builds, but does support single measure repeat ever since. But see also https://musescore.org/en/node/103336

brian-math commented 2 years ago

But see also https://musescore.org/en/node/103336

No wonder I've never seen a 2-bar repeat coming from MuseScore ;-)

hbitteur commented 2 years ago

@brian-math I have just pushed the result of migration to Bravura font as described in issue #576. It is available in the "bravura" branch created off of "development". Now, I think it is time to further extend the migration to your "drum-scores" branch.

Here is how I intend to proceed:

I will locally merge "bravura" back to "development" first.
Meanwhile, please make sure that you have committed and pushed all your local modifications, so that I can pull your "drum-scores" branch from github.
I will locally merge "drum-scores" back to "development" (here I expect to perform a few manual modifications, similar to what I did for Bravura migration, but limited this time to the migration of your additional symbols)
I will finally push "development" to github.

Tell me when you are ready.

brian-math commented 2 years ago

@hbitteur I have just pushed my recent work to brian-math:drum-notation. I don't seem to be able to issue a new Pull Request because the previous one is still pending, but the new commits have evidently been added to the existing PR.

I've been working on implementing MusicXML export for drum parts. This is still a work in progress, but I don't think it will do any harm to incorporate the work so-far into the Audiveris development branch.

If you want, I can post a summary of what I've done so far for unpitched percussion .xml export, and what remains to be done...just let me know.

hbitteur commented 2 years ago

@brian-math Done! The drum-scores branch is now up-to-date with Bravura font. Please pull to update your local copy. And check whether the template matching works correctly with Bravura symbols for drum scores.

I noticed that the new shapes created for drums (NOTEHEAD_DIAMOND_FILLED and the like) now appear in the ShapeBoard (HeadsAndDot family). This is consistent.

However this is likely to disturb the plain end-user who is not interested in these notations. So I intend to dynamically modify the display of HeadsAndDot family according to the processing switches that apply for the current sheet. More on this later.

Also, perhaps we should re-organize the order of appearance of shapes in this board.

Order by decreasing duration? (or increasing?)
Order by sub-families (standard family, drums family, ...) then decreasing order within each sub-family
What else?

hbitteur commented 2 years ago

If you want, I can post a summary of what I've done so far for unpitched percussion .xml export, and what remains to be done...just let me know.

Yes, please do so.

brian-math commented 2 years ago

And check whether the template matching works correctly with Bravura symbols for drum scores.

I have only tried a small sample score, but so far the Bravura font seems to be doing better than the old font at recognizing drum note shapes! I'll add the half- and whole-note x notehead shapes, and the various triangle-down shapes, when I get a chance.

I noticed that the new shapes created for drums (NOTEHEAD_DIAMOND_FILLED and the like) now appear in the ShapeBoard (HeadsAndDot family). This is consistent.

I had noticed this earlier, too. I was a bit surprised because I wasn't aware of doing anything to make the new head shapes show up on the ShapeBoard :). But it has been convenient in fixing mis-recognized notehead inters.

I agree the special head shapes could be suppressed for the average user who does not have the drum (or x-head) processing switches turned on.

I think it's useful to have all the ovals together, all the diamonds together, etc. Perhaps in order of increasing duration within each group (on the theory that shorter notes are used more frequently).

brian-math commented 2 years ago

If you want, I can post a summary of what I've done so far for unpitched percussion .xml export, and what remains to be done...just let me know.

Yes, please do so.

I made good progress today after merging in your Bravura font changes. Almost all MusicXML export features are in place for drum scores, including the preamble info listing score instruments and midi instruments pertaining to a drum Part. I think all that remains is specifying an instrument as each individual note is exported. I'm still figuring out how to do that.

hbitteur commented 2 years ago

With latest commit c17e4608be91a8432cf19d11910b972cc2d73666, pushed to "drum-scores" branch, the heads now adjust dynamically according to the effective processing switches of the current sheet. I have also cleaned up the ShapeSet class. Please pull.

hbitteur commented 2 years ago

I have just merged "drum-scores" to "development". I think you can still work on "drum-scores" it you wish, since I have not deleted it yet, but if you do so we will have to re-merge later. And my understanding is that the main part of the work has been done. So, if you have just a few additional modifications to make, it will be more convenient to pull development and then do the modifications directly on development.

brian-math commented 2 years ago

@hbitteur I still had some ongoing work, including several commits, on my local drum-notation branch, so I finished that up today (after merging in your latest commits) and issued a PR to Audiveris:drum-scores. In future if I have some minor changes, I'll try to make them directly on the development branch.

Here's a test score I've been using. It has 2 parts (Drumset & Voice), 2 systems, and 2 voices in the drum part, and uses lots of different note heads and instruments (standard ovals, x's, diamonds, triangles) of many durations and in several chord combinations. Test_Percussion_2part2voice2staff.pdf

The very good news: Audiveris now recognizes this score almost perfectly, and the MusicXML export very closely resembles the original when imported back into MuseScore, including instruments and MIDI-instruments, \<unpitched> elements, etc.

There are still a few small glitches:

~~The half-note triangle in beat 2 of the last bar is deleted at REDUCTION step: the head is recognized, but for some reason it doesn't acquire a connection to the corresponding stem at STEMS step.~~ DONE
The quarter note oval in beat 4 of the last bar is misidentified as a diamond head, producing a warning during .xml output (because there is no instrument in the drum set represented by a diamond in staff "line" -3). Strangely, the very same chord in beat 4 of bar 5 is correctly recognized! DONE
The two distinct drum voices, distinguished by stems up or down, respectively, are extremely well detected. The only problem is the whole measure rests in the lower voice. In those bars, the two voices are swapped, and the rests are poorly positioned (much too high) in the .xml output. Likewise, the whole measure rests in the Voice part are too high when the .xml export file is imported to MuseScore. DONE
The part abbreviation "D. Set" is recognized by the OCR engine, but does not seem to make it into the LogicalPart.abbreviation string, because the abbreviation does not export to MusicXML. Maybe it's in the Part but not the LogicalPart; I didn't try to check this. DONE
~~The log file shows an error "BREVE is not supported", which I believe is generated at the HEADS step. I did not try to track down why.~~ DONE
I must have entered some of the new note heads in the wrong order (or the wrong shape set) somewhere, because now in the ShapeBoard, the new whole note heads (x, diamond, and triangle) are all together at the end of the list, instead of being together with the other note heads of the same shape. DONE

I'll write a separate post later with some questions regarding places in the code where the new note heads should possibly play a role.

[Note from @hbitteur: I took the liberty to consider this message as a "todo list" and update it as tasks get completed]

brian-math commented 2 years ago

@hbitteur As I was adding new drum noteheads, I noticed some methods which use the standard oval noteheads in some (non-obvious) way, so I wondered if you'd check to see whether any of them should also refer to the new noteheads? Here are the method names and approximate line numbers, perhaps along with a comment.

TemplateFactory, 248. There is an adjustment to dy for NOTEHEAD_CROSS. Should this apply to NOTEHEAD_CROSS_VOID and WHOLE_NOTE_CROSS, too? [Also line 47, the import for CODE_NOTEHEAD_DIAMOND_FILLED is never used, according to my IDE.]
NoteHeadsBuilder, 1327-30. Trick to boost cross heads. Is this needed for the two new cross heads, too?
NoteHeadsBuilder, 1341-65. evalBlackAsVoid. Is this needed for any noteheads besides NOTEHEAD_VOID?
NoteHeadsBuilder, 1525. Special case: NOTEHEAD_VOID mistaken for NOTEHEAD_BLACK.
BeamLinker, 1358 and HeadLinker, 1113. Tests for not NOTEHEAD_VOID.
SigReducer, 413-4. I added all the new filled heads here: Standard beams support black heads (not void).
AbstractChordInter, 534-5. Replacing void note by black counterpart in some chords.
HeadChordInter, 162, 169.
ShapeSet, 268, 274. I added NOTEHEAD_CROSS_VOID and WHOLE_NOTE_CROSS to the CrossHeads list (which I believe is used for populating the note head shape board when the cross heads processing switch is on). But maybe these aren't relevant for users who turn on only that switch, and these heads should be in the DrumHeads list instead?

hbitteur commented 2 years ago

The log file shows an error "BREVE is not supported", which I believe is generated at the HEADS step. I did not try to track down why.

I just fixed this, by adding BREVE to the set of template heads.

hbitteur commented 2 years ago

There are still a few small glitches:

I will need some time to debug all these cases, please be patient.

hbitteur commented 2 years ago

The quarter note oval in beat 4 of the last bar is misidentified as a diamond head, producing a warning during .xml output (because there is no instrument in the drum set represented by a diamond in staff "line" -3). Strangely, the very same chord in beat 4 of bar 5 is correctly recognized!

Use a lasso and right-click to get the list of selected inters, ordered by decreasing contextual grade.

In the case at hand we have 14 head candidates:

1510: diamond filled, 0.730/0.916 (correct one)
1586: oval black head, 0.712/0.898 (correct one)
1578: diamond filled, 0.690/0.883 (incorrect, fully overlaps 1586)
and 11 others with minor grades

At end of reduction step, just 1510 and 1578 remain, even though we could have expected that 1510 and 1586 would be the survivors.

To check what is happening to Inters, generally during the REDUCTION step, a good approach is to set the Inters instances you are interested in as "VIP". You can do that via several ways:

In Options pull-down menu, look for vipInters constant. Set this string to IDs separated by commas, for example: 1586,1578. Advantage: this constant is persisted on disk and Audiveris is coded such that, all other things being equal, the same Inters get repeatedly assigned the same IDs.
In the InterBoard, display Inter with ID 1586 and tick the Vip checkbox. Same thing for inter 1578.

So what happened between 1586 and 1578? Here is the whole story, that you can discover on your own by setting 1586 and 1578 as VIP and then launch the REDUCTION step.

    Loading book D:\soft\cases\Issue-33\Test_Percussion_2part2voice2staff.omr
    [Test_Percussion_2part2voice2staff] Loaded /sheet#1/sheet#1.xml
1=> HeadInter{#1586(0.712/0.898) stf:3 NOTEHEAD_BLACK p:-3.0} flagged as VIP
2=> HeadInter{#1578(0.690/0.883) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0} flagged as VIP
    [Test_Percussion_2part2voice2staff] VIP check overlap HeadInter{#1586(0.712/0.898) stf:3 NOTEHEAD_BLACK p:-3.0} vs HeadInter{#1578(0.690/0.883) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] HeadInter checking overlaps between HeadInter{#1586(0.712/0.898) stf:3 NOTEHEAD_BLACK p:-3.0} and HeadInter{#1578(0.690/0.883) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] HeadInter checking overlaps between HeadInter{#1578(0.690/0.883) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0} and HeadInter{#1586(0.712/0.898) stf:3 NOTEHEAD_BLACK p:-3.0}
3=> [Test_Percussion_2part2voice2staff] VIP support HeadInter{#1510(0.730/0.916) stf:3 NOTEHEAD_DIAMOND_FILLED p:-4.0}-HeadHead:-HeadInter{#1578(0.690/0.883) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP support HeadInter{#1516(0.363/0.691) stf:3 NOTEHEAD_BLACK p:-4.0}-HeadHead:-HeadInter{#1586(0.712/0.898) stf:3 NOTEHEAD_BLACK p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkheads for HeadInter{#1578(0.690/0.902) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkHeadHasStem for HeadInter{#1578(0.690/0.902) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkHeadSide for HeadInter{#1578(0.690/0.902) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkheads for HeadInter{#1586(0.712/0.907) stf:3 NOTEHEAD_BLACK p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkHeadHasStem for HeadInter{#1586(0.712/0.907) stf:3 NOTEHEAD_BLACK p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkHeadSide for HeadInter{#1586(0.712/0.907) stf:3 NOTEHEAD_BLACK p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkheads for HeadInter{#1578(0.690/0.902) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkHeadHasStem for HeadInter{#1578(0.690/0.902) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkHeadSide for HeadInter{#1578(0.690/0.902) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkheads for HeadInter{#1586(0.712/0.907) stf:3 NOTEHEAD_BLACK p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkHeadHasStem for HeadInter{#1586(0.712/0.907) stf:3 NOTEHEAD_BLACK p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkHeadSide for HeadInter{#1586(0.712/0.907) stf:3 NOTEHEAD_BLACK p:-3.0}
4=> [Test_Percussion_2part2voice2staff] VIP conflict HeadInter{#1578(0.690/0.902) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}-Exclusion:OVERLAP-HeadInter{#1586(0.712/0.898) stf:3 NOTEHEAD_BLACK p:-3.0} deleting weaker HeadInter{#1586(0.712/0.898) stf:3 NOTEHEAD_BLACK p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP remove HeadInter{#1586(0.712/0.898) stf:3 NOTEHEAD_BLACK p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP removeVertex HeadInter{#1586 REMOVED(0.712/0.898) stf:3 NOTEHEAD_BLACK p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkheads for HeadInter{#1578(0.690/0.902) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkHeadHasStem for HeadInter{#1578(0.690/0.902) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] VIP checkHeadSide for HeadInter{#1578(0.690/0.902) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}
    [Test_Percussion_2part2voice2staff] Stems free length median value: 55 pixels, 2.6 interlines
    [Test_Percussion_2part2voice2staff] End of sheet step REDUCTION

We can observe at the end of this VIP log that 1586 (our poor oval head) got removed. Looking a bit earlier in the log we can see (mark 4): VIP conflict HeadInter{#1578(0.690/0.902) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0}-Exclusion:OVERLAP-HeadInter{#1586(0.712/0.898) stf:3 NOTEHEAD_BLACK p:-3.0} deleting weaker HeadInter{#1586(0.712/0.898) stf:3 NOTEHEAD_BLACK p:-3.0} The weaker got killed. OK, but 1578 was weaker than 1586 at the beginning (remember the list by decreasing grade, or see the marks 1 & 2 when these inters were flagged as VIP)

We have to look a bit earlier (mark 3): VIP support HeadInter{#1510(0.730/0.916) stf:3 NOTEHEAD_DIAMOND_FILLED p:-4.0}-HeadHead:-HeadInter{#1578(0.690/0.883) stf:3 NOTEHEAD_DIAMOND_FILLED p:-3.0} This means that 1578 got help from another candidate 1510 (exactly the same shape) and its contextual grade increased from 0.883 to 0.916. Et voilà! 1578 wins against 1586... Too bad!

Granted, 1586 also got help from another candidate (1516, same shape). But 1516 got removed later, and its support to 1586 got removed consequently, while 1510 never got removed..

Now, what is the reason for this HeadHead support? It lies in SigReducerclass, method analyseChords(), lines 339-351, "Mutual head support within same shape". This goes back to the time when we had no drum notations, but could have just black heads or just void heads along the same stem. Hence the need to insert exclusion between different head shapes and to insert support between same head shapes. This logic now needs to be modified when drum notations switch is active. One more thing to update, sorry for that...

The good side of the story was this opportunity to explain how in practice we can debug and understand how the reduction works. :-)

hbitteur commented 2 years ago

Strangely, the very same chord in beat 4 of bar 5 is correctly recognized!

I'll leave this as an exercise for the curious reader. :-) Hints:

Intrinsic head grade results from template matching applied on head pixels
Actual support depends on supporting inter intrinsic grade

hbitteur commented 2 years ago

The two distinct drum voices, distinguished by stems up or down, respectively, are extremely well detected. The only problem is the whole measure rests in the lower voice. In those bars, the two voices are swapped, and the rests are poorly positioned (much too high) in the .xml output. Likewise, the whole measure rests in the Voice part are too high when the .xml export file is imported to MuseScore.

OK, I see where the problem is. Voice assignment within a measure is performed, time slot after time slot, as follows:

Whole measure rests are assigned first (they don't belong to any time slot)
Time slot notes are then assigned using a rather complex logic (use of pitch value, use of stem direction, ...)

In the case at hand, measures 3 and 8, the whole rest is a measure-long rest and is assigned first, even though its vertical location is very low.

Before we come up with a better algorithm, you can manually fix this:

In measure 3, select high note at end of previous measure, together with the diamond whole and then open the right-click popup menu, where you select the "Chords" sub-menu, and then the action "Next in Voice". Doing so, your diamond whole will tight its voice to the one from the selected note at end of previous measure.
In measure 8, since there is no previous measure in the system, you can't use the voice linking approach as above. Instead, select the diamond whole note, and in the "Chords" popup menu, use action "Preferred Voice". Doing so you manually assign a voice number.

Once these two manual corrections are made, export to MuseScore looks good.

hbitteur commented 2 years ago

The quarter note oval in beat 4 of the last bar is misidentified as a diamond head, producing a warning during .xml output (because there is no instrument in the drum set represented by a diamond in staff "line" -3). Strangely, the very same chord in beat 4 of bar 5 is correctly recognized!

This is now fixed via commit 1bb37f27b8cac32bbd18b4b6f3d6c86be7e88363 which uses shape intrinsic duration rather than shape.

hbitteur commented 2 years ago

I must have entered some of the new note heads in the wrong order (or the wrong shape set) somewhere, because now in the ShapeBoard, the new whole note heads (x, diamond, and triangle) are all together at the end of the list, instead of being together with the other note heads of the same shape.

Fixed via commit 3eb071737454f37edec36a23fbbb2ee31209a4e5 which reordered heads sequence for ShapeBoard.

hbitteur commented 2 years ago

The half-note triangle in beat 2 of the last bar is deleted at REDUCTION step: the head is recognized, but for some reason it doesn't acquire a connection to the corresponding stem at STEMS step.

Bad news! The root cause for not detecting stem connection in this case relates to the side "reference point" of the head. This is the theoretical point where the head should get a stem connection (on a given horizontal side). And for oval head shapes, whether we have a black or a void head, left reference is roughly south west while right reference is roughly north east. For these new shapes brought by drum notation, you should not have to feel guilty ! :-), but these oval-based connection points no longer hold, especially for a triangle down shape in the case at hand. For a left connection, we should look at roughly north west rather than south west. Soooo, I will have to modify the current approach and adapt the potential connection point according to the head shape at hand (triangle, diamond)! More on this later...

hbitteur commented 2 years ago

The half-note triangle in beat 2 of the last bar is deleted at REDUCTION step: the head is recognized, but for some reason it doesn't acquire a connection to the corresponding stem at STEMS step.

This is now fixed via commit 10bd0962d74456d9409163c78e68c0e19d9399ad. For percussion heads, beside the specific reference points, we also relax the stem side-connection policy that applies only for oval heads.

hbitteur commented 2 years ago

The part abbreviation "D. Set" is recognized by the OCR engine, but does not seem to make it into the LogicalPart.abbreviation string, because the abbreviation does not export to MusicXML. Maybe it's in the Part but not the LogicalPart; I didn't try to check this.

Implementation had never been completed for Part abbreviation name. This is now fixed by commit 0061e13c6915f319d2f7dde2f64eb48e79620a8a

hbitteur commented 2 years ago

The two distinct drum voices, distinguished by stems up or down, respectively, are extremely well detected. The only problem is the whole measure rests in the lower voice. In those bars, the two voices are swapped, and the rests are poorly positioned (much too high) in the .xml output. Likewise, the whole measure rests in the Voice part are too high when the .xml export file is imported to MuseScore.

This is now fixed with commit c6ba3c694aee3b6ccd1394ddd3cf9861e7b631c0. All first chords in measure, whether they are measure-long rests or belong to the first time slot are handled in the same basket.

hbitteur commented 2 years ago

We should now be close to complete these drum notation topics. Please tell me if something is still missing.

brian-math commented 2 years ago

Great progress on your end, tidying up those loose ends! I realize some of them required a significant reworking of the Audiveris algorithms, so thank you for that.

Let me merge your new commits into my local development branch and make a few test runs with the new version. I'll post more tomorrow after doing that, but here are a few thoughts, off the top of my head, of what might still remain to be done:

recognize circle-x heads (open hi-hat), and assign them to the correct midi instrument
recognize a small open circle above a hi-hat x (yet another notation for an open hi-hat), and assign to the correct midi instrument
recognize single bar repeats, and perhaps two-bar repeats (you started working on this a while back)
recognize tremolo signs ("buzz roll" notation)
recognize an apostrophe after a cymbal note (this is one way to denote a choked cymbal, but I believe it is used in some non-percussion scores, too [breath mark?])
train Audiveris on drum scores not created by MuseScore (e.g. the "pseudo-handwritten" music font used by RedEye Percussion)

brian-math commented 2 years ago

After git fetch and git merge on local development branch (fast-forward merge, no problems), I get a build error I never saw before. Does anyone have a quick fix?

brian% ./gradlew build
Starting a Gradle Daemon (subsequent builds will be faster)

> Configure project :
targetOS=macosx-x86_64

> Task :compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not find javax.media.jai:com.springsource.javax.media.jai.core:1.1.3.
     Searched in the following locations:
       - file:~/.m2/repository/javax/media/jai/com.springsource.javax.media.jai.core/1.1.3/com.springsource.javax.media.jai.core-1.1.3.pom
       - https://repo.maven.apache.org/maven2/javax/media/jai/com.springsource.javax.media.jai.core/1.1.3/com.springsource.javax.media.jai.core-1.1.3.pom
     Required by:
         project : > de.intarsys.opensource:jPodRenderer:5.6

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 9s
3 actionable tasks: 3 executed

hbitteur commented 2 years ago

After git fetch and git merge on local development branch (fast-forward merge, no problems), I get a build error I never saw before. Does anyone have a quick fix?

This has nothing to do with drum notation but relates to the removal of JAI dependency (we need this for license compatibility reasons). See recent commit 3363fabb900d21b7690cc1b24c775939f8e83bc2 which I pushed to development branch last week.

I did remove all JAI use from Audiveris, but there seems to remain an indirect dependency via JPodRenderer 5.6. FYI, have a look at this pending issue.

I had carefully flushed Gradle cache before rebuilding Audiveris, but overlooked Maven cache. Probably I still had jai-core 1.1.3 somewhere in a local cache, which allowed me to build without any problem.

Until JPodRenderer 5.6 removes its dependency on JAI, a workaround is to explicitly re-insert JAI in our build.gradle file especially around line 107:

[group: 'javax.media', name: 'jai-core', version: '1.1.3'],

Please try on your side and report the result.

brian-math commented 2 years ago

I added that statement as line 107 in build.gradle, but still got an error. [Feel free to move these last few posts to Issue 540 if you prefer them to be there instead.]

brian% ./gradlew build

> Configure project :
targetOS=macosx-x86_64

> Task :compileJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not find javax.media:jai-core:1.1.3.
     Searched in the following locations:
       - file:/Users/brian/.m2/repository/javax/media/jai-core/1.1.3/jai-core-1.1.3.pom
       - https://repo.maven.apache.org/maven2/javax/media/jai-core/1.1.3/jai-core-1.1.3.pom
     Required by:
         project :
   > Could not find javax.media.jai:com.springsource.javax.media.jai.core:1.1.3.
     Searched in the following locations:
       - file:/Users/brian/.m2/repository/javax/media/jai/com.springsource.javax.media.jai.core/1.1.3/com.springsource.javax.media.jai.core-1.1.3.pom
       - https://repo.maven.apache.org/maven2/javax/media/jai/com.springsource.javax.media.jai.core/1.1.3/com.springsource.javax.media.jai.core-1.1.3.pom
     Required by:
         project : > de.intarsys.opensource:jPodRenderer:5.6

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 847ms
3 actionable tasks: 3 executed

Audiveris / audiveris

Drum notation? #33