The New “Stafftype Template” Model

In an IRC chat several weeks ago, I found out that my original idea “separating notation from score files” was a bit extreme for MuseScore’s devs.  Originally, I wanted to keep alternative notation completely out of the score files, but seeing as there’s nothing like that in MuseScore right now…  Well, it ain’t happening any time soon.

On the bright side, there’s still a very smart, very flexible way to implement alternative notation,  I am now merging notation data with the existing Stafftype class.  This will allow notations to be set on a staff by staff basis.  Just as important, I will still be able to save notations in their own files.  Notations will now be saved and loaded as “Stafftype Templates”.

Currently, I’m working on an editor for creating, loading, editing, and saving Stafftype Templates.  Once this is done, I need to make sure the notation data is passed around smoothly.

All this has been quite time consuming, and there are a lot of things to test.  I haven’t been able to get a working prototype finished yet, but…  If you want to see the current state of my code (which at least compiles and runs successfully), get it here: https://github.com/CraigFisher/MuseScore/tree/pre_alternative .  (I’m using a new temporary branch for displaying my changes on Github until I have a version that can actually run the notations again)

Sponsored Post Sponsored Post Menu More Info Learn from the experts: Create a successful blog with our brand new courseThe WordPress.com Blog

WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.

Register now

Automatic Updating of Scores

When the user loads a notation file, the score is now updated automatically to reflect the new notation rules.

I also have a new bug to report (though it should be unrelated to the automatic updates):

– For chromatic notations (where octaveDistance > 7), extra ledger lines are sometimes printed above and below the staff.

Improved Inner Ledgers

In the previous system, inner ledgers would appear if a note intersected one or two “inner ledger points”.  This worked for most cases, but if a note didn’t actually touch the inner ledger, there was no way to make it appear.  Now, notes are mapped to their inner ledgers.

Neither of these options would have been possible before:

Simpler note positioning. More demos.

Up now on Github…

First, the note positioning code is much simplified.  In the note class, I’ve removed all the ugly code from the getters and setters for “_line”.  Instead, the note repositioning is now done purely in the absStep in utils.cpp.

Second, all the demo notation files have been updated.  There are three of them.  The file “samplenotation.xml” now demonstrates the new, much more flexible innerLedger system.  I’ll be posting more about that soon.

Important usage notes:

• The original notation files will not work with the new system.
• When you load a notation, the notes in each measure will not display correctly until something within the measure is modified (my next priority is to automatically re-layout the entire score when notation is changed)

Github update

I pushed the wrong branch to Github yesterday.  Everything should be there now.  I’ve also included a new “traditionalsample.xml” file demonstrating traditional notation in terms of alternative parameters.

Current bugs:

– For the moment, if any new scores are opened AFTER notation is changed, all the notes will be on a single line (due to an improper initialization)

– When using any notation file (including one with “traditional” parameters) , shifting notes up and down will cause all the notes in the measure to shift up and down.

Progress from July to Present

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.

Design Discussion

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