Bracket color?
-- Using MuseScore 3 on Windows 10 (nightly 70b00e6) --
I've successfully applied a custom color to all the elements in a score--except the brackets! Clicking a bracket selects it but the Inspector is blank/empty. My brackets are sticking out like sore thumbs on every system.
I've searched through the usual resources and learned that brackets could previously be recolored via the Inspector, but that the feature was turned off some time ago.
So does MuseScore now provide any way to change the color of brackets? If so, please let me know what that is. Apologies if I missed the solution on the forums.
If not, my project is doomed, so I must beg that the Inspector be turned back on for brackets, or that some other path to coloring them be provided. If other edits to brackets caused problems, please just turn on a "Set color" option. Please?
Thank you.
---------
PS: It would sure be great if MuseScore permitted a per-score default color for all elements, and/or had a true "Select All" command with the ability to change color for everything so selected. Not only notes and rests and articulations, but clefs, staff lines, barlines, etc. etc. "Select all text" would also be nice.
Comments
See #104671: Brackets are no more selected in the Inspector and #33541: some elements can get marked invisible, but this doesn't get saved, so is lost on reload and many more. It was never really possible to color them, at least it never survived a save/close/open i.e. the changed color never got stored in the score, hence the ability to change color, offset or visibility had been removed.
Why is it viatal to your prohejct to be able to color them?
In reply to See #104671: Brackets are no by Jojo-Schmitz
My project requires printing a number of properly formatted scores, each completely in a color other than black. Exporting the whole thing to maybe 500 bitmap pages, recoloring them as such, and then assembling those pages into a (very large) PDF--well, that's more time and trouble than I'm able to give it.
I settled on MuseScore for this project only after confirming that the ledger line color bug had been fixed. I should think that if MuseScore supports color changes for all the other elements, it shouldn't oughta leave the brackets behind, seems kind of unfair to them.
One thought for an interim workaround would be to turn back on the ability to recolor brackets as long as they can be printed in that color. I could live with having to recolor only the brackets every time I go to print. People could be warned that the bracket color feature had that limitation.
By the way, Finale and Sibelius permit only very rudimentary sorts of color changes, so I appreciate the effort.
In reply to My project requires printing by Stephen Cummings
brackets are system created, so coloring them individually won't work
But you could try whether it works for you in MuseScore 2.0.2, before this got disable, check https://musescore.org/en/download#Older-versions
In reply to brackets are system created, by Jojo-Schmitz
I'm able to print brackets and braces in the chosen color(s) from 2.0.2 (see below). If you can turn back on the color option for brackets in the current version my immediate need will be met, even if the color doesn't stick on file set. I can't use 2.0.2 because it doesn't change ledger line color.
I may not understand your note that "coloring [brackets] individually won't work," in the sense that you meant it. In 2.0.2 I'm able to choose a unique color for each element, so I should think these color attributes are somewhere in memory and could be stored in the file. Here's an example:
![Multi-colored brackets and braces.jpg]( "Multi-colored brackets and braces.jpg")
Here's the PDF example:
In reply to I'm able to print brackets by Stephen Cummings
In the score file that is no bracket element stored for every start of a system, so no place to store the color of it. There's only a definition what bracket should span which staves, if any, and then only on layout it gets decided where exactly they go.
So if we'd implement a bracket color, it would be globally for the entire score.
Nobody is going to bring back that broken 'feature' from 2.0.2, where it pretends to be able to change color, but doesn't save.
In reply to In the score file that is no by Jojo-Schmitz
Hunh, I wonder how color is preserved during an editing session then, even after resize operations:
![Braces resized after recoloring.jpg]( "Braces resized after recoloring.jpg")
I will repeat/restate my observation that providing comprehensive color options but omitting a single element type doesn't make sense--if you'll forgive a gentle back-at-you, "Nobody" would design a product like that. With respect for the amount of work it may entail, somewhere down the line a redesign of the way brackets work is in order, perhaps as part of a broader overhaul of color-related features (see PS in my initial post).
NB: Windows-based GUI programs that appear to support color include Harmony Assistant (weird, awfully clunky UI but pretty sophisticated in terms of notation options/quality, and inexpensive relative to other higher-end notation software); and, I think, capella.
In reply to Hunh, I wonder how color is by Stephen Cummings
it is not a single element type, it is (at least) 2, brackets and instrument names. Also Initial barlines
But yes, this should get fixed eventually, just not by reverting back to the old bug of showing it in the session but not stroring it in the score itself
In reply to it is not a single element by Jojo-Schmitz
In case this horse isn't dead yet, here's one more beating:
I just remembered that MuseScore writes/exports faithful SVG files*. So if the spurious clefs and key signatures get fixed, I could color all the other elements the way I want them, write to SVG, and then use a little script to search-and-replace the fill color on the black brackets. In this example, I've hand-edited the color to be blue:
![Colored brace, SVG file.jpg]( "Colored brace, SVG file.jpg")
*What do you know, bracket color is properly saved in SVG files written by 2.0.2, even when the brackets are each given a different color.
In reply to In case this horse isn't dead by Stephen Cummings
I guess it is about time to file a feture request (or even a bug report) in the issue tracker , for allowing colored brackets. As it would most probably requite a score file format change, I don't think it would make it into 2.0.4 though.
In reply to Hunh, I wonder how color is by Stephen Cummings
Color and other options are provided for "first class" objects (not an official term, but it will do for now). That is, objects that you create with a fixed position etc. Things like clefs, brackets, and key signatures are typically not created by the user at all (except for clef or key *changes*, not the ones at the beginning of every system) and thus have fewer options, because they are generated on the fly. You might change the propertiers of a bracket at the beginning of measure 5 starting the second system, then add some more notes to measure 4 at the end of the first system, making it no longer fit, and suddenly your second system starts with measure 4 instead of measure 5 and it's no longer appropriate to use the properties you had originally told MuseScore to use for the bracket on measure 5. And so on. That bracket is not "real" in the sense a note is - you didn't place it directly there on measure 5, and it won't stick around as things change. A new bracket will be generated each time the layout changes or the score is read from the file - the old one simply does not exist any more. Easch time the layout changes, there may be different brackets. And not just which emasures they are attached to - there might be more or fewer brackets than there were when you tried setting their properties as well.
Because certain types of operations like this are especially common, we fudge things internally to make setting certain properties on certain objects possible, but it's inherently problematic for the reasons I stated. Sure, this one could be added if there is sufficent demand, but I thought I'd address the "why" of it a little.
In reply to Color and other options are by Marc Sabatella
Marc, your explanation makes sense and I appreciate the trouble you took to give it. I don't exactly get how "unreal" brackets (that can't be colored properly) are different from equally "unreal" clefs and key signatures (MuseScore lets me change the color of any arbitrary clef or signature object, and those changes are preserved when the score is saved, closed, and reopened). But I get it that with the current program design and/or file format, somehow the particular way that brackets are handled makes adjusting them individually a challenge, behind the scenes (per a previous reply, I guess that applies to a couple of other types of objects, too).
But in that case, a score-wide default color, preserving the ability that we now have to change colors of individual items, including clefs and signatures, would certainly be a great help.
As long as I've gotten this far in: It's easy to imagine, though, how the user/composer/engraver could be given more freedom to make formatting choices for those objects that are automatically generated, and that are automatically moved/created/destroyed as notes, rests, and what not get changed.
Building on the score-wide default color I imagine, the simplest level of control would allow the user to specify a color (and in theory, size, shape, slant, whatever) of each individual type of object, or at least of the brackets and other things that can't be colored individually.
But in concept, you could certainly go farther and also allow the user to make such changes on individual system-generated objects. In that case you could either (a) have the system convert these objects into "real" ones (that the user has to decide how to manage, since they would have to float around either in a fixed position or flowing with the edits); or (b) throw a message up when an edit to "real" objects is about to cause one of these altered "unreal" ones to move or disappear.
And in any case, since MS can print and export individually-colored brackets while the colors are showing on the screen, why not turn that feature back on and give users the choice? There's nothing wrong with a feature that only works when you print a file--lots of programs have print-time options that aren't saved with the document--as long as people know what to expect. If you're worried they won't read thee manual, add a little box that pops up saying, "You can't save the color, but you can print it--do you want to proceed?"
Anyway, the power of color as an information tool, and to create and direct interest, is obvious. In other media B&W lost out a long time ago, and unless we burn ourselves up, colorful musical notation will become commonplace. Seeing comprehensive color control as a core feature seems to me wise, longer term.
In reply to Marc, your explanation makes by Stephen Cummings
The difference is that key and time signatures are already things that are written to the file, since they can be injected directly into specific measures by the user and need to start right there until the user deletes them. So we can piggyback on this mechanism to allow even generated elements to be written if they havebeen customized . Brackets are not normally written to the file because there is no need to currently. So there is nothing to piggyback on. But of course in theory we could do so in the future if there is sufficient demand for it.
I think most people would find it unacceptable to have a feature that doesn't survive saving and loading a file. In fact that is one of criteria we have to consider an issue "critical" - it constitutes loss of information.
In reply to The difference is that key by Marc Sabatella
I would also appreciate it if brackets were saved, and the Inspector for them could be re-enabled.