Make invisible things not take up space

• Jun 23, 2012 - 00:30

When you make something invisible, say courtesy a time signature not needed between movements, or just about anything in music notation... usually you don't want it to take up space. Would be great if this was the default behavior, possibly with a way to make it take up space if anyone actually needs that.
I can't really think of a use case for having an invisible item still take space. It means you frequently have to jump through hoops when you want to hide something.

Comments

• Jun 23, 2012 - 05:24

I suspect one reason they might still take up space is that often in various notation programs, placing hidden elements was the best way to create extra space. But MuseScore provides other methods for that, so I tend to agree that invisible elements generally shouldn't take space.

Reply

• Jun 27, 2012 - 07:56

Music notation is full of different "things". If you have a system with several staves, and you hide one time signature, it's unlikely that you want this to affect the layout. If you have make invisible rests in voice 2 of a measure, it's unlikely that you want this to move the notes in your measure. If you want something to don't take any room, and not be displayed, you could just remove it from the score after all. So I don't see the point. Maybe hiding element is used in case where it's not necessary? Can you provide real life examples where you would want "set invisible" to affect the layout?

A courtesy time signature between movement is a good example. You don't want to make it invisible. You want to get ride of it, together with the key signature. MuseScore 2.0 will have a section break to create a new movement and reset time signature, key signature, and define a period of time between the playback of the two movements. In the meantime you can deactivate the creation of courtesy time signature in Style -> Edit general style -> Page -> Create courtesy time signature.

Reply

• Jun 27, 2012 - 17:11

Also, even regular time signatures never normally need to be added and then hidden. Assuming the goal is to notate some tricky passage that you wish to do by temporarily having a different number of beats in the measure but you don't want to actually show it as a time signature change, that is what the "actual" time signature controls in Measure Properties are for. No need to insert a time signature chane then hide it.

So I agree with lasconic that in general, there wouldn't normally be a need to add an element, hide it, and have the hidden element not take up space. But abnormal situations could indeed come up, and I have had times where I had something I added for playback purposes that I wanted truly hidden (eg, notes entered to simulate a trill). On the other hand, there might be better ways of handling that, too. I've taken to moving "playback only" passages (like written out trills, or rhythm action accompaniment parts notated for human readers just with slashes) in a separate staff, then I would want a way to completely hide that separate staff.

So, yeah, more discussion, with specific examples, would be good.

Reply

• Jun 27, 2012 - 22:45

in your blank manuscript example, wouldn't it be better to *delete* the clef and time signature than to hide them? I think that is an important part of the distinction being made here. obviously, there are time when *currently* you might need to need something, because that's the only MuseScore currently allows you to not display it, and in those cases, it might be good to have them not take space. but in your example, the clef and time signature don't need to be there *at all*. so wouldn't the ability to delete them completely make more sense?

and if they were present but didn't take up space when hidden, how would you propose making it possible to select them so you could then unhide them or otherwise modify then?

Reply

• Jun 27, 2012 - 18:02

I disagree, and I'll try to explain why.
Music notation editors are quirky things. Composers are always pushing their limits. Like other editors, MuseScore demands that certain elements be present as part of the structure of a score, and users sometimes want to hide those elements to workaround various "missing features". That might include courtesy elements---and I realize those will be addressed separately in a later version---but it includes many other "things" as well. Your rest example is a good one. I can't just put notes in the middle of a bar, I have to fill the logical music space before them with rests, then make the rests invisible. I most certainly don't want the rests to take up space, any more than courtesy symbols that I make invisible. The editor should still line things up "properly", since the remaining notes will be matched beat-for-beat with notes in the other voice. Similarly, if I hide a time signature on one staff but not others, I do not want the invisible time signature to take up space: beats in the score should still line up properly, meaning there will be blank space there because visible time signatures in other staffs, but if I extract a part for the single staff with an invisible time signature, there won't be any extra space.
Any time the editor forces me to include some element and I want to hide it for some reason, I don't want it to take space. If I wanted to create space without using the existing layout controls (and I've never had this happen), then a good alternative to having invisible things take space would be to have a "space object" that invisibly takes space.

Reply

• Jun 27, 2012 - 22:38

Can you provide an actual example, though, in which the rests would take up more space than whatever else was already present in the measure? That's the part I am having trouble u nderstanding. Normally, all rests in all voices are required to be shown, according to standard rules of musical notation. There are certain well-defined exceptions in which it is permissible to hide certains rests in certain voices. But in every single one of those special caees I can think of, the rests add no space, as there are always notes in other voices that are already requiring at least the same amount of room. I can't think of a single case where that would not be true. Which is why, again, talking about specific example rather tha generalities would help. Can you post a specific example of a case where a hidden rest is actually taking up space that it shouldn't?

As for the time signature example, again, you'd need to provide a specific musical example. I am having a hard time imagining real life cases where you'd want to hide a time signature change in one staff but not others. And the very few cases I can imagine are better handled by other means than hiding time signatures - eg, using the "actual time signature" measure property, or the new "local time signatures" facility in 2.0.

Again it's one thing to say that in some vague general sense, invisible items sometimes shouldn't be allocated space (other times ey very clearly should be), another to find an actual real life example that requires this behavior. I am certainly not sayi g Iknow for a fact they don't exist, but I am beginning to see it isn't nearly as simple or obvious as it seemed at first glance.

Reply

• Jun 28, 2012 - 01:29

The reason I'm speaking in generalities is that the whole point of making things invisible is to work around existing limitations of the editor. There will likely be such limitations for a long time, though any specific case can be solved by adding some other feature (e.g. movement breaks hiding courtesy time sigs). If you *could* delete everything that "shouldn't be there", there would be no need for invisible, silent elements like invisible rests. (Invisibility can also be used to hide playback-only elements, but for such elements you don't need them to take up space because you only care about how they sound, not how they look.)

Now, given that the invisibility feature is mainly useful for quick workarounds to existing limitations of MuseScore, you have to ask which of these two behaviors would be worse:
1. it takes up no space and you want it to take space
2. it takes up space and you don't want it to

Since you're working around something that was there that you didn't want to be there, it seems to me that (2) would be worse and (1) is unlikely. In the case of (1), you can probably find some other way to move things around and insert space, and as I said, a very simple and general space-taking element would suffice to completely eliminate (1), as would an option to make an invisible and take up space. But in the case of (2), there's nothing you can do until someone adds a specific feature to MuseScore to let you delete the thing you don't want to see.
In fact, if invisible items could be made to not take up space, you could probably eliminate some other features, and therefore reduce the complexity of the editor: e.g. you don't need "actual vs nominal" time sigs at all if you can just make a time sig invisible and take no space.

As for selecting such elements when they overlap other elements, there are many ways you could do it. One would be to let alt+click or some such combination cycle through overlapping elements, which would be nice even for visible elements.

---
Edit: To summarize, I think this would be an easy-to-implement feature that could cover a lot of potential cases. If you think it's necessary to support the existing behavior, having both would be a great option. Not having this feature means your options for workarounds are much more limited.

Reply

• Jun 28, 2012 - 01:48

Again, it really would help if you would provide at least one specific example. In particular, regarding rests. I believe you are is p,y I correct: there is never a case where a hidden rest will ever require extra space. At least, I can't imagine. If you can, again, please provide an example. As for time signature, I think havthise that/nominal time signaturesthis a *much* better solution than the ugly kludge of creating a time signature change then hiding it. Especially since, as I said, if invisible items were to take no space, you'd have to solve the problem of how to still make those elements selectable and editable.

I guess the point is, it will presumably take a lot of effort to change MuseScore in this way. If the developers are going to take time away from fixing bugs and implementing important new features valued by many users in order to implement this one, it had better be worth it - there had better be a real world problem that it solve that cannot be solved in better ways.

So once more, can you provide examples? Real world problems not solved in other better ways?

Reply

• Jun 29, 2012 - 00:04

As I said, the reason I'm speaking in general is because for any specific example, you can always say "MuseScore should/will someday support that specific feature". The point of making things invisible is to provide on-the-fly quick workarounds for which there is no specific feature, but this ability is greatly hampered when invisible things take up space. The feature I'm suggesting should be relatively quick to implement (presumably there's a method that asks an object for its size, and it can return 0 or the caller can substitute 0 if the object is invisible) but generate a lot of potential power for pushing the limits of MuseScore.

But if it helps to see another specific example... I've uploaded one. Currently MuseScore's support of 2-note tremolo is incomplete. Specifically, in m.1 you see a "tremolo symbol" placed arbitrarily between two half notes. I'd like to do a beamed tremolo similar to m.2, and in fact that's exactly what I have done by changing the noteheads. Unfortunately, those pesky invisible rests take up a bunch of space when you print the score. Would be great if MuseScore supported beamed tremolo directly, but you'd be able to solve this real-world problem without it if invisible things weren't getting in the way.

Attachment Size
tremoloExample.mscz 1.54 KB

Reply

• Jun 29, 2012 - 04:17

Yes, for every thing you might currently do by adding invisible elements, MuseScore might someday support this - and it might be less effort and a more elegant solution than implementing specific non-space-taking invisible elements, especially since other invisible elements probably should continue to take space just as they do now. Hard to sday without specific examples, hence the requests.

The case you show is a good example of a very unusual use of hidden rests. Your example doesn't even play back correctly; the rests are there because your notation is actually incorrect (deliberately so, of course). And in that case, sure, you'd like the results to space as if the notation were correct. But in cases where rests are used normally - for the correct musical effect - then one generally *would* want them to take the normal amount of space.

Anyhow, in this case, a better workaround for MuseScore's lack of support of this notation might be to enter the notes on the beats one and two rather than as adjacent 32nd's, with a double dotted eighth rest after each, then extend the beam over the first rest. Now, the rest is actually *supposed* to take up space and will accomplish automatically what you had to fake using edit mode - spacing the notes out better. It's a little too much space, but that can be adjusted manually. This is a much better solution as it plays back better (still off, of course) and takes advantage of the musically correct spacing that MuseScore currently employs.

Examples like this show why it is important to consider things like this case by case. The way you've done things - by deliberately notating the passage incorrectly, with incorrect playback -sure, rests that take no space might appear to make sense. Notated differently, then suddenly rests go back to being things that should take up space.

Reply

• Jun 29, 2012 - 08:26

Another simple issue about making something invisible out of the layout, how would you undo it ? Currently you can select the object and make it visible again. If the object is completely deleted, you can't undo it or you need one more action, show invisible, that will destroy the layout, possibly making system jumps etc...

Reply

• Apr 3, 2019 - 18:37

Well maybe once has to accept that the hidden element when revealed will cause space to be inserted. I use this capability frequently and would be happy to have a control that allowed me to override the space used by the hidden elemenbt. These are two examples:

1) to make multi-bar rests appear using the block notation (vs h-bar). I hide the H-bar notation and drag the appropriate symbols from the symbols pallet. However, the downside it that the space occupied by the original h-bar symbol remains.

2) Where I want a repeat barline to appear in the middle of the bar - typically a March with a Trio that begins on the the upbeat. For spacing reason I don't want or need to begin the Trio on a new line. So, if the basic time signature is 3/4 and the trio begins on the beat 3, I convert the last bar of the march to a 2/4 and 1/4 with hidden time signatures but leave the march repeat barline in place.

Reply

• Apr 3, 2019 - 19:04

It's still relevant - to me at least. I was searching the forum looking for an answer and stumbled on this. Please tell me it's been fixed :-)

When you say split the bar - what do you mean?

H-bar is the notation with a single thick line and two vertical thin lines at the end. The alternative and older notation is used in classical music for rests up to 9, thought I have seen 40 using this notation in 19th century parts. The modern usage is up to 9 bars then the h-bar notation for anything greater. Why use it: it's more elegant, the numbers of bars rest is implied by the symbols and can be a life-saver for well used parts then the numerals become obscured. it uses less space and it's the norm for classical music. There's a feature request on this - I may have created it. A number of folk have asked for this over the years.

Reply

• Apr 4, 2019 - 00:04

Actually I did manage to get this to work, without deleting the parts, but it did have some side-effects such as changing the span to next stave of all subsequent barlines. I wasn't able to recreate the odd effect I saw when I first tried it. There is one thing that splitting the bar doesn't do: change key signature after the split. That has to be done in the following bar.

Reply

• Apr 3, 2019 - 20:44

I don't think so. This arises when one generates parts from a score. I prefer to keep the parts attached. In the score I turn off multi-measure rests and in the parts I turn them on. I have to hide the h-bar rests in the parts but hide the block notation in the score. It's a bit messy. One of these days I'm hoping musecore will support this.

Reply

• Apr 5, 2019 - 05:11

This feature is useful when invisible notes are used for playback workarounds. For example, Musescore does not assign each note of a tremolo with a different dynamic when a crescendo is used; it only assigns velocities to the written notes. To get proper playback, one must write many invisible notes. These notes can make measures far wider than they should be.

Reply

Do you still have an unanswered question? Please log in first to post your question.