Audiveris import

[igorkorsukov]

Resolves: (direct link to the issue)

Optical music recognition by integration with audiveris app

Use "x" letter to fill the checkboxes below like [x]

• I signed CLA
• I made sure the code in the PR follows the coding rules
• I made sure the code compiles on my machine
• I made sure there are no unnecessary changes in the code
• I made sure the title of the PR reflects the core meaning of the issue you are solving
• I made sure the commit message(s) contain a description and answer the question "Why do those changes fix that particular issue?" or "Why are those changes really necessary as improvements?"
• I made sure the commit message title starts with "fix #424242:" if there is a related issue
  [N/A] I created the test (mtest, vtest, script test) to verify the changes I made

As for how it works:

• The file pdf, png, jpg is transferred to the OMR engine (used Audiveris)
• OMR engine can be either on the server, i.e. the file is sent over the network to the server. This is the default behavior.
• Or OMR engine can be local, for this you need to in the Preferences -> Import check to use local. Then the editor will download the portable build of OMR engine and its dependencies, install it in the Extensions folder, and use it.
• From OMR engine we get MusicXML and the OMR file, which contains information about recognized and unrecognized elements. Both files are zipped in one zip archive.
• The MusicXML is imported into MU Editor by its function, and I read OMR file, and draw under score.
• The main problem that I solved was to compare the data from OMR with the elements of score, because they are on a different scale, different size, different position, etc.
• Also, one of the tasks is to remove excess garbage, there are some features of the operation of Audiveris.
• As a result, I mark with the colors those elements that Audiveris recognized, and those that did not recognize (in the OMR file are marked as not recognized)
• A legend is shown to the user what the colors mean (you can hide it by clicking on it)
• In the View menu, you can hide recognized elements to see problematic ones, or hide all elements to see the final result
• You can start editing the score, correct what needs to be fixed, then save the recognition project (.msmr file), and later open it and continue working.

I think it is possible to improve the matching of data from OMR and Score, this is the work of the future.

[Harmoniker1]

@Jojo-Schmitz Why not create those review comments first and submit them altogether?

[Harmoniker1]

@igorkorsukov And yes, there're some pretty serious formatting (especially indentation and brace usage) issues, please read MuseScore coding rules.

[Harmoniker1]

@igorkorsukov All function definitions in .cpp files and all class definitions in .h files should have comments simply repeating the names in front. Like:

//---------------------------------------------------------
//   symbol
//---------------------------------------------------------

You can add other explanatory things between the two long lines if you like.

[Jojo-Schmitz]

Under which name did you sign the CLA?
AFAIK that is needed even for staff members.

[igorkorsukov]

You'd need to sing the CLA...
And of course fix those error that lead to Travis CI and AppVeyor to not compile.

Sorry, I did not know that C ++ 17 is not supported, fixed it.

Does it build on your machine? Which platform?

My Linux platform, gcc version 7.4.0

[igorkorsukov]

@Tantacrul started working on this feature, the behavior and design will be changed, so again WIP

[Jojo-Schmitz]

Better use git pull --rebase musescore master (or upstream, if that's what it is called in your repo), rather than git merge

[igorkorsukov]

Better use git pull --rebase musescore master (or upstream, if that's what it is called in your repo), rather than git merge

Yes, thank you, I got a little confused with git today, but I put everything in order in the end.
Sorry for spam.

[igorkorsukov]

Since most of the code is separate and does not affect the main code much, I'm going to merge to master the current PR with this experimental function, but it will be disabled by default (at the compilation stage). So that subsequent reviews and discussions of changes (there will be changes in UI/UX), were more effective.

[MarcSabatella]

If we're pretty sure the code will be used but maybe with a different UI, Id personally prefer to see it enabled so people can test the functionality itself. We also have an "experimental" flag ("-e" command line option) that things like this are sometimes hidden behind.

[Tantacrul]

t

If we're pretty sure the code will be used but maybe with a different UI, Id personally prefer to see it enabled so people can test the functionality itself. We also have an "experimental" flag ("-e" command line option) that things like this are sometimes hidden behind.

For what it's worth - I'm in the middle of putting together a different design for this idea. Uses some of this stuff but is quite different. I don't know how that affects your decisions here but I thought I'd mention it.

[Jojo-Schmitz]

rebase needed

[RobFog]

Does the merged code implement @Tantacrul's design?

[igorkorsukov]

Does the merged code implement @Tantacrul's design?

No, we are waiting for the final design. Now this feature is merged with disabled by default at the build level.