MuseScore 4 Missing Text Line Properties
I use MuseScore 3 for creating Anglo concertina tablature, such as this: https://drive.google.com/file/d/1TuBYZeASlcYsSGQEOuuXy7rMfO2smmej/view
A brief explanation of this tablature can be found at https://rollstonpress.com/ (search the page for "Easy Anglo Concertina Tablature").
You can see how I initially implemented this in MS3 here: https://youtu.be/8altdrmNJeI
I'm excited about MuseScore 4, but it's currently missing some features that I rely on for this notation. In particular, there is no way to toggle "line visible" for text lines. MS4 does respect this property when loading a score created in MS3, but I can't find any way to change it, regardless of its state. I might be able to use staff text for tabs that don't need the line, but the UI is completely different for editing staff text and text lines, and the positioning works a bit differently as well, so I'm concerned about how much effort will be required to get good results when mixing text lines with staff text.
There's also no longer a dedicated UI for choosing whether text lines appear above or below the staff. I'm aware that I can adjust the vertical offset until the text line snaps to the other side of the staff, but that makes an already tedious job even slower. This could be mitigated with a custom palette, but in MS4 I can't seem to drag elements from the score to the palette in order to store them with pre-set properties.
As an aside, I'm hoping we eventually get access to text lines in the plugin API in MS4 - being able to write a custom plugin would make entering concertina tab in MS much, much, faster.
Comments
Agreed, facing similar issue.
Also, changing the font in ''Styles>Text styles>Text line'' seems to have no effect on the ''System text line'' palette element, only on ''Staff text line'' element
4.1 has added back most of the missing settings.
Also, the way to flip a line or pretty much any element from above to below the staff is to press "X" or use the flip direction button on the main toolbar.
The way to add custom elements to a palette is Ctrl+Shift+drag, same as always.
In reply to 4.1 has added back most of… by Marc Sabatella
Thanks so much for the help! I swear I tried Cmd+Shift+drag before without success, but it works now, so I guess that's a win.
I'm still not seeing the option to hide the line but keep its text. Am I just missing it? Thanks again.
In reply to Thanks so much for the help!… by schult@gmail.com
The line visibility setting is present for the lines where it's relevant - things where the line itself has playback properties like crescendo or ritardando lines, it pedal lines with the old style rosette. For ordinary text lines there would be no point in adding a line then hiding it - it would be the same as just adding the text.
And I totally believe you about the palette customization sometimes just not cooperating - it's always been finicky and sometimes just doesn't seem to allow the drop. But patience normally pays off.
In reply to It's present for the lines… by Marc Sabatella
From a formatting perspective, I haven't found text elements to be equivalent. Setting the same offsets for system or staff text does not result in the same vertical position as the line text. I need text both with and without lines on the same notes, with matching style and positioning. And, afaik, there's no way to convert seamlessly between lines and plain text when changing whether a note is held or not in this tablature.
In reply to From a formatting… by schult@gmail.com
I think you are seeing a difference only because the alignment properties have different defaults. Just set your staff text to center alignment like the lines are, or change the "Text line" text style to baseline to match staff text.
If you continue to have problems, please attach your score and describe the issue in more detail.
In reply to I think you are seeing a… by Marc Sabatella
Aha, that does make the positions match. It's not the answer I was hoping for, since it does leave some extra effort to change between the two elements, but it's enough to let me move forward with MuseScore 4. Thank you!
I still hope we'll see better support for the plugin API in the future. I've already got a good start on a plugin to greatly simplify entering this tablature in MuseScore 3, and the only thing holding it back is the lack of access to line elements.
Cheers!
In reply to Aha, that does make the… by schult@gmail.com
Can yu explain more what you mean about "change between the two elements"? Do you mean you have text you entered one way then change you mind and wish to enter the other way? Feel free to open an issue on GitHub explain your use case and perhaps this property can be added back. In general, any property with a real use case is intended to be preserved; only those for which there were no known real world use cases are not supported by design, to keep the Properties panel from becoming as cluttered and complex as in MU3.
Improvement to the plugin API are definitely planned, but have always tended to be fairly low priority and hopefully some community members interested in writing more sophisticated plugins can step up to help. but first there does need to be some design work on how it will all look going forward.
In reply to Can yu explain more what you… by Marc Sabatella
That's pretty much it. Lines are typically shown when a harmony note is held across multiple melody notes. Sometimes that duration changes that while working out/adjusting an arrangement and a line comes or goes. That was pretty easy in 3, since it was just a checkbox. I'll try it as-is for a while and see how much of a hassle it actually is. Like I said, my long-term hope is to write a plugin. That would render this issue irrelevant.
I definitely appreciate the effort to keep the Properties panel under control. It's much nicer in 4.
I had looked into helping with the plugin API at one point, but I've just got too many other things going on. Maybe someday...
In reply to Can yu explain more what you… by Marc Sabatella
As I'm experimenting again, I'm finding that palettes no longer store offsets for Text Lines, but they do for Staff Text. Is this intended behavior or a bug?
I'm also finding some tricky interactions between Staff Text and Text Lines when positioning them together on the same side of the staff. I can get around it by turning off auto-place for the Staff Text, although I'm wondering if that will cause me more heartache down the road.
In reply to As I'm experimenting again,… by schult@gmail.com
It's a very long-standaing bug that the palette itself will display an item with offset applied, but when you actually go to add the element to your score, the offset is removed. It should probably be the other way around.
As for other interactions, if you post your score and explain the issue in more detail, we can advise better.
In reply to It's a very long-standaing… by Marc Sabatella
How long-standing are we talking? It seems like it's working as I expect in 3.6.2.
I'm not sure if a score would be helpful, since it's more of a process interaction. I uploaded a video demonstrating what I'm talking about (link below). I'm relatively certain this behavior is intended and makes a lot of sense for other types of notation. It's just inconvenient for me, assuming I have to represent concertina tab using a mix of Staff Text and Text Lines.
https://youtu.be/lR0oeIAN31U
In reply to How long-standing are we… by schult@gmail.com
The behavior I’m talking about where the offset applied to a score element that is added to the palette is then ignored when adding the score is present in 3.6.2 and going back before that too.
In reply to The behavior I’m talking… by Marc Sabatella
That is what I thought you were talking about. I'll have to go back and check the behavior more carefully. I'm pretty sure I at least have horizontal offsets that take effect when inserting elements from a palette in 3.6.2.
In reply to That is what I thought you… by schult@gmail.com
Not for me; both vertical and horizontal offsets are reset upon adding the score in 3.6.2 (and others). Just tested again, same result.
In reply to Not for me; both vertical… by Marc Sabatella
Aha, you're right - I had set an offset on the text, rather than the whole element. That still works. Thanks for following up on that.
In reply to The behavior I’m talking… by Marc Sabatella
Just in case I was unclear, I'm talking about a couple of different things. The video is about an unrelated issue. Like I said, probably intended behavior, but I figure it's worth asking.