External resources (like images): embedding vs. linking

• Jul 7, 2012 - 22:32

It seems to me the trend of recent changes is toward dropping support for external resource linking (only external file name kept in the score) and only allowing resource embedding (resource file included in the score itself). So far this mostly refer to images.

We already had this discussion and I remember well Werner's point on that: images (or other resources) directly embedded into the score file make the score self-contained and carrying all its resources with itself, simplyfing distribution and sharing. This is a strong point, of course, and embedding could probably be the default.

However, I believe there are arguments for linking too: basically, any change to the resource (normally made outside MuseScore) requires deleting from the score the old version, re-embedding, re-positioning, re-scalign and possibly re-layerying (Z-order) the new version.

There are scenarios in which this seems a lot of (useless?) work:

*) resources made for a specific score: if you do not get it right the first time or for any reason you need to change the resource, you have to redo the embedding process, repeating until acceptable.

*) resources shared by several scores (logos, common symbols, etc.): if the resource is updated, the new version is immediately available to all scores if linked, but requires re-processing in each score if embedded.

Both are work in progress scenarios: once the score is 'finished' (or distributed in some way), a self-contained file is definitely the right thing.

This distinction is present in many programs which allow for embbedding of externaly-made resource, for instance LibreOffice.

*) The 'old' solution -- mscx using linking and mscz using embedding -- seemed to me a reasonable compromise; if the distinction was unclear for the final users, possibly changing the file type description in the "Save / Save as" dlg boxes could help: "Complete score (*.mscz)" vs. "Music only (*.mscx)" should be familiar to anybody having saved an HTML page from a web browser.

*) And/or an explicit "Link" check box could be added to the resource properties or to the resource "Open" dlg box (this is the solution used in {Open|Libre}Office).

*) And/or a score-wide command to "Embed / un-embed" (depending on which is the default).

Anybody else feeling this need?

Thanks,

M.

Comments

• Jul 7, 2012 - 22:51

Using lots of graphics in my scores, I think choosing between "embedded" and "linked" would be a good thing and effectively simplify changes or corrections.

Reply

• Jul 8, 2012 - 00:25

It would help me with my Organ Library Project, particularly if we will be able to drag and drop SVG files onto MuseScore.

This would save a lot of faffing around with title pages etc.

The graphics could be linked during development and embedded for final production.

Reply

• Jul 8, 2012 - 18:21

Thanks for the replies.

So, there seems to be some room for this feature.

How do you see it working from the user perspective? Some options (not necessarily mutually exclusive) are outlined in the first post; I'll try to summarize:

1) A dlg box is shown each time a resource is attached to the score (open from a dlg box or drag-and-dropped), asking for link vs embed selection (embed could be the choice selected by default); this is how LibreOffice works.

2) A score setting (in "Style" | General ?) to select a default behaviour score-wide; no question asked for each resource addition, but:

3) Two score-wide commands (in "Files"?) to embed all linked resource and viceversa.

4) An inspector parameter to change the embed/link status of a resource individually.

5) An option while saving the score: "complete" vs "music only" (or similar wording). This may create problems when a complete score is moved or shared, as linked resources are no longer there and cannot be embedded; also un-embedding embedded resources may or may not make sense, depending of folder structure. As this condition is hard to detect, it might be difficult to present meaningful choices to the user.

6) Other possibilities?

M.

Reply

• Jul 16, 2012 - 11:19

Hi,

After some false starts, I'm working on a rather minimal implementation which should achieve the intended result. It is rather different from the lines described above and introduces 2 changes to the current code:

1) The external resource file path is stored in the Image object and is saved in the score data file, alongside with the store hash. The ImageStore will still contain the 'embedded' resource.

In addition, an attempt is made to make the external file path (written in the score data file) relative to the score path: this should allow to move the score elsewhere as long as the images are moved too. The code currently checks if the image is in (or below) the score folder or in (or below) the folder above the score folder; perhaps some examples are useful (examples are Windows-like, but the same applies to Unix too):

score path: Z:/Music/Scores/Quartets/MyQuartet.mscz
img path: Z:/Music/Scores/Quartets/img/MyImage.png
img path written as: img/MyImage.png (image is in or below the score folder)

score path: Z:/Music/Scores/Quartets/MyQuartet.mscz
img path: Z:/Music/Scores/img/MyImage.png
img path written as: ../img/MyImage.png (image is in or below the folder above the score folder)

If the image is further removed from the score folder, the absolute path is written (and the image may become unavailable, if the score is moved elsewhere).

2) Upon loading the score, the external resource path is checked before the ImageStore: if the file is found, the resource is loaded from disk and the ImageStore updated if necessary. If there is no external path (older file format) or the external file is no longer there, the resource as stored in the ImageStore is used.

In this way, any update to the external image will show up in the score, upon score re-loading. The downside is that score loading is somewhat slower (more disk accesses).

Notes:
1) There is no link vs enbed implementation or user interface as such: simply if the link exists and is valid is always used; if not, the embedded version is used.
2) This should work transparently both for .mscx and for mscz files: for .mscx, as there is no ImageStore, the external link will always used; for .mscz the external link will be used to update the internal resource, if present and different.

The code is mostly written, but there are still several things to test and debug. So, if anyone has anything against such a solution or sees any problem, there is still time to discuss before committing.

Thanks,

M.

Reply

• Jul 16, 2012 - 16:44

@lasconic: the short answer is yes. A longer answer:

Every time the score is loaded, the current version of the external resource is read from disk and the score internal ImageStore is updated (if the external resource has been updated since the previous score loading). As a consequence, when the score is saved again, the updated resource is saved with the score.

Note: In the code I'm working on, this happens when the score is read, not when it is saved. So, a process like:
* open the score (the image is loaded and, in case, the internal store updated)
* while the score is open, modify the image (with an external editor)
* save the score (without re-loading or re-opening it)
would not update the image in the score store, as the score does not notice the image has changed until it is (re-)loaded.

The current situation is however even worse, as the score never notices a change in the external resources, once embedded.

If this is a requirement, it can be implemented, I think, but at the cost of more disk accesses while saving. Also, once an external resource is modified, it would probably make little sense to save the score without checking the result of the resource modification i.e. without reloading the score).

@Marc: simply replacing the file in the ZIP would not work; images are internally referenced through a hash code computed on the resource contents; if the contents changes, the hash code changes and the modified image would be no longer found.

M.

Reply

• Jul 19, 2012 - 12:27

Ok. it looks good enough for MuseScore.com purpose. As you explained, it makes no sense to embed a file if you didn't check how it works in MuseScore.

I see a little drawback though. If you change a file without moving it and you don't want MuseScore to update it, you can't.
It may be a unexpected behavior for some users.

-> Create a score, embed some file
-> Save, happy job is done

-> Later you need the image to illustrate something else, edit it, change it.

-> Later again, reopen your score, it's destroyed :(

Reply

• Jul 19, 2012 - 19:06

I grew the idea that per-image management of link/embed status was after all not needed. Your point may show otherwise.

A) There may be cases when the program is expected to update in the score an image updated outside (your musescore.com requirement, if I am not mistaken).

B) And there may be cases when the program is expected to store an image in the score and never touch at it (your example of a double-duty image been modified).

However, the program has to choose one of the two behaviours as default and leave the other to user's manual intervention (once the proper user interface for this manual intervention will be added).

Which one to choose? In both cases we are dealing with user expectations (either expressed or inplied) and/or with making one process more straightforward (and foolproof!) than the other.

I personally tend to rate A) higher than B), but I am aware this is a personal point of view.

M.

Reply

• Jul 19, 2012 - 22:27

I personally think that the choice: linked / embedded needs to be done, not at the time of the inclusion of an image but when the backup.

Linked is interesting when multiple occurrences of an image appear in the score. I know it is not very common but for now a change of the image requires modifying each individually occurrences.

Another view: during the development of the layout may need to change the framing of the image content. Having to reload the new image and resize and reframe is irrelevant to a proper focus.

It seems therefore useful to link an image during development of the score, with all the facilities it provides in terms of possible changes. Being finalized by embedding the image, when saving final, admitting that from that time changes can no longer be automatically make.

That said, I am open to all views and ideas that enhances the use of MuseScore.

Reply

• Jul 20, 2012 - 00:52

@ Jall2: This was my view when I initially started thinking about it (as it is a known paradigm). Then, I begun to think that, in this particular case, adding more commands, selections, ..., was more a burden on the user (more steps one could forget, more things which could go wrong) than a real enhancement.

So, I am implementing a way to always keep the images in the score up-to-date, while keeping them embedded. As it works now, only score reloading (without any specific step or user command) is necessary to update the embedded images. It should be available in the next nightly (I just discovered a small bug and posted a fix to the central repo).

However, last lasconic comment raised an interesting point; so, the story will not end here. Also, Werner has ideas about an external resources manager which may solve most of these points. It is not for tomorrow, though; so there will be many occasions to test if my small change is a step in the right direction or should be thrown away.

Thanks,

M.

Reply

• Jul 20, 2012 - 09:05

I am certainly one of MuseScoristes which uses most frequently embedded images. I therefore support any initiative that makes this easier. It is very interesting to interact with the image without having to rebuild everything every possible change. Currently it is a little failure to MuseScore. An external resource manager would actually be a good solution, after all MuseScore is a partition editor, not a graphics program.

Reply

• Jul 20, 2012 - 18:34

I'm afraid my English is too primitive to understand this nuance.

The problem is that :
a) "un gestionnaire de ressources externe"
and
b) "un gestionnaire de ressources externes"

translate into English the same phrase: "an external resource manager. The difference in French? The presence or absence of "s" of "externe".
in a) is the manager that is external, as resources are either external or internal
and b) are only resources.
My thought was for the a option.

I know French grammar is one of the most formidable which are ; )

Reply

• Jul 20, 2012 - 23:07

Italian scores some points too:

a) "un gestore esterno di risorse"
b) "un gestore di risorse esterne"

(with a few possible variations in the word order). Anyway, I noticed you intended a), but I think the core developers are thinking about b).

Cheers,

M.

Reply

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