Metadata (tags) in frames

• Nov 29, 2017 - 16:48
Reported version
3.0
Type
Graphical (UI)
Frequency
Many
Severity
S5 - Suggestion
Reproducibility
Always
Status
GitHub issue
Regression
No
Workaround
No
Project

I'd find it very useful if I could use metadata in frames like it's already possible to do in headers / footers.
That would enhance coherence between metadata and what is actually printed.

Currently, the contents of tags filled during score creation are duplicated in the top first frame, but the link with the tag name is lost.

In headers/footers, it's possible to enter $:variables: to be replaced by actual contents.

An option could be to create an edit dialog for frames in which one could enter $:variables: as for headers/footers. Whenever one validate this dialog, the values are parsed and the content actually displayed in the frame reflect the values of the variables.
Furthermore, user-defined tags could be honored as well.

Warning: in this dialog, it's important to still be able to affect a text style for a paragraph (Title, Author, etc.)

pros: The proposition is efficient, simple and consistent with other portions of code
cons: It'll no more be possible to directly edit the content of the frames


Comments

I'd like to add my name to the list of people requesting this feature. Being able to type $:[metadata]: directly into a frame would be helpful so that my headers, footers, and subtitle, for example, can all be changed by a change to the score properties.

Reported version 3.0 4.0
Reproducibility Always

+1 - from the info here and links, in order to update info on the visible score (apart from header and footer), one must simply update it manually. Honestly, it's kind of a hassle, but not that big of a deal. The main issue? It's counterintuitive! I'm prompted to enter info into a form, and the implication is that those values are updatable and will be used in the visible score. It's confusing when an update is made to those values and nothing else is updated.

What is the point of score properties if they're just hidden away in file metadata? Copyright and such on the footer is definitely convenient, but apart from that, why bother?

I could very well be missing something, so if there are other reasons to use score properties, I'd be interested. But for now, I'll probably just skip it and type it all.

MuseScore is great! Thanks for all you do!

In reply to by tyezdro

> I could very well be missing something, so if there are other reasons to use score properties,
> I'd be interested. But for now, I'll probably just skip it and type it all.
One example. Today, those properties can be retrieved by plugin that can use them for any purpose (to the contrary the plugin cannot access the text frames). So using those properties remains useful if you are using one of these plugin. But indeed at risk of desynchronisation between the meta-data and what is printed on the score. Example of such plugin Batch Convert.

I would be very interested. In fact, it makes so much sense to be able to retrieve this existing data and use it anywhere in a score, that I wonder why it hasn't been implemented already!
An example of use: the 'score duration' plugin places a meta tag in the score properties; it would be useful to retrieve this value to place it in the score header frame by $:scoreDuration:

+1 from July 2024.
This is one of the useful features of e.g. Sibelius that's missing in MuseScore.
Now it's a bit annoying that you have to manually keep Project Properties (what's used in e.g. PDF export) and the text on your score in sync. (As a result, PDFs often have wrong metadata / titles when opened in the browswer).

Simple replacements like $:composer: in the text frame at the top of score (as is already possible in Header and Footer) would solve this.

I'm not familiar with the MuseScore codebase, but if anyone would give a pointer or two on how/where to start implementing this, I might give it a try.