Lock notes

• Sep 12, 2019 - 18:20

It is horribly easy when editing a score, to tidy up slurs, and so on, to knock a note from its rightful place. I have seen professionally published scores looking a bit like this:

ouch.png

A "lock notes" function would disable anything which changes the notes. For people (perhaps young ones) with perfect hand-eye coordination, perfect memory, perfect pitch, and general perfection, this might sound silly, but I think it would be very helpful to many of us.


Comments

I'm not sure how useful "lock this set of things, but not that" would be, but "lock this score, period" (can't modify it at all) would be great. Sadly, some things that are "really only looking" like changing page format or Concert/Transposed pitch, or making all invisible objects visible, modify the score.

In reply to by BSG

I agree a "read only" mode would be useful but especially if it allowed certain "non-destructive" operations like those.

Right now, we kind of have a read-only mode - if you use the View / Score Comparison Tool, and compare against a "last saved" version, you get a tab with a read-only view of the state of the score when it was last saved. I seem to recall it was implemented as a quick hack, intercepting the command interpreter to just not allow any commands through. Probably this could be adapted to allow this to be a flag set on any score, but to then also let "some" operations through.

In reply to by BSG

If you open a score which you've carefully made read-only to the file system, it should act as other editors do, i.e., prohibit modification of the score and complain if you try, unless you explicitly override.

In reply to by Marc Sabatella

Well, we have the Selection Filter that can already limit by element type, but I think limiting by command is maybe more relevant. I'm not so sure there needs to be user control over this, though - could be a hard-coded list, just the things that one might be likely to want to do with a read-only score, like toggle concert pitch.

I imagine we have a similar use case in mind - making educational materials a student can browse without fear of messing up.

Not to cast anything negative on the proposal which may have use, it strikes me that any professional publication that has such an error has poor editing practises.

In reply to by xavierjazz

I don't understand what this means. Not only are only a fraction of the users of MuseScore professionals, but it is dreadfully easy for even a skilled professional to accidentally click something while scrolling or dragging or whatever and not see immediately what he or she did.

In reply to by BSG

It seems an obvious thing to see with cursory inspection. It was not proofread. I find it difficult to believe that a professional, one who gets paid for his/her work would be so cavalier.

I too work for myself and I too make errors. However, I re-read what I write.

In reply to by xavierjazz

Yes, of course it is obvious. No doubt the score was proofread, but after proofreading a note got knocked accidentally. No-one knows who knocked it, so no-one can really be fired. And anyway the real problem is that it is easy to knock a note in a way which really isn't obvious. I am just trying to suggest another tool which could help to reduce errors.

I agree that a playback/read/view-mode makes sense to have.

Aside from that, I've noticed in courses that people that frequently have this occurring are those that use the mouse to drag the view of the score. This indeed makes it easy to by chance drag the wrong thing, which indeed could be missed when doing a lot of dragging subsequently.
Once they switch to using scrolling to move around the score, most of those complaints diminish or vanish. Certainly as soon as they discover that you can scroll horizontally by holding Shift while scrolling normally.

In reply to by BSG

Let’s not forget: if you have completed your work and expect no further edits/revisions, in Windows you can right-click on the file name and check the option (I forget what it’s called) to lock the score. I assume apple and linux OSs have a similar option.
You can still open the score and “experiment” but if you attempt to save it the system forces you to give it a new file name.
Short of this, I can imagine a feature where you can check off the following line items selectively:
Lock notes
Lock dynamics
Lock articulations
Lock tempos
Lock lyrics
Lock staff text
Lock system text
Etc.

In reply to by marty strasinger

Other editors (i.e., Emacs/Aquamacs) don't work that way. If they open a read-only file, they open it in read-only mode, and reject attempts to modify it. You can remove read-only mode, and if you try to save it, it will ask you if you want to overwrite the file system protection. If you want to experiment with a read-only file, you can remove read-only mode locally in the editor.

In reply to by marty strasinger

It is called "Read-only" in Windows, and it is taking away the write permission on Linux/Mac for user, group and/or other.
Opening such a file in MuseScore shows the 'Save' icon and the File > Save option disabled
Not consistently though, after some changes and undos ... those become eneabled, but saving still doesn't wotk, a message box shows on trying this,

The following file is locked:
(filename)

Try saving to a different location.

File > Save as in same dir and under the same name is blocked by the OS then

As has already been said, it is quite easy to accidentally move an item instead of dragging the score so a read only mode would be useful.

Perhaps locking at the measure level would be practical. I rarely input a whole score in one sitting and it would be useful to lock the measures in a section that I've already completed. Of course there would need to be a means of unlocking if changes are subsequently needed.

In reply to by yonah_ag

The problems occur if the user mistakenly selects a movable item before attempting to drag the score. Therefore perhaps an option to disable drag/drop for movable items would be a better way to go than making the whole score read only. This would still allow editing/moving in all other ways than drag/drop. Could this be done just for the duration of the drag by holding down a key while dragging with the mouse? (e.g. shift + left mouse key, or does that already do something?)

(Personally, I would not miss drag and drop if it was permanently disabled; much better and accurate control of position is available via the inspector. However, some users seem to like it and each to their own.)

Regarding Ctrl+shift+End. This is useful if you want to go to the very end. However, I suggest that a more frequent use case is wanting to go to that bit that you think is somewhere around 5 or 6 pages from the end.
Dragging the score is a more intuitive way to find the place.

In reply to by BSG

I meant it "somewhat" seriously. It would be trivially easy to disable the score drag command. It's completely unnecessary, doesn't do anything the mouse wheel doesn't do more effectively. With score dragging disabled, people would get out of the habit of using it, and thus would no long accidentally drag elements when they are trying to drag the score because they would no longer be trying to drag the score.

Of course, there is no need to actually disable dragging, we could just strongly encourage people to stop dragging the score.

In reply to by BSG

Doesn't your trackpad allow for that directly without the need to drag? I thought that was one of the features of the Mac trackpad. In any case, it still ends up being at least as efficient in most cases to simply scroll horizontally then vertically, or vice versa. I literally don't think I've dragged a score in years nor seen any benefit to being able to do so.

In reply to by Marc Sabatella

Oh, I see, that's not dragging --- got it. No, I never ever want to grab a score and drag it. But while scrolling a score in that fashion, occasionally a finger slips (so it's no longer "two fingers") and some object is affected. Maybe the OP meant that, too.... ?

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