MuseScore
MuseScore copied to clipboard
musescore
[MU4 Issue] The user should be able to unmute hidden instruments
Describe the bug See #9357
If you hide an instrument using the 'Instruments' panel, the instrument should be muted in the mixer. The user should be able to unmute it if they want
https://user-images.githubusercontent.com/90187801/160684542-0789944b-9c0a-4f97-a989-697c02ee5476.mp4
Expected result You should give user ability to unmute hidden instruments in Mixer (or implement something in Instruments panel - see https://github.com/musescore/MuseScore/issues/9357#issuecomment-950046752 )
Platform information macOS, Windows, Linux
I think this is a feature request that will take time to get right. I don't have a major problem with the idea and I can see how it may be desirable at times. But for now, let's bump to 4.x.
It would be good to do this eventually.
This isn't a feature request, it's a regression - it has always worked in the past and lots of people rely on it as a way to get all sorts playback effects you can't otherwise (rhythm section parts notated with just slashes, various ornaments and other notations not supported for playback directly. I have verified this issue with one of my big band scores; no drum playback in MU$.
The good news is, it seems you can still access the mute controls, if instead of hiding the instrument, you hide its staff (or staves). So it seems the functionality is still there (thankfully!) - it just for some reason isn't working as it should when hiding the full instrument instead of its staff/staves.
It's still a regression in that it means any imported 3.x score using invisible playback staves won't play correctly without employing a hard-to-discover workaround. And even for new scores, it isn't necessarily obvious that you even can hide the staves individually or that this would work when hiding the instrument doesn't.
@bkunda - would be good to perhaps consider a design here. Perhaps just the ability to toggle on/off the sound in the mixer? Perhaps something in the Instruments panel itself?
@bkunda - would be good to perhaps consider a design here. Perhaps just the ability to toggle on/off the sound in the mixer? Perhaps something in the Instruments panel itself?
Do we really need a design for this? (Maybe I'm missing something).
I think at this stage our goal should simply be to restore the functionality as it was in MS3.6, which would mean:
- Not automatically muting an instrument that has its stave(s) hidden in the instruments panel
- Allowing the user the ability to mute and unmute any hidden instrument in the mixer
This behaviour presupposes an expectation that what you see on the score is not necessarily always linked to playback – i.e. that the two are separable, allowing users to create playback effects that are not directly connected to what is on the score. This might of course be a moot point, but I'd suggest that any discussion about this would be better reserved for an MS4.x release.
I don't think we should return to 3.6 behaviour. It is more weird for the sounds to persist when the instrument it hidden.
It could just be that we allow users to unmute in the mixer. However, this might be a hacky solution, so I thought it deserved more thought then that. Perhaps we can use this solution for 4.0 but the logic would need to be spelled out:
- If you hide an instrument, it would automatically mute the instrument in the mixer
- If you unmute, the instrument can now be heard again
- (Part I'm not sure about) If you show and then hide the instrument again, it would still be heard (and users can mute it again if they want)
- (OR) every time you hide an instrument, it always mutes in the mixer
It is also worth exporting a score from 3.6 with a hidden staff and importing it to Audio.com to see what happens currently.
We may need to support this in 4.0. Not sure.
OK I think I can be persuaded to this (I have storied-out some user cases in order to think this through, which I'd be happy to share elsewhere if it helps discussion).
In this case, my suggestion would be that we adopt a fairly hard line about the interaction between showing/hiding instruments and their playback property, i.e. unmuted/muted. This is in order to keep the behaviour predictable.
So, by default:
- When an instrument is hidden in the instruments panel, its playback is automatically muted
- When an instrument is not hidden (or rather, shown) in the instruments panel, its playback is by default un-muted
In either case, this playback property can be overridden in the mixer:
- A hidden instrument can be unmuted (currently broken)
- An unhidden instrument can be muted (existing functionality)
If the user changes the visibility state of the instrument in the instruments panel, playback for that instrument reverts to its default state.
For example:
- The user un-mutes a hidden instrument to hear its playback. They then show the instrument in the instruments panel – playback is again available (the instrument becomes un-muted). They then hide the same instrument again – playback is muted.
What do you think @Tantacrul? Perhaps we can also chat separately about importing to musescore.com.
As for supporting this in MS4.0, I think we definitely need to address the issue of not being able to un-mute a hidden instrument, so there's only (he says, naïvely) one more step to establish beyond that, which is to ensure that the instrument becomes muted again if the user shows and hides it in the instruments panel. Not implementing this extra step in MS4.0 could cause some unpredictable behaviour, with playback occurring by default for hidden instruments in some cases but not others (my spider sense says this could be problematic).
I'd definitely be interested in seeing the use cases that people have in mind for wanting invisible instruments to automatically be muted. Personally, for me, I don't think I have ever included an instrument that was both invisible and muted this, and I've created a heck of a lot of scores. For me, it's always invisible or muted, but never both at once. But maybe others work in very different ways and do commonly find a need for scores that are both invisible and muted. Could be a good time for a poll, and/or a statistical analysis of actual scores on musescore.com. And further discussion on Discord or wherever if we want to keep it out of here.
As long as 3.x scores import correctly (invisible instruments play by default as they always have) and it's obvious and simple how to make an instrument invisible but still have control over whether or not you hear it, it doesn't matter too much to me what the specifics are. If I need to open the mixer and turn the mute button back off every time I hide an instrument, I can handle it. But I have to admit I'm scratching my head to understand why we'd want to take on all that extra complexity of worrying about all these different scenarios, and potentially surprising a lot of users, when I don't recall anyone ever complaining about the MU3 behavior.
This would be one example user case:
As an ensemble leader (of a classroom/non-professional ensemble), when I want to create a version of my score that contains an alternative part for one of the instruments (e.g. an easier, or more difficult part), I want to be able to hide the part that I no longer need so that I don’t see and hear the wrong version of the score during playback.
Agreed that the best way to really establish this would be through user research (ideally observing people hiding instruments and asking what they expect would happen to the playback). Given where we're at with the current release timeline though, I'd say that our next best opportunity will be during usability testing, which will confirm for us whether the design needs needs revising.
Makes sense. But either way, the regression where MU3 scores will incorrectly needs to be solved.
Reported again in https://github.com/musescore/MuseScore/issues/10951. I had forgotten about this. Hiding instruments but still hearing them is pretty essential for jazz scores where people use this for rhythm section parts or improvised solo sections that are notated just with slashes. Also any number of places where people wish to write out a complex ornament playback etc.
I still say, not once during the 10+ years of MuseScore 1, 2, or 3 can I recall anyone ever complaining that invisible instruments could be heard by default. To me it's expected behavior. The simple solution for 4.0 is to just remove the code disabling the mute button, and then it can always be revisited.
I went ahead and created a PR for this (https://github.com/musescore/MuseScore/pull/13282; ignore my local WIP version), simply restoring the MU3 behavior where hiding an instrument and muting it are independent. It's simple and it's what people are used to.
I'm assuming that at this point, user research and a new design for an alternative scheme is not in the cards for 4.0, which is fine by me. I'm also fine with seeing this revisited in the future. But meanwhile, the regression needs to be for fixed for 4.0, as there will be tons of scores that suddenly don't play correctly. Plus it's an important capability for new scores with only a difficult-to-discover workaround otherwise.
I think we have to stick with the current behaviour and add the ability to unmute instruments - as suggested by Dmitri. I do not think it is simple or intuitive to hear music you don't see by default.
It would also require a large inconsistency with part scores (do we hear all other, invisible instruments when we play a part score by default?).
As someone who uses invisible playback staves almost every day (as do almost all other jazz arrangers), I guess I don’t see why you’d think of this as less intuitive than seeing staves you don’t hear. And yet no one seems to be suggest we automatically hide staves when muting them. Why is it intuitive in one direction but not the other?
But as long as the regression is fixed - that existing scores that uses this technique continue to play correctly without workarounds - I’m sure people can adapt to needing a few more steps to accomplish this on new ones. Just seems like a weird thing to ask everyone to have to do.
Just curious - do all other major notation programs automatically mute staves when hiding them, but not the reverse? If so, the. I can see why it might seems intuitive for people used to those programs.
You might want to mute tracks so you can momentarily isolate others. It's not really a comparison I'd draw.
You've explained why you want to hide sheet music but still want to hear it, so we accept a user should be able to unmute a hidden track. However, making it work like that by default doesn't make sense.
@Tantacrul Allowing the user to unmute tracks for hidden instruments is not straight-forward at all, especially when it comes to part scores.
The problem is that mute/solo state is in principle a project-wide setting. Currently, the logic to determine whether a track is actually muted is as follows. A track is actually muted if either:
- the track has been muted by the user,
- or a different track has been soloed by the user,
- or the staff corresponding to that track is not present/visible in the currently viewed part.
If a track has not been muted by the user but is still actually muted for reason 2 or 3, the "mute" button in the Mixer is disabled, because it wouldn't do anything useful: the track will stay muted because of reason 2 or 3.
Note that the user's chosen mute state is never changed by the playback system itself. The user's choice is also what gets saved into the file; so if a track was automatically/temporarily muted for reason 2 or 3, this will not be stored in the file but rather computed dynamically from other data.
If we want to allow the user to unmute tracks that would be muted for reason 2 or 3, we have to use a different logic, but it is not clear to me how it should work exactly. Some things that make it difficult are:
- we should allow overriding reason 3, but not reason 2;
- mute/solo state is (currently) a project-wide setting and can't be stored per-part;
- it's unclear how/what should be saved in the file (for example, if the user switches to a part score, then we would automatically mute the invisible staves, but that should not be saved in the file, because otherwise, next time the user opens the score, those tracks will be muted in the full score too).
So what we need to solve this issue, is a clear definition of how the new logic should work. What would be your suggestion?
One suggestion of mine: instead of an on/off setting, we can make "mute" a three-state property:
- unmuted -> user has specified that this track should always sound
- default -> muted-ness of this track will be determined by the visibility of the staff in the currently viewed part
- muted -> user has specified that this track should never sound
(reason 2 about the "solo" setting will always take priority over whatever choice the user has made)
This could be how it works internally, but I've no idea how we should represent it to the user, because of course from UX POV a "mute" button should look like a simple on/off switch.
I think the way we'd want it to work (just side-stepping the technical considerations for a moment) is this:
- A user can un-mute a hidden instrument using the mixer (this would mean we'd have to create additional logic for hidden instruments)
- If another instrument is soloed, then the mute buttons are disabled, so the user can't unmute anything until the solo instances are cancelled
- I don't think we should create a third state in the UI because this isn't a problem users will understand.
If it is too complex for 4.0, then we wait until 4.x to do it. We unfortunately can't perfect everything at this late stage and I'd rather hear from some users if this is really a feature they consider to be important before committing a lot of time to 'solving' it.
I'm also open to the idea of adding UI to the instruments panel to allow for turning on/off sound for each. Although, since this idea requires an actual redesign, it can't make it in for 4.0.
We unfortunately can't perfect everything at this late stage and I'd rather hear from some users if this is really a feature they consider to be important before committing a lot of time to 'solving' it.
If you want more users "opinions" you should make this issue more visible (i.e. a post in the forum and get feedback). It is a feature I use often in MS3. My guess is that users will experience "playback" issues after open a MS3 score in MS4 and consider there is an issue with migration scores from MS3 to MS4 and may (as a result) be reluctant to start using MS4.
btw, Marc: I do get why you want this solved pronto. I was hoping there'd be a quick fix here... but it's worth pointing out that the new setup is quite different to MS3 and sets up different expectations.
- The instruments panel doubles as the way users manage the visibility of their parts. So if it works one way there, it should work the same way on the main score.
- Anyone using the instruments feature to create alternate passages or as a method of displaying combined instruments (eg: 4 horns on one stave) in the main score, while having each instrument separated for parts will end up hearing loads of things they don't want to hear.
One last point, which I don't really make enough: for an app like this, my general approach is that UX is everything. I'd rather delay a feature in order to get the UX right rather than provide a quick fix solution that ostensibly solves the problem but in a confusing way, which then needs to be undone later.
@henkdegroot
If you want more users "opinions" you should make this issue more visible
We've agreed to come up with a solution, the only remaining question is when we do it. We unfortunately, cannot delay this release any further, which is the real sticking point.
I'm coming around to being able to let this go, except for the matter of existing scores.
While I remain unconvinced that the new design will automatically change people's expectations about the connection between hiding and muting, the fact that MU4 makes it possible to hide staves without hiding the instruments is, I think, our ace in the hole here. It means you no longer even need to add a whole new instrument to get an invisible playback staff for the usual sorts of purposes people use these for currently. Instead, you can just add a new staff to an existing instrument. So going forward, it shouldn't be a big deal to re-train people to think this way, and it may even seem like a win once people get used to it.
But, my main concern remains existing scores. It is still a pretty huge regression that tons of existing scores won't play back correctly without some action being taken here. Since it is the case that invisible staves are still heard by default, and the ability to hide staves as opposed to instruments was not present in MU3 and earlier, my proposal would be, for older scores, we automatically convert invisible instruments into invisible staves on import. That is, still add the instrument, but don't mark the instrument invisible - mark its staves invisible.
That should fix the playback of existing scores without affecting anything about the current UX, and it will also help people see how this is done,
New PR https://github.com/musescore/MuseScore/pull/13293 implements the import behavior described above. Tested for 3.x and 2.x; I don't have any 1.x scores with invisible playback staves handy to check.
I have more than 100 scores that use the 3.6 behavior. I will not move them to 4.0 as long this is not fixed.
I frequently add staves and make them invisible for one single purpose: playback. Use case: mixed choir in unison, women visible (and with an optional ottava bassa clef), men hidden (and an octave lower of course). Only reason for having those is for playback.
Not having this in Mu4 is a showstopper to me
I'd like to suggest that my PR https://github.com/musescore/MuseScore/pull/13293 be merged for Beta if at all possible. It makes no changes whatsoever to the UX, no changes whatsoever to any new scores created in MU4. It simply makes sure that existing MU3 scores with invisible instruments play back correctly, by taking advantage of the way staff visibility works now (converting invisible instruments into invisible staves). There are a number of other issues that will interfere with proper playback of existing scores, and many of those we can't easily do anything about, but this one we can and should.
Long term, barring additional user feedback, I'm fine with the existing UX where invisible instruments are muted but invisible staves are not. However, another significant regression is that there is no longer a way to mute one staff of a grand staff but not the other. So, I would like to observe that adding a mute control to the instruments panel - say, an ear icon next to the existing eye icon - would solve that problem nicely, and also partially address concerns about the mixer being too big. So, definitely something to consider for 4.x.
We're going to allow users to mute / unmute hidden instruments for sure. We're going to do quite a lot of cool playback stuff with the instruments panel in fact. However, the dev team have advised that this is a complex thing to try and rush in (at the time, we were discussing it for alpha 1 or alpha 2)
But we can't have an inconsistent system where some scores work one way and other scores work another way. It's just something we'll have to build into MS4 'properly', if you know what I mean?
I still think there is misunderstanding about this. Hiding a single staff within an instrument works perfectly right now in MU4. It's fine as is and will continue to be fine even if new cool features are also added. Adding a second invisible staff to an existing instrument works is exactly how people should be adding invisible playback notes for most use cases. Like, for instance, creating an invisible second staff for VST key switches. Or creating a second drum staff for playback while using slash notation for the notation. No changes at all are required to make that work in MU4 - it already does, and works well. So that is what people will start doing in MU4 from day one.
I'm just asking that we allow existing MU3 scores to take advantage of this feature automatically - so they will work the same way as MU4 scores. That is all my code does. It doesn't make them work differently from MU4 - it makes them work the same.