Visibility changes the layout of score
When changing the visibility of elements, Musescore changes the layout of the score: specifically noticed is beam directions. This screws up the intended view for the user in certain scenarios, and it gets worse if used with multiple-measure selection, and seems to be more prominent when utilizing multiple voices.
Expected behavior: User-defined spacing of measures, beam directions, etc. should remain unchanged, that is, they should be independent of visibility. This is especially important if the user wants to have only a certain type of elements showing for screen shot purposes for further use, only to find that they are no longer in their desired positions.
Observation: This probably would be an easy code fix: layout code is probably not being executed by checking for visibility before layout feature implementations (maybe to save processing time?) But this shouldn't be much processing time to perform, and it would be better to have visibility have no effect on the layout at all, so far as understood.
To give an example, an attached gif is provided with a few pressings of the 'v' visibility upon a measure. The beam of the second voice in this specific example alternates upon visibility shifting. Notice also that the measure size changes, which adds up in bulk. This was also the way it was in version 2, but this is with the most recent version:
Comments
Well, it's to be expected that making something invisible means it no longer affects the layout in the same way. This is an important feature for most users. For instance, your voice one beam in the above would normally default to down It's only up because there are notes in voice 2. If there are no notes in voice 2, there is no reason for the beam to be up, so it flips back down when those notes are not present. This is normal correct, and desirable behavior in most cases.
If you have some special reason to lock the position of some element even when it no longer makes sense (eg, wanting voice 1 to stay forced up even when there is nothing present in voice 2), just do so manually.
In reply to Well, it's to be expected… by Marc Sabatella
Thanks for responding Marc. I suppose it depends on your philosophy here, because in my view the visibility shouldn't affect the layout, and so your phrase "if there are no notes in voice 2" is correct only when there exists no voice-two, yet there are notes in voice two with the example, they're merely unseen. Like, if one makes frames invisible (View->Show Frames) , one wouldn't expect the space required for the frame to disappear and alter the page, but that's not a fair observation because those are non-musical elements.
The main reason in desiring a maintenance of layout is one of, it will be admitted, non-normal operation: If i want only all of the beams to be visible so that I can do something to them visually in another program, I'd like to be able to make everything invisible except for the beams and then export this. Vice versa, I'd like also to have all elements visible except the beams in contrast to this, offering ease of separation between the elements. The measure size shifting and beam shifts make this extremely difficult to achieve as MS currently operates.
One can export to SVG, but the object types don't seem to appropriately export for use. For instance, in Inkscape, if I import an SVG from Musescore, select a beam and then choose "Select same object type", this will also select the staff and most other elements instead of all beams (if anyone knows any further information about that, it'd be much appreciated. As a matter of fact that might be the bug which should be filed: SVG Object types aren't seemingly exported well). Hope that makes sense as to the reason for wanting to maintain layout while variating visibility.
Any further ideas with this?
In reply to Thanks for responding Marc… by worldwideweary
The way I see it, anything invisible should be ignored by musescore (or is it Musescore or MuseScore 😁) when it comes to layout. In your example you use a slightly extreme example of two invisible groups of notes not ignoring each other. Since these items are invisible, they will not affect layout or be printed, so they are no issue most of the time. Special casing every invisible collision would be a daunting task and I don't want to know how it will slow down drawing the score.
In reply to The way I see it, anything… by mike320
Ok. I'm out numbered! But so the topic shifts and the question becomes how does one achieve what is desired? How can one have only certain types of elements be visible for export to do special post-processing since it can't be done with visibility since it changes the measure size (and beam direction if not explicitly set by the user when dealing with voices)? If an example were given showing only one voice being made hidden, it still would shift the measure size and hence remove the ability to quickly make hidden certain elements for the purposes of exporting while retaining uniformity of layout. As a matter of fact, for the sake of wholeness:
SVG Export again is another option, but as was mentioned, the object types don't seem to be implemented well with them, and so programs like Inkscape can't do what MuseScore 😁 does when "Select All Similar Elements".
In reply to Ok. I'm out numbered! But so… by worldwideweary
I really don't understand your ultimate goal or what's difficult about making voice 2 invisible as you did in your GIF. Even in your original GIF, all you should have needed to do was press v to make it invisible then x to flip all of the stems while the invisible items were still selected.
In reply to I really don't understand… by mike320
The goal related to the thread is to only have a particular set of elements be visible so that a score can be exported as an image for post-processing in an image/vector editor. Then, after exporting the score without those elements, the processed elements can be neatly "overlaid" as a transparent layer on top of the other image. This can't be achieved easily if the layout is shifting around during the process of changing visibility.
In reply to The ultimate goal is to have… by worldwideweary
IC
You need a way to set measure widths. With your goals, using staves with invisible notes or rests, as is the usual method, won't work.
You may be forced to make the notes white with an alpha of 0 for the unseen notes then make them gray to make them look invisible when you want to see them. That's the best Idea I have.
In reply to IC You need a way to set… by mike320
Thanks for the idea, as I hadn't thought of it prior to starting this thread.
In reply to The ultimate goal is to have… by worldwideweary
Given your scenario, I had a different idea, but the results are extremely weird.
There is another way to make things invisible, namely change their color alpha to 0
Unfortunately, this seems to not be respected for noteheads & beams. Funnily enough, ties and stems do become fully transparent.
Which does bring me to another possible workaround, namely, change the color of those elements to a unique thing. The use "select by color" in your image editor to easily remove these elements.
In reply to Given your scenario, I had a… by jeetee
Although it seems that locking the stem direction will eliminate most situations run across so far discussed, your last workaround is rather from a nifty way of thinking. I tested it in Inkscape, and indeed, "Select by fill color" will select all elements that have been altered (even if only slightly like using #010101). Thanks much for the tip as an alternative.
P.S., Maybe the fact that not everything honors transparency should be discussed in another thread about whether it should be sent to the issue tracker and implemented for uniformity's sake ?
In reply to Ok. I'm out numbered! But so… by worldwideweary
It's not clear to me what you desire or why you desire it. To me, the current behavior seems obviously what would be desired in every use case I can think of. Best if you attach an actual real-world example rather than just pictures so we can understand better.
In reply to It's not clear to me what… by Marc Sabatella
If the above statement which was commented on by Mike123 isn't making sense, I'm not sure I understand how to better word it. For now though, the idea has shifted from MuseScore and visibility related layout changes into MuseScore's SVG export capability (a different topic in the functional sense related to MuseScore as a program: maybe a different thread should be created). It seems that MuseScore doesn't thoroughly provide specific object groupings for each type of element so that an external editor such as Inkscape can adequately select all "Similar object types" like with MuseScore's ability to select all similar elements. Forgoing the visibility and layout shifting, this most definitely ought to be updated if possible.
In reply to If the above statement which… by worldwideweary
Well, I kind of understand that you are doing something that involves combining MuseScore with some other program to create what seems like maybe some sort of animation of a score being built for as yet unknown purposes that require it to not actually look like what a score actually looks ike while being built, but instead some sort of artificial rendition in which at various stages it is not actually proper notation, kind of like an animation where first the stems appear then the noteheads, except you are talking about first voices 1 notes then voice 2, or something like that. I can kind of picture what you are talking about but struggling to understand the context.
On the surface of it, it seems might indeed be best off exporting as SVG and then simply removing the elements you don't want to see. Or, perhaps, using notes on a separate staff to force the spacing the way you want it, and as for the beamns, just use the usual MuseScore means for forcing them the way you want. Again, without a specific real-world examples to discuss, it's hard to give good advice on how best to achieve it, so the best we can do are vague suggestions like these.
In reply to Well, I kind of understand… by Marc Sabatella
To give example imagery: imagine thickening the note heads by using some image-filters in an external program, but not thickening anything else of the score. Or, specifically with beams, imagine to make them slightly wavy but not at all touching the straightness of other elements of the notation, like the staves or note-stems. Operations like these require to have separation of the desired specific elements so that they can be imposed upon by an external program quickly, but the result will need to be 'overlaid' over the regular score without those elements, hence the desire to make invisible in bulk certain elements. Hope that helps your understanding as related to the intentions.
In reply to To give example imagery:… by worldwideweary
It helps slightly. Again, an actual score and an actual explanation of the specific purpose would help more. As it is, it still seems the suggestion I gave would work perfectly and solve the problem completely, from what limited information I have available.
In reply to It helps slightly. Again,… by Marc Sabatella
To what do you refer in mentioning a suggestion? If it is to lock manually, please explain, as it has been demonstrated that merely making something invisible will often change the measure size which in turn will shift the positions of the elements, and by so doing will negate the ability to overlap an image without having to rearrange anything manually.
In reply to To what do you refer in… by worldwideweary
Locking for stem direction, notes on another staff to force a particular measure width and spacing, as mentioned earlier.
In reply to Locking for stem direction,… by Marc Sabatella
Okay. Again, thanks for the tips.
Locking stem direction by way of selecting each voice separately and pressing 'x' two times so that stem direction is manually configured rather than automatic seems to be helping with the issues had as of late. Maybe that'll do it after all.
Still, another topic related to SVG object-types might be worth looking into for later development.
In reply to Locking for stem direction,… by Marc Sabatella
You can be discussing for weeks, there will never be an end because clearly there are two different goal to unvisibility:
A-do not show item but take it in consideration in layout
B-do not show item and ignore it in layout of visible items
MuseScore should offer both options.
In reply to You can be discussing for… by frfancha
YES!!!! PLEASE!!!!
In reply to You can be discussing for… by frfancha
If you want an invisible element to influence the layout, make its color white (assuming white paper) or transparent
In reply to If you want an invisible… by Jojo-Schmitz
Good trick, but doesn't it make it quite difficult to find it when you need to alter that "false invisible" element later on? Or just difficult to discover that such an element exists in the score?
In reply to Good trick, but doesn't it… by frfancha
True, there's a downside to it. You could change the canvas to something darker then plain white to see the white element again