2013/11/23 maxpol <[email protected]>
> Hello folks,
>
>
Hello! Good to see you here! Good job on Audiveris!
> after setting up a development environment for Musescore I was thinking
> awhile about contributing to this amazing project.
>
> The first thing that came to my mind was the OMR feature. I already read
> several topics in the user forum full of criticism regarding the Optical
> Music Recognition in general.
>
> I'm aware that this topic would most likely start a long controversial
> debate. Nevertheless, I assume it would be nice to have this OMR feature
> because I've found out in my daily work as musician that partially working
> solution is better than no solution at all.
>
Yes. OMR is a hard problem and we often expect something magic to happen
even with a just a bunch of pixels.
Nevertheless, when it does work, it's great and indeed feel magic. I did
get some wow moments with Audiveris!
>
> I'd like to volunteer myself for working on tighter coupling between
> Musescore and Audiveris.
Welcome! Way to go. Combining Audiveris OMR and MuseScore music notation is
definitely the best way to have good free and open source notation suite.
> The existing (one way) method of communication
> between these two apps via plugin mechanism has been proven to be very
> limited and less useful for real-world transcription work due to the
> following drawbacks:
>
> ---> Audiveris doesn't provide a musician-friendly WYSIWYG editor. Although
> it offers several possibilities to drive the recognition process at the
> graphical level, it's almost always better and faster to work at the
> notation level.
> ---> Before a document processed by Audiveris, especially one with missing
> notes and rhythmical errors, can be imported in Musescore, it has to be
> fully fixed in Audiveris. Otherwise, the resulting MS score will look like
> a
> mess. There is currently no way to cope with partial or erroneous
> recognition results.
>
>
The current way via plugin is in fact two ways :) the plugin send a PDF
score and got the log of audiveris but I understand what you mean.
The last point is linked to the "quality" of the MusicXML exported by
audiveris. I think there are simple fixes that could be done to make the
job of the user more easy.
For example, Audiveris sometimes export incomplete measures, or incomplete
voices, or weird cross staff voices. If we could instruct it to be more
"strict" on the MusicXML export, it could make a huge difference for a user
using MuseScore to fix the notation.
On a similar note, I believe Audiveris would benefit from more musical
input parameters. Something like "this piece is only 4/4, and only one
voice, don't try to guess out of this".
> Therefore, I'd like to propose the following roadmap:
>
> On Audiveris' side:
>
> 1) design a Java API for use within C++ applications providing methods for:
> ---> setting up recognition documents
> ---> passing user options and configuration parameters for processing
> ---> run the recognition either on the full score or any part of
> ---> retrieving score bitmaps
> ---> retrieving recognition results
> ---> providing Audiveris' OMR engine with "error reports" derived from user
> corrections
>
I love this plan!
I'm not sure what you mean by Java API for use within C++ but if this means
JNI, I don't think it's the best way to go.
I would prefer running audiveris in a separate process and have MuseScore
and Audiveris collaborate via IPC or even better a web API, via a local or
network socket. This could be made language agnostic, would enable to run
MuseScore on one computer and Audiveris on another one, and would make
Audiveris usable in other use case than just the MuseScore one.
If the API is good enough to use Audiveris as an engine and MuseScore to
drive it, I think we'll have a win.
>
> On Musescore's side:
> ---> extend the OMR pane with the possibility to choose either Werner's OMR
> or Audiveris
> ---> design a C++ bridge for calling Audiveris API
> ---> provide an amended score editor ontop of libmusescore for quickly
> correcting recognition errors in a musician-friendly way
>
>
Idem here, the C++ bridge would be just a web/ipc call.
Werner will probably comment further on the OMR feature but AFAIK it was an
experiment to detect staves and barlines (and eventually noteheads) from
PDF files and then synchronise a MuseScore ScoreView with images of the PDF
files. If the solution you describe does a better job in the end, having
both methods will make non sense.
The main problem to compile the current code will probably be the PDF
parsing library. The code used a old non documented version of this
library. According to the IRC log, you have sorted this out so that's
great!
Talk to you soon,
lasconic
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
