Add properties (e.g. arranger) from the score properties to the 'create new score' wizard.
This could be driven dynamically through an indicator in the score properties.
composer, copyright, creationDate, lyricist, platform and workTitle are already filled on score creation, partName on part creation, poet is, I believe, for some backward compatibulity and otherwise unused, source is used for URLs on MuseScore.com.
arranger, movementTitle, movementNumber, translator and workNumber might be asked for in the New Score Wizzard, but none of them has a counterpart in the titel frame or header/footer.
But arranger is the one that I'd need most and have to add latet on almost all of the score I transribe.
I wonder whether Subtitle should be reflected somehow in the score properties. And a 'transscriber' or 'engraver' tag might be useful too
In the current version you can add whatever you want in the properties. Any field will end up being available as meta-tag to be referenced by $:tag: in header an footer. I submitted enhancement request #163906 to be able to use this in the title textblock.
How do you envision this being a part of the wizard? If you mean you want it added to the first page, where the text that appears on the score can be entered, I would say very strongly no. The only way I can justify it is if it's hidden by default, perhaps like this:
Isaac,
could you expand why you're so strongly against just making it one table?
Putting it in a sub-table opens the discussion what should be primary and secondary.
We could also have a switch in the preferences to have them all, or as is :-)
And, I use arranger and workNumber (to display our choir's library number to each page in the header) on all sheet music. If appropriate I also use translator and source.
I'm strongly against it because the wizard is simply meant to set up the sheet music. Nothing else in the wizard affects anything that does not appear directly on the printed page, and the file's properties just don't belong here. Title, subtitle, composer, lyricist, and copyright go right there in the score, so its appropriate they can be preset in the wizard; things like "platform" are just metadata. Keeping the wizard simple is particularly important for people who are not yet power users, and who would unquestionably be overwhelmed by the whole "Score Properties" dialog in their faces the first time they try to set up a score.
The "source" field is not read-only because occasionally an uploading error will mess up the link, or the user may simply fail to save the file locally again after saving it online. In either case, it's simple to manually re-link it.
@Isaac: i see that you feel strongly about the setup here.
As for your statement 'Nothing else in the wizard affects anything that does not appear directly on the printed page' I strongly disagree. I for instance have a number of fields I use in headers and footers through my standard template which I only can enter by editing the properties (e.g. workNumber). Also, in connection to feature request #163906 the number of properties grows (e.g. arranger).
To try to move this forward the following coukd be considered:
I can see that ther are basically to type of properties:
1- File/system based (Platform, source, etc.)
2- User data (title, workNumber and all user defined properties
To accomodate different users we could think along the next lines:
- Show the file/system based (auto filled) fields in 'Show more fields' as in your reply #4
- for each 'user data property' allow the user to define the property as primary (directly visible in the wizard) or secondary (in the extended view (your show more fields' section)).
This allows a default as it is now, and the flexibility to accomodate other user's wishes.
Please consider that different users already stated that they manually put in other data like Arranger, workNumber, origin, and probaby more.
In connection with feature request #163906: it provides for people to make their own 'additions' to what is provided and use that in the title textblock and/or headers/footers.
I have no clue on how feasible this all is.
I was basically thinking about that for each new piece I go through the wizard and then open the properties to enter the rest of the needed data. That doesn't sound as the ideal situation, does it?
I don't understand what you are disagreeing with. It is a simple fact that the wizard only allows entry of things that appear on the score. You might like to display other information, but you can't possibly be doing that via the wizard, because the wizard only supports the handful of standard fields that almost all as scores display. You might *want* it to display more, but the statement you are trying to agree with was a statement about what *is*, and as such is totally true.
Yes, I agree that 'source' should be read-only (create date probably too?). But this should be dealt with in another issue, not this one here
Arranger and translator for example should show up in the title trame too, at least optionally. I thinkg Translator belongs below Lyricst, Arranger below Composer.
Work number, movement title and movement number may be needed there too (again optionally), just not sure where exactly though.
@Jojo: I've had times when I've been grateful I could fill in the source myself.
I actually agree about Arranger and Translator, though I'd suggest instead of positioning them below Lyricist and Composer, simply add them after a line break in the same text element.
Für Translator/ Arranger this is what I do currently and after score creation, but only because the Wizzard is lacking them and not easily allowing multiline Input (same issue for Copyright).
And there's actually even a text style for translator, bottom aligned and centered.
source should still be read only, if it is screwed up for some reason there are other thing to worry about
Comments
composer, copyright, creationDate, lyricist, platform and workTitle are already filled on score creation, partName on part creation, poet is, I believe, for some backward compatibulity and otherwise unused, source is used for URLs on MuseScore.com.
arranger, movementTitle, movementNumber, translator and workNumber might be asked for in the New Score Wizzard, but none of them has a counterpart in the titel frame or header/footer.
But arranger is the one that I'd need most and have to add latet on almost all of the score I transribe.
I wonder whether Subtitle should be reflected somehow in the score properties. And a 'transscriber' or 'engraver' tag might be useful too
In the current version you can add whatever you want in the properties. Any field will end up being available as meta-tag to be referenced by $:tag: in header an footer. I submitted enhancement request #163906 to be able to use this in the title textblock.
I know. Still there are some yet unused tags in every score by default.
And yes, #163906: Allow use of macros in text block would be quite useful.
How do you envision this being a part of the wizard? If you mean you want it added to the first page, where the text that appears on the score can be entered, I would say very strongly no. The only way I can justify it is if it's hidden by default, perhaps like this:
Many of those fields are already filled/connected. But adding Arranger for example and maybe Movement and Translator might do?
Isaac,
could you expand why you're so strongly against just making it one table?
Putting it in a sub-table opens the discussion what should be primary and secondary.
We could also have a switch in the preferences to have them all, or as is :-)
And, I use arranger and workNumber (to display our choir's library number to each page in the header) on all sheet music. If appropriate I also use translator and source.
Better don't use 'source', it is for recording the URL on MuseScore.com, so gets overwritten if and when you upload it there via "Save online"
Thanks for the advice, I'll create some other tag like "original-from" or whatever.
If this has a fixed (automtic) usage, why isn't this read-only (in other words, why can I edit it)?
Thanks for the advice, I'll create some other tag like "original-from" or whatever.
If this has a fixed (automatic) usage, why isn't this read-only (in other words, why can I edit it)?
I'm strongly against it because the wizard is simply meant to set up the sheet music. Nothing else in the wizard affects anything that does not appear directly on the printed page, and the file's properties just don't belong here. Title, subtitle, composer, lyricist, and copyright go right there in the score, so its appropriate they can be preset in the wizard; things like "platform" are just metadata. Keeping the wizard simple is particularly important for people who are not yet power users, and who would unquestionably be overwhelmed by the whole "Score Properties" dialog in their faces the first time they try to set up a score.
The "source" field is not read-only because occasionally an uploading error will mess up the link, or the user may simply fail to save the file locally again after saving it online. In either case, it's simple to manually re-link it.
@Isaac: i see that you feel strongly about the setup here.
As for your statement 'Nothing else in the wizard affects anything that does not appear directly on the printed page' I strongly disagree. I for instance have a number of fields I use in headers and footers through my standard template which I only can enter by editing the properties (e.g. workNumber). Also, in connection to feature request #163906 the number of properties grows (e.g. arranger).
To try to move this forward the following coukd be considered:
I can see that ther are basically to type of properties:
1- File/system based (Platform, source, etc.)
2- User data (title, workNumber and all user defined properties
To accomodate different users we could think along the next lines:
- Show the file/system based (auto filled) fields in 'Show more fields' as in your reply #4
- for each 'user data property' allow the user to define the property as primary (directly visible in the wizard) or secondary (in the extended view (your show more fields' section)).
This allows a default as it is now, and the flexibility to accomodate other user's wishes.
Please consider that different users already stated that they manually put in other data like Arranger, workNumber, origin, and probaby more.
In connection with feature request #163906: it provides for people to make their own 'additions' to what is provided and use that in the title textblock and/or headers/footers.
I have no clue on how feasible this all is.
I was basically thinking about that for each new piece I go through the wizard and then open the properties to enter the rest of the needed data. That doesn't sound as the ideal situation, does it?
I don't understand what you are disagreeing with. It is a simple fact that the wizard only allows entry of things that appear on the score. You might like to display other information, but you can't possibly be doing that via the wizard, because the wizard only supports the handful of standard fields that almost all as scores display. You might *want* it to display more, but the statement you are trying to agree with was a statement about what *is*, and as such is totally true.
Duplicate deleted.
Yes, I agree that 'source' should be read-only (create date probably too?). But this should be dealt with in another issue, not this one here
Arranger and translator for example should show up in the title trame too, at least optionally. I thinkg Translator belongs below Lyricst, Arranger below Composer.
Work number, movement title and movement number may be needed there too (again optionally), just not sure where exactly though.
@Jojo: I've had times when I've been grateful I could fill in the source myself.
I actually agree about Arranger and Translator, though I'd suggest instead of positioning them below Lyricist and Composer, simply add them after a line break in the same text element.
Für Translator/ Arranger this is what I do currently and after score creation, but only because the Wizzard is lacking them and not easily allowing multiline Input (same issue for Copyright).
And there's actually even a text style for translator, bottom aligned and centered.
source should still be read only, if it is screwed up for some reason there are other thing to worry about