'Lock-Score' Tool
As it is becoming obvious that succeeding versions of MuseScore cannot be expected to respect layout and formatting created in previous versions, a tool which would 'lock' an existing score against changes unless authorised specifically (via an 'are you sure?' or other prompt-style pop up) would be most useful.
In addition to protecting scores against unforseen changes in layout due to differing versions, a 'lock-score' tool would also help users avoid making inadvertent changes to note pitches or durations, which can be caused by a careless keystroke or movement of the mouse. Computers may be perfect, but users aren't, and we all know that something as banal as nudging a mouse while reaching for one's cup of tea can introduce unnoticed and unwanted changes.
I suggest putting it in the 'Tools' menu; that would seem to be the logical place.
Comments
See also #88536: Is there a case for a lock on the score?.
Maybe mark one or the other as a duplicate?
The best way to lock a score is to export it as a PDF.
I don't understand what you expect this to do with respect to layout. What exactly would be locked? I think maybe you are confused about what is happening. It is not that MuseScore is refusing to honor your layout decisions - that virtually never happens. If you see differences, in most cases it is simply that the *defaults* have changed - and almost always for the better. But if you had overidden those defaults and adjust things manually, it is indeed likely your manual adjustments will no longer make sense. Still, there is nothing a "lock" function could do about that as far as I can see.
@ Marc: I am not confused about what is happening, but perhaps I could have been clearer in explaining. There are two things here:
1. A lock which would disable automatic re-layout of the score. This lock would instead highlight any measures which, as a result of user input or program version difference, fall outside the default layout parameters. The dialogue would offer the user three options: (a) accept the measure(s) as shown, (b) adjust/fix the layout manually, or (c) allow the program to fix it.
2. A lock which would prevent changes to pitch or duration and disable note-entry input. When the score is locked any user input--keyboard or mouse or touch-screen--would trigger an "Are You Sure?" popup, which informs the user he has just asked the program to make a change to the locked score, and asks him if he really wants to do that. The user is offered YES, NO, and UNLOCK buttons.
YES allows the input, highlights the resulting changes, and brings up a 'Confirm/Cancel' dialogue. 'Confirm' applies the changes, erases the highlighting, and keeps the score in 'locked' mode. 'Cancel' only cancels the changes; it does not unlock the score.
NO directly cancels the input that triggered the "Are You Sure?" and keeps the score in locked mode.
UNLOCK takes the score out of locked mode and returns it to normal mode. (Users who wish to alter more than one note pitch or duration at a time would be able to use this option on the first warning popup, and then re-lock the score (if desired) afterwards.)
This tool could be structured so that it could be set to apply to the entire score, or just to a selected section. There were some requests in https://musescore.org/en/node/54076) for that sort of thing.
I also think any changes made using this procedure should be subject to "UNDO" commands. I know that some changes applied through dialogues are not, and that would be particularly unfortunate for this type of work.
@ Zack--That is a permanent lock; PDF scores are not editable in any practical sense.
Sorry, I still don't get what you mean by "disable automatic relayout". What would you propose MuseScore dominated? With no layout, MuseScore cannot display your score at all. And there is no other type of layout but automation. There are manual adjustments that are made on top of that automatic layout,mBut with no automatic layout, there use nothing to apply those manual adjustments to. I get the feeling you are thinking that somehow by suppressing "relayout" MuseScore would magically be able to reproduce the layout created by a previous version, but that is simply not the case. The layout itselfnis not stored in a score.
The lock against changes makes sense but seems entirely unrelated.
@ Marc--The point of the request about 'locking' automatic re-layout is so that users won't have to go through their finished scores and parts by eye, measure by measure, every time they make even the most minor changes to them. Say I have published a concerto grosso with 12 parts, and a few years after it's released, I get a letter from someone who has found a D in the concertino horn part that he thinks should be a B. I go into my files and check the source MS; it turns out he's right and I made a typo. Ooops. Things like that happen.
So I open the score and change the D to a B...but when I do that, MuseScore automatically re-does the entire layout. Maybe it changed something--a flipped stem can cause a measure to drop to the next line, or move up to the previous one--and maybe it didn't. But I have no way of knowing unless I check the whole score all over again, and that's a lot of work. So what I want is for the program to tell me what, if any, changes it has made--or wants to make--to the layout subsequent to my action in changing that one note, and give me a chance to override the default layout before those changes are saved.
Maybe 'lock' is the wrong way to describe this. Perhaps I should have called that a 'compare to previous version' tool. Does that make more sense to you?
Sorry, I am still not quite understanding. What does this have to do with difference between versions, which was what you mentioned in the original post? Sounds like you are now saying the request is not about changes between version of MsueScore, but between versions of a score - eg, when you make an edit. In other words, you want the ability to make any change you want without a relayout of surrounding notes and live with the errors this creates - like collisions, poor spacing, etc - because you will be careful to only use it in cases where you are confident you can accept the results?
I am not really sure how that would work either, but I can see how it might make sense to think about. The problem I originally described still remains: the layout is not a fixed thing that can be perserved. It is *always* calculated on the fly. There is no way to fix the positions of elements in MuseScore - everything is always laid out dynamically, with a default position calculated autoamtically and then a user offset applied to that. And in most cases, that's exactly what you want - otherwise you'd make a change that requires more space (like changing a quarter note into two eighths) and now suddenly you will have collisions. Or in your example - changing a D to a B creates a collision if there is an "A" in that same chord or in another voice.
So what the lock would have to do is somehow hardcode the width of the edited measure and record that (and then honor that in the future) - thus preventing the change from affecting anything in other measures - and then also calculate the change in position of all elements within the measure that your edit would normally have caused, and then incorporate the *negative* of that into their user offsets. So the result would be that editing one note in a measure would result in that particular measure being marked with a fixed width (a new feature), and also the user offsets of all other elements in the measure potentially adjusted to compensate.
This sounds like an awful lot of implementation work just to allow the user to automatically create collisions and poor spacing. So maybe I am still missing something. To me, if you desire collisions and poor spacing, you can do that already - via your own manual adjustments. I am not really seeing the value of additing a feature to do this automatically.
Okay, I'll try again. Let's start with what I don't understand:
Please correct any of my assumptions that are wrong:
1. If I have a score open and it's just 'sitting there' on my screen, my assumption is that there is no calculation, no on-the-fly layout going on. What I see is what will be saved if I hit CTL+S, and when I close and re-open that file I should see exactly the same thing. So obviously, the layout has been saved as part of the file.
2. Same situation. Score sitting on a screen. I can scroll through it, even zoom it in or out, but AFAIK those actions will not cause the program to recalculate the layout. So the layout at that particular moment is indeed a 'fixed thing', even though I haven't, perhaps, re-saved it since the last actual modification. A 'temporary' fixed thing, in a manner of speaking.
3. Add an action besides saving, scrolling or zooming. Input or change one note. Now the program starts recalculating. It seems logical to me that it has to start those calculations based on an existing state. At some point in that process, several nanoseconds later, the program will determine that the last command I entered requires changing the stretch in certain measures (or moving measures up or down a system, or moving a system to a new page, etc.), in order to keep the layout within the default parameters.
4. What I'm suggesting is that at that precise moment, the program would make the changes it thinks necessary provisionally, and then highlight them so I can see what it's proposing and where, and ask me to confirm, modify, or reject.
As for the problem with different versions, yes, you've made me think a bit more about this one. If the layout information saved by one version is read by a different one, I can see that there's no asssurance the layout could be preserved. What's needed then is information, a warning upon opening a file that it was created by a different version of MuseScore and may not display as the original creator intended.
ad 1) Well, the file does get laid out when loaded. This is why there are suble differences between how a score looks in 2.0.1 and 2.0.3, as there are pissbl e differences between how a scroe look in 2.0.1 on Max, Linux and Windows (2.0.3 tries to avoid these cross plaform diffs). And it shows that the layout is not saved as part of the score. Offsets to the default layout, system breaks, font type and sites, a whole bunch of style settings, etc. are part of the score though
Starting from 1.: the layout has not been saved as part of the file. What has been saved is the content of the file; upon loading the file, MuseScore reads the content and then generates the layout.
1) To be clear: what is saved is the content of your score - the list of notes, rests, dynamic markings etc. *Not* the layout. That is, nothing whatsoever about *where* they are on the page. *Except* if you've made a manual adjustment to some element. Then that manual adjustment is saved - but again, not as an absolute position on the page (which would be disastrous) but as a relative offset from either its own default position or the position of its "parent* (the latter protects against the default position of *this* element changing in the future, and helps ensure manual adjustments are at least somewhat future proof).
Here's a pseudo-code version of what the first line of "Mary Had A Little Lamb" might look in your score if you made a manual adjustment to the position of the word "A":
key signature C
time signature 4/4
measure 1
quarter note E, lyric "Ma-"
quarter note D, lyric "ry"
quarter note C, lyric "had"
quarter note D, lyric "a" with manual adjustment 1sp to the left
measure 2
quarter note E, lyric "lit-"
quarter note E, lyric "tle"
half note E, lyric "lamb"
No other formatting info would generally be saved at all.
Actually, try saving a file in MSCX format and looking at it in a text editor to see for yourself - it might prove very educational as you continue to ponder how your proposed feature could work. You'll see, though, it's basically what I wrote out above but dressed up in XML syntax with lots of angle bracket tags (<note>, etc).
2) You are correct, scrolling does not do a relayout. A layout occurs when the score is read or edited; at this point this actual positions of each element on the page are calculated *in computer memory* and reused until a relayout is needed. Those calculated position are *not* in any way saved to the file, though, as mentioned above. They are kept in memory basically for the sole purpose of saving time when you scroll, zoom etc. So, yes, a "temporary fixed" layout. But there exists no facility for making this permanent, nor could such a thing be done without pretty major changes to the internal structure of things.
3) Yes, if you make any edit, the score is laid out anew. The specifics of how this works are changing in 3.0, but basically, we throw out the old "temporary fixed" positions for elements and calculate brand new ones. In current versions of MuseScore, we do this for the entire score on every edit operation - even on just a Ctrl+A. 3.0 tries to be smarter and detects what will not change and keeps more of the existing "temporary fixed" layout. This can be called "incremental layout", and it is done for performance reasons alone - the actual *results* should be precisely the same either way. But the idea is, a change on page 3 of a score won't generally affect anything on page 1-2, so no need to relayout those pages. And pages 4 & on only need to be laid out again if location of the page break between 3 & 4 changed as a result of the edit, so we can normally only lay out page 3. More than that, we can detect which *systems* within the page are affected in the same way. A change to the third system won't generally affect the layout of the first two, and will only affect the fourth and subsequent systems if the location of the line break changes. So, basically, in 3.0 we try to track what needs to be laid out anew and only do that, keeping the "temporary fixed" layout as is for everything else. BTW, I say "we", but this new incremental layout is extremely new, experimental, and pretty much entirely Werner's work. So while I understand the basic intent of it, I don't have great insight into the specifics of how it works. In particular, I don't know if the algorithm is smart enough to go one step further and only layout the edited measureand not the rest of the system if it detects that the edit doesn't change the width of the measure or anything else that might affect other measures on the system (like ties into the next measure, lyric melismas, etc).
4) I think what you are saying is, at the moment you make an edit - the only time MuseScore relays out your score - you want MuseScore *not* do the relayout but instead *tell* you what would be changed as a result and give you some sort of option. It still isn't clear to me what that option would be or do. But for 3.0 at least, we *do* already do calculations as to what changes and what doesn't: this is indeed the essence of the incremental layout I described above. In principle, it should be trivially easy to highlight the section that is about to be laid out as a result of the change. In many/most cases where you've changed just a single note, this would be just the current system, unless this causes spillover.
But again, I can't see how this in any way whatsoever has anything to do with different versions of MuseScore. Everything you've said here is about what happens after a file has been loaded and you have performed an edit operation. The most that could happen between versions is, as you suggested, a warning that pops up on load telling you the file was saved with an earlier version. That would be a nusiance to most people most of the time, but if it were a preference you had to manually enable, I wouldn't oppose it.
This is all very interesting, but it would have been better on the forum since we are discussing several things and there seems to be a misunderstanding right from the start between "locking the edition of the score" which is already filed at #88536: Is there a case for a lock on the score? and locking the layout in next versions of MuseScore? which will be very hard to achieve because we currently don't save anything about the position of elements. I let this issue open for a little while but I think it's ok to close it once the discussion is over and then create one or more proper feature requests if necessary.
Keep ALL old MuseScore install files.
Really, the issues I've had are from 2.02 to 2.03, but I suspect they are present in 2.04β and 3.0β.
I suspect they can't lock scores to look like whatever the previous version showed in a newer version.
PDFs (EMBED FONTS!) are probably the best way to "lock." Really, if you can afford it, use Acrobat. (I can't afford newest, so I use v 6.0 which works great, still.)
If you need to edit later uninstall the "latest and greatest" MuseScore and downgrade to whatever you had when the score was perfect.
The developers can not currently test the program on Windows outside of KDE, Wine, Gnome, or whatever it is they use and I suspect these changes you are seeing can't be replicated on their systems.
You've already seen and commented on some of my remarks about this.
I'm still going back and forth between 2.02 and 2.03.
I like the updated features in 2.03 but all my older scores look like garbage if I open them with 2.03 and the developers can't replicate the problems. For which I have three words.
$50. eBay.
(Fifty and Bucks are two words.) They can search for "Laptop" in "Laptops and Netbooks," specify Windows 7 Professional" for OS and de-select "For parts or not working" in "Condition."
I wonder what the newest upgrade for Qt! costs?
@ Marc--Thank you, my dear sir, for that excellent and very detailed explanation. I am now much better informed than I was previously, which is always a good thing. I think we are on the verge of what the corporate types call 'consensus'. ;o)
Based on that, it appears that what I have been requesting is not only 'trivially easy' but that the basis for it is already in the pipeline for 3.0. All we need now is to implement that highlighting option, and to provide a control which would enable the user to enable that when needed. Users doing input or major editing of a piece would not need nor want this; it is when a user is making minor revisions to a finished and fully formatted score--one ready for print--that this becomes important. So an option to 'lock layout' seems to me the way to go.
As to the options to offer a user when in 'lock layout' mode, I would suggest Accept, Modify, and Cancel.
If the user clicked 'Accept,' that would tell the program to apply the highlighted layout changes in the usual way.
Clicking 'Modify" would select the 'trigger element' (the new/changed note, whatever), and give the user the opportunity to manually adjust the positioning of that element (or the stretch of the measure it is in) before recalculating the layout--and highlighting the proposed changes--once again.
'Cancel' would erase the user's original change, and return the score to the state it was in before the user made that change--essentially, an 'Undo' command.
No argument on this; I would be more than happy to have that option available in 'Preferences'. The only other thought I have on the subject would be in line with SeasonPsalt's perspective about maintaining all versions of MuseScore. IOW, it would be a good thing if downloads of subsequent versions of MuseScore would NOT automatically replace former versions, but would install themselves under unique version names alongside those older versions. That way, if I need to edit a score I created in 2.0.x a few years from now, I will be able to run that version of the program to open it.
For the record, there are many developers, and some of them do use Windows. It's just that none of them happen to be commenting on the threads having to do with thew specific issue you are presumably referring to.
To be able to open older scores with the MuseScore version it was created with, you can use the portable apps.
Until a lock-file feature is added to Musescore, one can remove the write permissions of a file, and thus the ability to modified it, through the terminal/command-line, or in most cases, the file manager GUI. For example, in the gnu/linux OS Xfce, one can simply right click on a file, select "properties", "permissions" tab, and then the appropriate permission. Also, one can revoke the write permission of a file/directory using the terminal/command-line.
In any gnu/linux system or Mac OSX, for any file or directory, launch the terminal, and enter...
# Revoke write permission
chmod a-w /path/to/musescorefile.mscz
# Re-invoke write permission
chmod a+w /path/to/musescorefile.mscz
"chmod" is the bash command to change file or directory's permissions. The "a" means all (i.e., user/owner, group and others), "-" or "+" means revoke or add the following permission respectively, and "w" means "write".
After the write permission of a file has been removed, the file is essentially "locked" in that it can not be modified until the write permission is re-invoked. Any modifications made to a file in Musescore can not be saved, thus protecting the original file. For an excellent tutorial on file permissions in linux, check out the following: //ryanstutorials.net/linuxtutorial/permissions.php
And making this changing write permissions possible from inside MuseScore might serve as a lock option.
I can't seem to delete this comment? I'll be back with more.
There are a few things one can do to deal with the problem of an edit altering the layout all the way to the end of the score:
1. Use page layout. You'll see the changes right away and don't need any warning feature. If the line breaks don't change on the page you are editing then your score layout will be unchanged to the end. Otherwise you can try to "force" it back to the old layout by playing around with the stretch and then decide if you want to accept the layout change or not.
2. Start any proofreading or formatting from the beginning of the score. That way you don't inadvertently screw up the pages you already corrected.
In my experience it is a good idea though to go over the score with care every time before printing or exporting to Pdf: I find almost always things to fix.
It's blatantly obvious that there needs to be a way to lock measures; meaning when locked they cannot or will not be changed. It's incredibly obvious that the tiniest of edits in a measure can massively screw up everything that follows. It doesn't matter if it originally was a manual change or not. These unwanted changes are one of the most annoying and time wasting aspects of Musescore. Also to go along with this, there needs to be a feature to copy and paste pitches only, not the rhythmic value. Likewise there probably needs to be a feature to copy and paste only the rhythmic values but not the pitches. MuseScore does a nice job in the end, but working with it is extraordinarily frustrating, often due to unwanted changes to large sections of the score that don't need attention. I noticed too when copying and pasting sections, that a complete measure copy does not grab everything. I work with Inkscape a lot and while it does have a learning curve, it's much easier to work with because it does not make automatic changes and elements can be locked. Also there needs to be a way to assign the voice number to a series of notes. Exchange voices is rather poor because if you try to copy voice 2 notes to another measure where you want them to be voice 1, they insist on remaining voice 2 even though in the measure being pasted into, there is no need for a separate voice other than voice 1. So the larger issue is the entire manner in which copy and paste takes place.
Not sure what you mean about an edit to be measure affecting others. The content of other measures is not affected, only perhaps the layout. Meaning a lock tool wouldn't help. If Im understanding correctly, simply inserting line breaks is all you need to lock the layout so that edits to one line don't affect others. Feel free to ask for help in the Support forum if you continue to have problems. When you do so, be sure to attach the score you are having trouble with and describe the problem in more detail.
Similarly, the other subjects you mention are unrelated to this "lock score" issue and should be discussed in the forum as well.