Forgot to add to the issue description, the score I was using was a 1.3 score I uploaded to 2.0 beta 1. This may be part of the issue, just in case someone need to know.
Yep, good detective work! I had already seen by running under the debugger that that is where the crash occurs - omb is 0 - but assumed the problem was some other change made later, since that code worked when I added it as far as I knew. But at this point I'm not seeing what that other change could have been. Anyhow, should be an easy fix.
Question: when you added the frame in the part, what was your intent? What was the purpose of the frame, and were you expecting the frame to be added in the score & all other parts as well?
So far, we really don't have a concept of certain elements *deliberately* being local to just the current part, although the subject comes up from time to time. But because the layout of the various parts and score varies so much, and because of how all this is implemented, it seems to me it *might* actually be better to make it so adding a frame while in a part adds that frame to that part only. But I'll try to fix the crash and have it add to score & all parts for now, for consistency with how everything else works.
You say you "also" do this for coda, that impies you were doing it for a *different* reason in this case. What was that reason? And in this particular case, would you want the frame added for the score and all parts?
A frame before a coda I would think you probably *do* want in the score and all parts. At least, I know I'd find it a pain if working with an orchestra score I had to repeat that operation a couple of dozen times.
I have a PR submitted that fixes the crash and makes it so adding a frame to any part also adds it to the score and all other parts:
Then, I added the fact that I do this same thing with a Coda. And I mean this part is just in general.
And no, I do not want this linked to the score. I do not want the Frame at the beginning of the first system, and the frame where the Coda begins, to be shown in the score.
I believe the only Frame that would need to be linked between the part and score would be the titles frame. I think the titles frame is the only frame that would needs to do that.
I don't know. If you indent the first system on one part, surely you would want to do the same on *all* parts? Same with the coda system. So at most we might say, you would want it in all parts but not the score. Regarding the intending of the coda system, I'm not sure *why* you wouldn't want it in the score - when I look at published scores, it seems they do this pretty often - but I would agree about not wanting the first system indented.
Absent a way of breaking links on command, it seems to me the best way to handle that would still be to add it to all parts and score, but if you decide you don't want it in the score, you can set it to be zero-width there.
In any case, there are certainly more frames than just the title one would normally want linked. Any interior frames used to create space for explanatory text, frames used to create space for images, etc - these would all appear on all parts as well as score. But indeed, there might be cases where a frame should be unique to just one part, or just the score, and this would be a good argument for adding the ability to break links at some point.
Correct. I want it in all parts but not the score. And regarding the coda and score, you are probably right. I don't read a diverse amount of scores. I mainly read scores that were made for the ministry I work with, and in their scores there is no space between the measure with the D.S. al Coda and the measure with the Coda. They share the one barline between them. (Sorry if that's a little confusing.)
Yes, a way of breaking links on command would probably be beneficial for these types of issues.
And, yes you are right. There are more frames than just the title frame you would want linked. I was just thinking of the major one, that being the title.
Comments
Forgot to add to the issue description, the score I was using was a 1.3 score I uploaded to 2.0 beta 1. This may be part of the issue, just in case someone need to know.
Crash confirmed with 2.0 Beta 1.
For helping Mark and others, I can say that this issue has occurred between:
- Saturday 2 August (Nightly, cf1da9f, correct)
- and on Monday 4 August (Nightly, 49165d, wrong).
Just knowing that there was very little contributions on Sunday, August 3.
So, good luck!
Tried from scratch 2.0
open attached score
look flute part,
select the last mesure,
add -> horizontal frame (or vertical)
Crash !
NB : I reopened Musescore 2.0 , tried a restauration, it restored just before adding frame...
So it is perhaps this, Marc? https://github.com/MarcSabatella/MuseScore/commit/7a19d481cdbce41e3084f…
(Sorry if this is not it!) But it should be around that. And August 3, correspond.
Knowing also that the nigthly (cf1da9f, correct) was the last of Saturday, August 2.
Yep, good detective work! I had already seen by running under the debugger that that is where the crash occurs - omb is 0 - but assumed the problem was some other change made later, since that code worked when I added it as far as I knew. But at this point I'm not seeing what that other change could have been. Anyhow, should be an easy fix.
Question: when you added the frame in the part, what was your intent? What was the purpose of the frame, and were you expecting the frame to be added in the score & all other parts as well?
So far, we really don't have a concept of certain elements *deliberately* being local to just the current part, although the subject comes up from time to time. But because the layout of the various parts and score varies so much, and because of how all this is implemented, it seems to me it *might* actually be better to make it so adding a frame while in a part adds that frame to that part only. But I'll try to fix the crash and have it add to score & all parts for now, for consistency with how everything else works.
I was trying to add a frame to the first system of the part. I also do this where a Coda is needed.
You say you "also" do this for coda, that impies you were doing it for a *different* reason in this case. What was that reason? And in this particular case, would you want the frame added for the score and all parts?
A frame before a coda I would think you probably *do* want in the score and all parts. At least, I know I'd find it a pain if working with an orchestra score I had to repeat that operation a couple of dozen times.
I have a PR submitted that fixes the crash and makes it so adding a frame to any part also adds it to the score and all other parts:
https://github.com/musescore/MuseScore/pull/1238
No, the original reason I was trying to put a frame in a part was to put the frame at the beginning of the first System, creating a space shown like it does here: http://www.onlinesheetmusic.com/the-lonely-bull-trumpet-part-trumpet-in…
Then, I added the fact that I do this same thing with a Coda. And I mean this part is just in general.
And no, I do not want this linked to the score. I do not want the Frame at the beginning of the first system, and the frame where the Coda begins, to be shown in the score.
I believe the only Frame that would need to be linked between the part and score would be the titles frame. I think the titles frame is the only frame that would needs to do that.
I don't know. If you indent the first system on one part, surely you would want to do the same on *all* parts? Same with the coda system. So at most we might say, you would want it in all parts but not the score. Regarding the intending of the coda system, I'm not sure *why* you wouldn't want it in the score - when I look at published scores, it seems they do this pretty often - but I would agree about not wanting the first system indented.
Absent a way of breaking links on command, it seems to me the best way to handle that would still be to add it to all parts and score, but if you decide you don't want it in the score, you can set it to be zero-width there.
In any case, there are certainly more frames than just the title one would normally want linked. Any interior frames used to create space for explanatory text, frames used to create space for images, etc - these would all appear on all parts as well as score. But indeed, there might be cases where a frame should be unique to just one part, or just the score, and this would be a good argument for adding the ability to break links at some point.
Correct. I want it in all parts but not the score. And regarding the coda and score, you are probably right. I don't read a diverse amount of scores. I mainly read scores that were made for the ministry I work with, and in their scores there is no space between the measure with the D.S. al Coda and the measure with the Coda. They share the one barline between them. (Sorry if that's a little confusing.)
Yes, a way of breaking links on command would probably be beneficial for these types of issues.
And, yes you are right. There are more frames than just the title frame you would want linked. I was just thinking of the major one, that being the title.
Fixed in 98f6050e0c
Automatically closed -- issue fixed for 2 weeks with no activity.