Track changes??

• Jun 2, 2016 - 22:36

This may be a completely off-the-wall idea, but I'll throw it out there for discussion. What the heck--the goal is to make MuseScore better than any other scorewriter out there, bar none. So let's see where this could take us.

In publishing music, doing the original input of the music (whether copied from a contemporary edition or a new composer's MS) is often the smallest part of the work. Once the input is 'done', a LOT of time is subsequently spent editing and revising it, and usually there are several people involved (associate editors, instrumental specialists, whatever), in that process. When they're all done contributing their musical expertise, the whole score has to be proofread at least twice (by two different teams), before it is finally ready to print. Only this way can a publisher know that he's done his 'due diligence' to provide the ultimate users--the performers-- with a quality product that contains as few errors as possible (there are rarely none at all, but that's a fact of publishing we won't solve here).

Anyway, that's a lot of changes to a single original score, and keeping track of them all can be a major task in and of itself. In publishing text works, editors and writers use word processing programs such as MS WORD, most of which contain some sort of 'Track Changes' tool. This enables ALL changes made to the base text file to be seen by everyone involved and tracked, accepted or rejected; it also enables the author, editor, copy-editor, and proofreaders to add comments and questions to the text when necessary.

I'm in the process of comparing edits on a bass figuring from an associate specialist editor to the original figuring written by the composer of a new work. The only way I have found to comment or question the FB editor's changes to the figuring is to add comments as 'lyrics', and, while this works, it's clumsy and time consuming. (And if the piece had actual lyrics in it, it would really be a mess, but that's not the case for this particular score.)

Would it be possible for something like the MS Word 'Track Changes' utility to be developed to work with MuseScore? Such a tool would show changes in a different colour (or even a different colour for each editor/proofreader), and would comprise an 'accept/reject' function as well. If that's not practical, could we at least develop a new class of text, 'Comment Text', which could be anchored to any element (including bass figures), and would then highlight that element in yellow (or whatever), and show the comment text only when the mouse is hovered over the anchor element? Either or both of these tools would be a great boon to professional users, as well as to music educators who want to correct their students' homework assignments in digital form.


Comments

In reply to by shredpub

Good to see the annotation idea is currently being worked on. That will be particularly valuable for collaborative editing and educational users.

If you're familiar with 'Track Changes' in Word, for instance, you'll know that the essential difference between a 'comment' (annotation) and a 'change' is that when the track changes feature is turned on, all changes to the text made by the last editor show up as inserts/strikeouts, in a specific colour. Graphically, this might present some interesting challenges in a music score (hash-marks over a 'struck-out' portion, perhaps?), but the important thing is that the original version of the material is retained in place in the file alongside the suggested revision until the current editor accepts the change (done with a right click, or globally via a menu tool). (If he rejects the change, the original version stands and the suggested revision is deleted.)

This sort of utility would enable me to send a score to a specialist (a continuo editor, for example), and receive back a modified file showing his suggested changes side-by-side with (or directly below/above) the original material. I could then check that with the composer or source edition and make editorial decisions on which changes to accept or reject, without having to go through the entire score manually, one measure at a time, working two different tabs on MuseScore simultaneously. That would be a VERY big time saver.

In reply to by Jojo-Schmitz

Hmmm. Not sure exactly how that would work, but obviously you guys MUST have developed a system that enables multiple people to work on the same code and let everyone know what everyone else has done/suggests doing.

Can you give me an idea of the way we might use git to keep track of changes to a score? If I were to post a score there so an associate editor could revise it, what would I see when I went back to look at it afterwards?

In reply to by Jojo-Schmitz

Heh, heh. Now I feel as you did when you asked me to explain printing paper basis sizes and weights! ;o)

I used to run ACAD on command line, so I might eventually figure that out given enough time to remember what little I once knew, but there's faint hope most of my associate editors and proofreaders would be able to do so. I think we're going to have to depend on you guys to make this a dummy-proof, UI-accessible feature in MuseScore itself.

How much of the basic 'track-changes' code structure is available to developers outside of Microsoft by now? That feature is well over 10 years old; I would expect it to have been re-engineered and improved long since by collective-commons developers.

In reply to by Jojo-Schmitz

MSCX might look like just text but they are XML and diffing a text or a XML file is quite different...
It will work and be relatively easy if the user changes a pitch or add a note or an articulation but what if the user do one of the following: append a couple of measure, delete a part, reorder the remaining parts, insert a couple of measures with a different time signature and shorten some others? There is no way that we can make a usable diff out of this...

That being said, the idea of saving revision of a score is in the air for years. In the thirdparty directory, in the source, there is the diff-match-patch library since 2010 but so far nobody took the challenge. As I said in another post, I feel this is a nice feature but it's a very low priority to me, I would prefer to focus on the most common use cases and I feel they don't need such a feature. However, I'd be happy to review any implementation.

In reply to by [DELETED] 5

@ Nicolas:

In the world of music publishing, the most common use-cases would be unlikely to include major structural changes to the score, such as those you mentioned. By the time an editor starts sending out a score for proofreading, or for verification by specialists, the basic structure of the score has already been established (length, instrumentation, etc.). The discussions between a composer and his editor about the overall structure of the piece are long since settled, and revisions in that round of editing will usually happen by an exchange of new versions accompanied by text directives (John--take your second theme at measure 32 and transpose it to the subdominant for the English horn solo, then modulate back to B-flat major for measure 64 for the recap before you go into the third theme...) . And in the case of historical editions, that sort of thing doesn't apply anyway. We're working from autographs or first editions, and no major changes of the sort you worry about would ever be made.

The sort of thing that might happen at that stage of editing is that a repeat and its voltas might be eliminated and converted to full-length musical notation, or an instrument might be changed globally for another one (treble viol for a pardessus, for example). But those changes are not 'measure-by-measure' things; the burden on the editor and composer to compare differering versions in such cases is not great.

The same goes for music educators correcting students' homework assignments. If the teacher wants a student to change the entire structure of a piece, he'll say so in a written message, not in the score itself. Again, it's the measure-by-measure stuff that takes an inordinate amount of time to check without some sort of automated feature that calls out all the suggested changes visually.

Currently, when I have to send or review 'measure-by-measure' revisions of a score to/from a composer or specialist editor, we use the inspector to 'highlight' the changed material by printing it in a different colour. This makes it easy to see where the score has been changed, even if it also requires opening two different files at the same time and manually comparing them. The problem with that is that lyrics and figured bass (for instance; I haven't yet experimented with dynamics, staff text, and articulations, just to mention a few other elements) can't currently be re-coloured or highlighted. Changes in the inspector have no effect, and changing a text style would not be useful, as we would want to recolour only a SPECIFIC element, not all of them.

In reply to by Jojo-Schmitz

@ Jojo--

:-) indeed!

Thanks for 'getting' this idea. Sometimes I think the more difficult part of the process is 'selling' the idea itself, rather than actually implementing it. (Of course, what I know about implementation could be written on the back of a postage stamp with a big, fat felt-tip marker. But you already knew that!)

Do you still have an unanswered question? Please log in first to post your question.