The first public version of my code is up on github: https://github.com/CraigFisher/MuseScore/tree/alternative. All my changes are labeled with “//cc” marks. I’ve included a file called “notationsample.xml” and a file called in the demos folder. To test it:
- go to Preferences > “Notation” tab
- select “Use alternative notation file”
- select the file, and hit O.K.
- At this point, some but not all of the notation changes will be visible. To see them all, edit any random thing and voila! (Most of the changes will not be applied until a Layout() routine is called, and I haven’t settled on the most desirable way to do this yet)
Feel free to mess around with samplenotation.xml and see what you get. I’ll post more notation files soon.
I’ve been chugging along for about two months now, but I’ve hit the point where I can’t really continue without setting up this little blog. Most of my work so far has been proof-of-concept. Now I have to make longterm design decisions.
Passing parameters from files
I’ve created a NotationRules class whose purpose is to read and store the notation params. It reads them from xml and stores them in static variables. I plan on re-organizing this once I develop a REAL gui, but at least the NotationRules class is pretty well encapsulated. On that note, my whole idea of loading a notation file from Preferences is completely temporary.
Setting notation parameters in score object
My first concern was “separation of visual display from score data”. I wasted to make sure I could tweak certain notation parameters without creating persistent changes in the data. I’m happy to report this part was breezy. I can modify all of my intended notation parameters without messing up files. For example, I can make G’s look completely like C’s, when I load the file again in a “normal” MuseScore, everything’s back to normal. The same is true for accidentals, staff lines, noteheads, and all the rest.
To do this, I modified the functions of several classes, including Note, Chord, StaffType, and StaffLines. I give these functions data from static variables that hold the alternative notation parameters. That said, these hacks are not longterm solutions for the following reasons:
- Sometimes they modify getters and sometimes setters. Very inconsistent.
- In a few cases, I created my own getter function and then forced the class to internally use that getter function. Anyone could easily set the private variable somewhere else and break my code.
- For some parameters, most of the original layout calculations are still performed, which is unnecessary since those calculations are also ignored