Image on parts missing or resized
Hey there.
Version: 2.0.3 Windows
Expected behaviour:
If creating a part from a score that contains an image linked to the "title box", the image should appear in all parts without being resized.
Actual behaviour:
It only appears on some parts and moreover, the size does not correspond to the size it has on the original score.
Comments
In my version of MS, the image attached to the title frame only appears in the first part which is created. If I copy and paste the image from the score into the second part, it will appear positioned at the intended location in all parts. But now, the first part owns the image twice.
Is there anyone who can explain how the title frame information is passed from the score to the part and in which part of the source code this is done?
I would like to have a look at this. But as it would be my first contribution a might need some help to get started with it.
In reply to In my version of MS, the by cosmictrp
First, can you attach the score you are having problems with and precise steps to reproduce the problem? I just tried a quick example with 2.0.3 and it worked as expecxted - the image attached to the title frame in the score was correctly exported to all parts. This was true whether I added the image before generating the parts or after. Are you by chance using an older version? Maybe this is a bug that was already fixed. Or maybe there is something unique about your score or how you are doing things that is causing the problem.
The way parts are handled has changed somewhat from 2.0.3 to the current development code, so I suspect if there is anything that needs fixing here, it might be to be done in two different places - or it might affect one version and not the other. Anyhow, the relevant code is in Excerpt::createExcerpt() in libmscore/excerpt.cpp. I think the copying of the contents of the frames probably happens within the call to cloneStaves().
In reply to First, can you attach the by Marc Sabatella
Thank you fpr your answer.
I attached the score_template I am working on.
I tried it once more by deleting and reinserted the image and now it works as expected. A create the part and I find the image at the right postion in all parts. If I delete the parts and create them again. It also works.
BUT: If I delete the parts and close the file, it won't work when I open the file again. In that case, the image is not inhereted to the parts creating them.
taktlos_score_template.mscx
In reply to Thank you fpr your answer. I by cosmictrp
mscx files don't contain images (so take them from your local file system), you'd need to use mscz files for them to be embeded and available outside your file system and after you moved/deleted the image on/from your file system
Here it is /Users/dominik/Dropbox/taktlos/Archiv/Logo/taktlos_logo_300dpi_druck_bw.jpg
But indeed, when generating parts, it only seems to get copied accros to the 1st part, and independantly on wheter it is an mscx or mscz file, looks like a bug to me and should get reported in the issue tracker
In reply to mscx files don't contain by Jojo-Schmitz
As I mentioned, though, it works fine for me in 2.0.3 (including with the attached score, if I insert my own image by pasting it in). So in filing a bug report, be sure to post precise step by step instructions to reproduce the problem.
In reply to As I mentioned, though, it by Marc Sabatella
I could reproduce with that score and an image I placed in it.
In reply to I could reproduce with that by Jojo-Schmitz
Again, when an issue gets filed, step by step instructions will be needed. Something different about your image or how or when you added it presumably is the difference here.
In reply to Again, when an issue gets by Marc Sabatella
Right-Violine the Frame, add image, select one. Then generate parts, all new,
In reply to Right-Violine the Frame, add by Jojo-Schmitz
Hmm, still can't reproduce any sort of problem, using 2.0.3 on Windows 10. Could be specific to the image I guess although that seems unlikely.
In reply to Hmm, still can't reproduce by Marc Sabatella
Ok,
what I will do next is examine in more detail when this error occurs. I use Musescore 2.03 on MacOSX El Capitan, but I also obtain the same error in the current Musescore 3 developer version.
Do you think, that this is an issue relatively urgend? I am actually quite interested in learning more about and developing Musescore. So maybe I could try to have a look at this?!
In reply to Ok, what I will do next is by cosmictrp
Since you can reproduce the problem and I can't, sure, this would make a good candidate to try to investigate! See the "Development" link in menu at right of this page for info on getting started.
Realistically, it might turn out to be pretty complicated, or it might turn out to be very simple. Often things like this that are not reproducible for everyone turn out to be uninitialized variables or the like. But anything having to do with linked parts often involves learning a lot of relatively complicated internals just to find the place in the code where the problem occurs. Help with understanding the code and debugging is available via the IRC channel, as mentioned in the "Development" link. Good luck!
In reply to Since you can reproduce the by Marc Sabatella
I tried to examine the error more in detail. It seems that somehow Musescore looses track of copying the image element into the parts (see first attachment). But this only happens if the image is:
-inserted,
-the score closed
-reopened again and then
-the parts created.
The behaviour does not depend on the linkPath of the image. It seems to be related to the closing and reopening of the parent score.
Maybe it has something to do with this:
https://musescore.org/en/node/17250
At least I encountered some commented code where the relative-path handling was edited.
By the way: What is the purpose of the elements? They appear far more often in the original file than in the reopenend file.
In reply to I tried to examine the error by cosmictrp
It does seem you are likely on the right track.
I guess you were asking about "lid" elements (this forum strips off the XML formatting you may have tried adding, thus one can't use tag names literally with the angle brackets). That stands for "link ID" - they are used to track which element in the score corresponds to which element in the part. These aren't so useful for the score as it sits in memory since this is done more through actual links that are established when you create an linked element (ie, adding an element to a score with linked parts, or adding a new linked part). But when writing a score & part to the file, the "lid" tags are what allows MuseScore to recreate this data structure.
The fact that the issue seems connected to saving/loading the file - which I guess is why i couldn't reproduce - suggests that either we are writing the "lid" tags incorrectly, or reading them incorrectly. or, it's just an issue with how the paths are written / read, but since you say you see a different number of "lid" tags before and after, that seems like a bit of a "smoking gun" to investigate.
In reply to It does seem you are likely by Marc Sabatella
Ok, so I went a step backwards and used the basic score observing the number of "lid"s in the .mscx files.
There are no lids at the beginning. Attaching the image - still no lids.
Closing mscore and reopen - no lids.
Creating the only part - 144 lids
closing and reopening - 144 lids
deleting the part - 72lids
So I conclude that lids are created during the creation of the parts. Deleting the parts does not delete all lids - I'm not sure whether this has some influence, because the number of lids is again increased on 144 when I create the part once again and this simple example.
Up to now, I can at least say why I encountered this unexpected behaviour. My solution is to produce and save a template where all generated parts are saved together with the score. My error was to create the template, close it and then trying to create the parts only when I'm using the template for composing.
Nevertheless, this does not change anything about the strange behaviour of the lids.
In reply to Ok, so I went a step by cosmictrp
Well, it's totally normal that lids are connected to the parts - that's the whole point of them. If you have a score and a linked part, each element in the score will have a lid, and the corresponding element in the part will have the same lid. That's what links them. No parts = nothing to link = no need for lids at all, although I am not totally surprised you might still see lid tags after removing the part. But I *would* hope that adding the part back would return you to the same state you were in before.
In reply to Well, it's totally normal by Marc Sabatella
Ok, then I think I understood the lids. Yes, in this simple example it gets back from 72 to 144 when I recreate the parts.
In a more complex example, there are two lids missing when the image does not appear in the parts.