Progress Log

Updated 10 years ago
This page shows old instructions for MuseScore 1.
For MuseScore 4 users, see Progress Log.

This was removed from the main page. It basically contains a log of the progress I made on the project over the summer.

Progress Log

Current Work (last updated 23 September 2013)

  • Continue debugging errors related to fonts.

Next Steps

  • Verify that the score has loaded correctly
  • Get a score to paint on the screen
  • Clean up the libmscore changes

Previous Work

  • (7 September 2013) Verified and loaded a score, but loading more complicated scores with text (as well as rendering) has presented issues with font loading, therefore I've been looking into that problem. It seems that QPF format fonts might be easier to load, but getting the makeqpf utility which creates those files proved complicated, as QPF doesn't seem very current with Qt. Talking to the creator of emscriptenqt, it seems the true;type font loading issue might be a problem within emscriptenqt itself, so I've been exploring the source trying to track it down. In the meantime I've created my own branch of emscriptenqt to track changes.
  • (23 August 2013) Continuing work on loading the score. Initialization seems to be working, but I had to comment out some methods to get that to work, which appear to be causing problems with the loading of a score. I now either must stub out all methods related to some of the graphical initialization which was skipped, or re-visit some of the initialization code. For the time being, stubbing out the methods seems to be the better option until I can get a score fully loaded and verified.
  • (15 August 2013) Currently working on loading a score and verifying the score loaded correctly (by printing out some meta info). Right now, I have exposed some methods to javascript which allow me to load the score, and I'm sorting out some bugs related to the transition from a traditional desktop app to a javascript one (embedded files, initialization, etc.).
  • I'm also working on creating a better testing process. I had looked into using PhantomJS , but it appears they're using an older version of webkit which doesn't have some of the javascript features required by emscripten. For now I'll just be using javascript files and the javascript console.
  • (updated 30 July 2013) Working on getting just one class (Score) to have some methods exposed so that I can load a score into the browser and then hopefully render it. So far I'm able to instantiate an instance of score in the browser, but I'm getting some weird thing about unbound types. Been getting help on the emscripten irc to sort through these errors. Hopefully this won't be too much of a set-back.
    • Relevant paste: paste
    • update: I've abandoned using embind for now, and I'm just using C wrappers and "EXPORTED_FUNCTIONS." This seems to be a lot simpler to expose more methods, although it's a little less flexible and not as streamlined.
  • UPDATE (24 July 2013): I've created a repository for the embindgenerator script here: repo
  • UPDATE (23 July 2013): Using the doxygen XML file I'm able to extract code structure from a collection of source files. I then feed that file into a node script I'm developing which parses the file (using xmldom, a node module) and traverses the document, generating a cpp embind file as it goes along. This script is not yet complete, but I'm making steady progress. The script is already able to identify structures which need to embind declarations generated for them.
  • UPDATE (19 July 2013) : Continuing experiments with embind lead mixed results. Succesfully got some example projects working with the "EXPORTED_FUNCTIONS" method, and when calling embind on a single file, but when trying to use embind on a project consisting of more than one file I'm having lots of problems. I successfully generate the bitcode, but it seems that these methods aren't getting exposed in javascript. I'm going to do some more experimenting and debugging as well as trying to find more documentation on embind and asking for help in the irc. I've also been looking into automated generation of the embind bindings. It seems someone created a tool for visual studio which does it (can be found here ), but using visual studio is far from ideal. Talking to the creator, it seems that he got doxygen to generate an xml file containing the layout of the code, and then using that generated code structure created the embindings. I think creating a Node.js tool which generates these embindings would be something worthwhile. Once I get the bindings created manually working, I'm going to look into that.
    • UPDATE (20 July 2013): After quite some time of checking and re-checking my work, turns out I was using "--embind" as the compiler flag, instead of "--bind" which is the correct flag. Embind seems to be working as expected now and I plan to move on to creating a tool which will automatically generate embind files.
  • UPDATE (9 July 2013) : First taste of success -- generated bitcode out of the libmscore source using emscripten. Unfortunately, getting libmscore's c++ classes and functions exposed to Javascript may prove a bit tricky. It seems there are several routes to take. I'm going to do some research and possibly a little experimentation with these methods before committing to one.
    • Emscripten, interacting with code: link
    • Embind, a tool which exposes c++ classes: link

    Hopefully I can find a way to automate as much of this process as possible to make future patches simpler.

  • UPDATE (6 July 2013): Figured out how to get emscripten-qt to compile with support for SVG and QDeclarative stuff. After some experimentation, solidified that LLVM 3.4 will not work with emscripten, at least not without more patching to emscripten itself, which is likely outside the scope of this project. That left me with either rewrite parts of libmscore to use different data structures or modify some header files that used the atomic calls. Since everything in emscripten doesn't use multiple-threads, I can just modify some of the headers to do their literal sequential operations rather than use the (unsupported) atomic calls. This seems like the most likely solution right now. After I complete this, if everything seems to be working, I'm going to go back and clean up some of the libmscore changes I made which I don't think are necessary anymore.
  • Modify the header to stub out the atomic methods doing their simple sequential counterparts instead.
  • Create a qmake build for libmscore that uses emscripten-qt's qmake.
    • UPDATE (28 June 2013): Have been fighting with basically getting a square peg to fit in a round hole. Encountered a bug in llvm 3.2 in which some library functions for c++11 weren't yet implemented. These bugs were fixed in 3.4, but emscripten only supports llvm 3.2. A branch of emscripten supports llvm 3.3, which I've been trying to make work for llvm 3.4. Emscripten-qt's demos failed, but I decided to go ahead and try to build libmscore with this configuration anyway, but I've been encountering lots of inter-dependencies between libmscore and the rest of MuseScore. I've mostly been solving these by stubbing out methods and commenting out lines, tracking any changes I make in a log. If this configuration of emscripten and llvm doesn't work, I have talked with lasconic about several alternatives I might pursue.
    • Pursue alternative configurations, listed below.
      • Try to isolate the bugfix in 3.4, and fork llvm
      • Rewrite the parts of libmscore which are victim to the bug in llvm 3.2. It seems like it might be Map or atomic operations causing the problems.
    • UPDATE (21 June 2013): I've created a qmake.pro file, as well as some other files which are normally intermediately generated during a build (all.h and config.h), which seem to be working well. Now I'm just plowing through the innevitable rampant compiler-errors. I'm keeping track of all the changes I make from a "vanilla" libmscore build so that I can walk through all my steps as well as reproduce it. My goal is to get everything to compile with emscripten, and then once it's working go back and optimize.
    • For reference I will look at https://github.com/wschweer/mscoreserver which also uses qmake to build libmscore.
  • UPDATE (18 June 2013): emscripten-qt configured and working. Wrote up a short summary of the steps to get emscripten-qt running attached as a child page.
  • UPDATE (17 June 2013): Continued attempts with emscripten-qt show light on a possible bug in emscripten, looking into work-arounds. Also began work on what will need changed in libmscore's build process (CMakeLists.txt and such) to use the qmake from emscripten-qt as well as emcc and emscripten's build tools. Should more or less still be on schedule with the original proposal timeline as long as I can solve these problems by the end of the week.
  • UPDATE (6 June 2013): having some difficulties getting emscripten-qt examples to run. I've been exchanging correspondence with Simon St James (creator of emscripten-qt) to sort through them, who has been extremely helpful. Making progress.
  • Setting up my work environment, git, etc..
  • Looking through libmscore code and reading relevant documentation (especially coding rules).
  • Reading Emscripten documentation
  • Learning the details of the libmscore build process