Make track muting/unmuting more intuitive (by sticking to the established standard)
First of all, kudos to your User Experience team. They have done a great job of designing a simple, intuitive tool to support what is a pretty complex, multi-user, collaborative task.
That said I find the way in which soundtrap supports muting/unmuting of multiple tracks confusing and inefficient.
First, let's talk about the confusing bit. I find the approach taken by SoundTrap difficult to understand and I find myself having to explain it over and over to my 20+ choir members.
There is a well-established UI pattern for muting/unmutting a bunch of tracks and it goes like this:
- Provide two buttons: mute-all and unmute-all
- Provide a speaker button for each track. When the speaker button is greyed out it means muted. If it's purple it means audible.
- If users want to mute most of the tracks, then they do:
--- mute-all, which turns all speaker icons to grey (muted)
--- click on a few speaker icons to make those tracks audible
- If users want to make most tracks audible:
--- unmute-all, which turns all speaker icons to purple (audible)
--- click on a few speaker icons to mute those tracks
This standard pattern is efficient and well understood by users.
For some reason SoundTrap chose to use a completely different UI pattern, and I find it extremely confusing and inefficient.
Here is how it goes as far as I can tell:
- No mute-all / unmute-all buttons
- Each track has both an earphone and X'ed-speaker (mute) buttons which can be gray or purple
The behaviour of the X'ed-speaker icon is as follows:
- Clicking on a grey X'ed-speaker icon will mute that track (as in the standard UI pattern)
- Clicking on a purple X'ed-speaker icon will unmute that track
-- UNLESS one or more tracks have their headphone icons in purple, in which case the track will remain muted and it looks liike clicking on the purple speaker icon did not do anything
-- BUT WAIT, clicking on the purple speaker DID INVISIBLY achieve something and it's actually the OPPOSITE of what I wanted to achieve (i.e. wanting to hear that tracks). Indeed, if I click on all the purple headphones all tracks will now be un-muted, EXCEPT the one track I wanted to hear in the first place!
The behaviour of the headphone icon is equally confusing:
- Click on a grey headphone icon to mute all tracks but that one.
-- ACTUALLY, not really. If another tracks has its speaker icon in purple, clicking on a grey headphone icon will add the clicked track to the list of audible tracks.
--- Hum... isn't that what the purple X'ed-speaker icon is for? Answer: No. See above for what happens if you click in the X'ed-speaker in that situation.
--- Also... how can I tell if this will mute all others or just add this one to the audible list? Answer: If you see another track with a purple headphone on the screen, it means add this track to the audible list. If you don't see another purple speaker on the screen, you have to scan the list of tracks (I have 20 tracks, one for each of my choir member) and check if one of them has a purple headphone. If no other tracks have a purple headphone, it means mute all others.
- Click on a purple headphone icon to remove it from the list of audible tracks
-- ACTUALLY, not really. If this the las purple headphone in the piece, it will unmute all tracks
--- Well, not really... some tracks may be left muted (see the above description of the X'ed-speaker icon)
Another thing I find confusing about the headphone/X'ed-Speaker that the colour purple means different things for those two buttons
- For headphone, "purple" means audible
- For X'ed-speaker, "purple" means muted
All in all, this is very confusing. I think it would be much clearer if SoundTrap sticked to the established UI pattern of:mute-all / unmute-all + speaker icons
The standard approach also turns out to be more efficient when you have lots of tracks. For example in my choir (20+ tracks), people often need to switch between listening to:
- Only tracks in the same section as they are (ex: Bass)
- The whole choir
Suppose all tracks are initially audible and I want to mute all but the 5 Bass tracks. The number of clicks is about the same for both approaches (6 for the "standard" approach, 5 for the current soundtrap approach).
But now I want to listen to the whole choir. With the standard approach, I just click on unmute all (1 click). But with the current soundtrap approach, I need to un-mute the 5 bass tracks (5 clicks). Also, I have to make sure I didn't miss one, whereas with the standard UI, I just have to make sure I click on the one unmute all button.
An much worse scenario is the following. Suppose I want to hear all but the 5 bass tracks. With the current SoundTrap design, this requires 15 clicks (I have to click on headphone icon of the 15 non-bass tracks) vs 5 with the standard design. Un-muting those 5 bass tracks requires 5 click with the Soundtrap design (one for each bass track) versus 1 for the standard design.
----
Well, that's it. Sorry for the lenghty request and I hope it helps improve an already excellent product.
-
Agreed - mute and solo are confusing. Another request that postdates this one also talks about this. Very intuitive on one track but doesn't scale well to a project where you have to scroll...
now in COVID some of us are making humongous projects, and I think we need some better track management tactics, including unsolo all and maybe unmute all. But for this case, track grouping tactics might be just as worthy a move.
Groups/buses/VCAs, though confusing as hell if done wrong, could be INSANELY helpful. Also for big projects, instead of freezing a track, freezing an entire track FOLDER (maybe like Logic Track Stacks) would get sessions running faster and help track management big time.
-
To clear the confusion up:
The headphones do NOT mean 'audible'.
The heaphones mean: Put this track on solo
The speakers mean: Put this track on muteYou can see this by hovering over the icons, where it will state each button's function. This is, by the way, the established standard you are asking for and Soundtrap is sticking to it, as you are asking for.
I absolutely agree with the masses of clicks needed to be made when trying to reset things, but I don't quite understand the confusion about the button functionality.
You say that purple on the icons means a different thing, even though purple simply means 'active' in the context of the buttons function.
For example: If I click the solo-icon (the headphones), I am activating solo for this track. As with any other DAW, any number of tracks can be made solo. This has ever since meant that everything that is not solo is muted and all tracks that are solo are audible on playback. This implicitly mutes any other track
The same goes for the mute icon: If I activate mute for a track, it is muted. As with solo, you can mute as many tracks as you like. The difference is that by clicking mute, I explicitly mute the track, meaning it's mute state will not change If I solo or un-solo a different track.I think the confusion arises from using both in combination, because soloing a track will implicitly mute others. Un-soloing would thus implicitly un-mute those that were muted before, but NOT those I have explicitly muted by clicking their respective mute icon.
The only thing to criticize here is that the implicit mute looks the exact same like the explicit mute and you wouldn't be able to tell it changed if you clicked. This is what you described in your first example. The mistake you were making is to assume that un-muting a track while having other tracks in solo would make the track audible. This is wrong and contradicts the concept of solo, because un-muting a track while having others on solo doesn't put the track on solo as well, of course. The right way to do would be to solo the other track as well, which will automatically clear any muted state.
Suppose I have three tracks. I mute the first, it's mute icon turns active (that is, purple). I then solo the third, which will activate its icon and add it to the solo-ed tracks list, which are the only ones audible. This action will implicitly mute the second track, since it was unmuted and do nothing to the first, since it was already muted.
Un-soloing the third would then again unmute the second again but leave the first muted, as I told Soundtrap explicitly to keep it muted.
Likewise, un-muting the first while the third is on solo still results in only the third being on solo. That's why the first track stays muted. It's state only changes from an explicit mute to an implicit mute, the implicit being because there are tracks on solo.I really don't see what's confusing about this, but maybe it's because I'm a software developer myself and this is exactly what I would've implemented.
Still, your point in resetting stands, but the safe way to go is to first un-solo all tracks, then un-mute those you need and mute those you don't.
That being said, solo/mute for individual tracks like this is a widely used mechanism and works in Soundtrap like it works everywhere else.
If you don't believe me about this, I have had a look at Ableton's manual and basically, I can transfer what it says there about solo/mute pretty much exactly onto Soundtrap.
This is the passage from the manual:
4 - To mute the track’s output, turn off the Track Activator switch. [...]
5 - Clicking the Solo switch [...] solos the track by muting all other tracks [...]On soloing a track, the manual states that "By default, soloing a track simply mutes all other tracks"
Here's an image from a Soundtrap track, I have only added the two numbers:
The Ableton description still applies with the exception of Ableton deactivating the whole track and Soundtrap activating the track's mute, but conceptually this is nothing different. The Ableton wording changed would then be:
4 - To mute the track’s output, turn [on the Mute] switch. [...]
5 - Clicking the Solo switch [...] solos the track by muting all other tracks [...]As another example of how standard this behavior is, here's a screenshot from Studio One, where I have also added the numbers:
Again, the Ableton manual also holds true for this application. Even more so, Studio One works exactly like Soundtrap does.
As my final point: Soundtrap needs a button to clear the state of all tracks but must in any case keep the current solo/mute functionality.
-
Hi kvist, thx for your response. Before I reply I want to point out that I too am a software developer, albeit one who may have a particular perspective as I deal with end-users all the time. One thing I have learned from this is that when users are confused it's never their fault. It's a problem with the UI design. My original comments were based on the observation that all 20+ members of my choir are totally confused by the behaviour of the solo-mute button pairs, and no matter how many time I try to explain it using different words, they just don't get it. I am not surprised because it took me the better part of 1 day to figure out all of its little idiosyncracies (more on that later).
Now I have to admit that I had never used a DWR system before (and none of my 20+ choir members had) so I wasn't aware that the solo button was a standard pattern in that world. It could be that the problem is not so much the concept of solo buttons but the particularly idiosyncratic way in which SoundTrap implemented it.
A good test of whether something is intuitive or not is to think about how words, and how many ifs-and-buts you have to use to describe the behaviour. In the of the UI pattern that I am more familiar with (which Audacity uses) with a mute/unmute-all with mute/unmute-this, the behaviour can be described with 4 simple sentences:
A.1) Clicking on mute-all will mute all tracks
A.2) Clicking on unmute-all will un-mute all tracks
A.3) Clicking on a track's inactive (i.e. greyed out) mute button will mute that track
A.4) Clicking on a track's active (i.e. purple) mute button will un-mute that track
Note also that I can predict the effect that any of those button presses will have on all tracks, without having to know anything about the state of any of them (not even the state of the track for which i press the single mute/unmute button).
Compare this with the explanations I have to provide for Soundtrap's implementation of the solo + mute buttons.
B.1) Clicking on a grey solo button will turn that track on and turn off all other tracks, EXCEPT those tracks that are already soloed.
B.2) Clicking on a purple solo button will... well, it depends on whether other tracks are soloed or not. If other tracks are soloed, then it will mute that track and leave the other soloed tracks is solo mode (all non-soloed tracks will remain mute). If on the other hand, there are no other soloed tracks, it will un-mute all tracks. Actually, not quite... if a track T has been muted by clicking on its mute button before any tracks were soloed, then track T will remain muted even after we un-solo all tracks. Actually, even if you clicked on track T's purple mute button after some tracks were soloed, that track will remain muted after all soloed tracks have been un-soloed.
B.3) Clicking on a track's grey mute button will mute that track.
B.4) Clicking on a track's purple mute button will un-mute that track, UNLESS, there are tracks that are soloed. In such case, the track will remain on mute, AND that track will remain muted even after all soloed tracks are un-soloed (see B.2). This one is pretty hard to explain given that my intention in clicking on the purple mute button was probably to activate that track... but it actually achieved the opposite effect, i.e. making that track's muted status imune to being changed by un-soloing all tracks.
As you can see, I need to resort to a lot more words and a lot of except, but, unless, if words to explain SoundTrap's implementation. And none of my users are able to master i. Another problem is that when I click on a button, I can't know what efffect it will have on all tracks without knowing the state of all of them.
B.3 is the only case that doesn't require any knowledge of the status of other tracks.
For B.1, I cannot predict the effect without knowing if other tracks are soloed or not. And with 20+ tracks in my choir, it often happens that the soloed tracks are off-screen. Of course, I I see that all tracks on the screen are muted, I may guess that it's because some other, off-screen track is soloed. But I can't be sure. In fact, many of my choir members don't understand how to use the solo buttons so they manually mute a bunch of tracks (which then makes it look like some track must be soloed even though that's not the case).
Likewise for B.2, I can't predict the effect unless I know if the track I am about to un-solo is the only soloed tracks. Even if I am able to establish that the track is indeed the only soloed track, I can't be sure that all other tracks will be un-muted, because if a tracks mute button was clicked either before or after any of the tracks were muted, then it will remain muted even after the last soloed track is unsoloed.
For B.4 I again need to know whether there are soloed tracks or not.
-
BTW, I am not averse to the idea of a solo button but I think it's behaviour should be simple to explain. For example:
- Cicking on a track's grey solo button will turn all curently selected tracks on (including of course the one you clicked on), and turn off all other tracks.
- Clicking on a track's purple solo button will unsolo all tracks
This is simple to explain and you can predict the effect on all tracks without having to known anything about their current state, other than whether or not you group selected them (which is something that you probably know since group selection usually happens seconds before you do an action on the group).
-
From my understanding, the confusion isn't with what soloing is...it's with the signifiers (how you what's going on). I hope the following clarifies the problem/missing feature the OP and I noticed.
To match your fun graphics...notice how there is a difference in color between muted and unmuted tracks even when soloed. You can still functionally and visually toggle mute/unmute if something is soloed. Here, 4 is muted. It looks the same on or off. But 2 and 3 are now also grayed out, making the lit solo button more prominent.
In Logic and GarageBand, all the unengaged mute buttons FLASH when something is soloed. It indicates that somethings different about the mute button (it's overridden, everything is muted). But you can still mute or unmute a track.
In Soundtrap, take a guess as to what's going on in this picture:
The bottom track is actually muted, but the top is not. Either way, when I click on the mute buttons in this state, they actually are toggling, but I can't see that. The buttons seem like they're doing nothing. That seems confusing to me, never mind my students or first time users.
So my students click both to try and unmute them, then unsolo only to realize that now both the tracks are muted. Whaaaaatt? It's something you know to look for if you've used a DAW before, but for first timers and students it's not obvious. As a teacher I've gotten emails from confused parents because of another kid who soloed their own track before they hit save.
Point 1: It'd be nice to have a a good signifier for "something is soloed" instead of it looking the same as mute. A solo clear would also be handy.
The other mention in the OPs request was more about grouping together tracks. They want to be able to hear their group of 6 people and then hear everyone. They requested solo clear to double for that, but it seems like better ways to group tracks together would actually be more beneficial.
Now that I'm on a screenshot kick, might as well throw an image of Logic's Summing Stack:
This is an easy visual representation of a summing bus (as opposed to a send). In pro tools you have to hard route buses, but they do also have VCAs and Groups which are really powerful. Soundtrap seems to avoid routing for simplicity's sake, but I think that a little bit of grouping would go a long way. That comes with the power to freeze a whole bus rather than single tracks, put effects on a bus, and do crazy things that allow projects to get bigger and deeper.
Point 2: Track management / grouping would help big projects and expand possibilities.
Hope this makes sense!
-
Alternatively if some people are happy with the way that the Solo buttons currently work, I would be OK with just adding a mute/un-mute all button as per your suggestion.
I would then simply tell my choir members to never click on the Solo buttons and to only use themute/unmute-all and the individual mute buttons.
-
As I reflect on this, I think a choir setting makes it harder for people to get a feel for what the solo buttons do and how they interact with the mute buttons. In say, a rock band setting:
- You can see all tracks at once on the screen
- The different instruments are easy to distinguish by ear (because they are different musical instruments, playing parts that differ in some aspect)
So when you click on a solo or mute button, you can immediatly see and hear the effect it has on all tracks
But in a 20 people choir:
- Only a 3rd or so of tracks are visible at any time
- The different tracks are not easily distinguishable by ear (because they are all human voices, some of them signing the exact same part)
Here if you click on a solo or mute button, you can't tell the effect on all tracks without scrolling through all of them and visually inspecting their status.
The fact that we are using the tool for practicing also complicate things. When I enter a piece I want to practice and want to choose which tracks I want to hear, I have to first determine how the previous person muted some tracks (did she solo some tracks, or did she explicitely mute some tracks). This means I have to scroll through 3 screens worth of tracks looking for a possible purple solo button. If I see one I know I have to solo the tracks I want to hear and un-solo the tracks I don't want to hear. On the other hand, if I don't see a purple solo button, it means I have to un-mute all currently-muted tracks, and then solo the tracks I want to hear. As a software dev used to complex dependencies between things, I can remember how to do this. But "normal" people (which is all the folks in my choir) have trouble remembering that. It would be much simpler if I could tell them something like this:
- If you want to hear most of the tracks, then unmute all, and then mute tracks you don't want to hear
- If you want most tracks to be silent, then mute all and unmute those tracks you want to hear
This procedure would not depend on what the previous person did.
-
Earlier, I wrote that with mute/unmute-all I could use the following instructions to tell my choir members how to select the tracks they want to hear when practicing
- f you want to hear most of the tracks, then unmute all, and then mute tracks you don't want to hear
- If you want most tracks to be silent, then mute all and unmute those tracks you want to hear
Without those buttons, I find myself having to tell them something like this, which depends on two conditions:
To choose the tracks you want to hear when practicing,
- Scroll through all tracks and look for a purple solo button.
- - If you see a purple solo button, then
- -- If you want most tracks to be silent, solo the tracks you want to hear and un-solo the others
- -- If you want to hear most tracks, unsolo all tracks then mute those tracks you don't want to hear
- - If you DON'T see a purple solo button then
- -- If you want most tracks to be silent, solo those tracks you want to hear
- -- If you want to hear most tracks, mute those tracks you don't want to hear
-
Wow, a lot of stuff going on here. Please let me clear some things up. First of all, please don't get my answer wrong, I never meant to be rude, but I tend to catch on to bad wording when trying to explain things that seem obvious to me.
On the other hand, I never meant to contradict your points, and I absolutely support both of you guys with all your points. When I read the OP though, I partly interpreted it as "mute/solo itself makes no sense", so I only wanted to give some more context on the functionality.
Please note that I agreed with you on how you can't see if a track is explicitly vs. implicitly muted, which is an obvious flaw as stated in my original comment. This is what Jake's screenshot of Soundtrap was referring to. This could be solved by simply introducing different colors for the different muting states
Please also see my final point in my original comment, where I share your opinion on having a (un)mute/solo all, because I never wanted to say anything against that, only explain why and how solo/mute works .
In conclusion, I think, I need to apologize for my wording in my comment. I could've been a lot more polite there, but I hope you see how I wanted to shed some more light on the solo/mute as I want it to stay the way it is, but I ALSO want the buttons to globally control it. Track grouping would be even more awesome, of course.
-
@alaindesilets, I just saw that you wrote this:
"I would then simply tell my choir members to never click on the Solo buttons and to only use themute/unmute-all and the individual mute buttons." and wanted to have a quick comment on that.
I think this perfectly demonstrates why solo/mute coexist. Depending on how many tracks you want to hear, it is simply more efficient to use one over the other but, it doesn't make sense to use both at the same time. Please let me elaborate. You are already in a scenario where you have 20 different tracks and Soundtrap currently does not have the "mute all" functionality.
Person A wants to listen to only 4 of those tracks. If they were to only mute, they needed to mute a total of 16 individual tracks. Instead, they could simply solo the 4 and be fine.
Person B wants to listen to 16 tracks (for whatever reason), so the situation is reversed and the functionality used is as well, you'd of course mute only the 4 tracks you didn't need instead of soloing all 16.
If this contradicts, UX, please let me know as this absolutely isn't my topic.
In the end, every person changing those settings need to reset their changes, of course to avoid confusion with the next person.
This is where the reset functionality in the form of "(un)mute/(un)solo" you are wishing for is currently missing, so everybody could quickly reset everything at their convenience even if the person before forgot to do so.In your example you also state:
But in a 20 people choir:
- Only a 3rd or so of tracks are visible at any time
- The different tracks are not easily distinguishable by ear (because they are all human voices, some of them signing the exact same part)
Here if you click on a solo or mute button, you can't tell the effect on all tracks without scrolling through all of them and visually inspecting their status.
I think this isn't necessarily the case. Should the piece in fact be reset after a person is done with it, then the effect of clicking a solo or mute button is crystal clear, because then the button literally does what it does. Of course, this would again need the global reset buttons for it to be easy and other DAWs do actually have those buttons.
To sum it up: To use mute over solo is dependent on the result you want to achieve and you shouldn't use both at the same time, as it doesn't make sense anyway.
I'd also like to give an example on how I use the current functionality in my projects, I usually have a lot of tracks that contain template MIDI I want to copy-paste around my tracks and also use a different drum set for snare, kick, etc. in order to control the effects for each part better. This results in me also having a lot of different tracks, so I, too wish for track grouping.
For the time being, I organize them by using the same color for the same "register" (percussion is blue, lead instrumentation is red, harmonizing instrumentation green, for example. In a choir I guess this would be SATB each in a separate color with the name of the singer as the track name?) and drag & drop them so they are on top of each other.As for mute/solo:
My "copy-paste" tracks are always muted, unless I want to edit them. Also, if I want to disable a "normal" track temporarily, I mute it and unmute it after, because it's "normal" and thus needed for the song.
Should I want to isolate certain tracks or edit one of the "copy-pastes", it usually comes down to a single one up to only a few. Then, I solo those I need and don't mute any tracks while I am doing that and un-solo everything after I am done. From the UX point of view I'd assume this is great, because I don't even need any if's to decide what to do, it's simply "deactivate all the solo buttons".
The solo button is actually the more straightforward of both to explain. To put it in your words:
- Clicking on a track's grey solo button will add it to the "list" of solo'ed tracks, which are the only ones you hear
- Clicking on a track's purple solo button will remove it from that list
The above holds true at any time, no matter the state of any of the other tracks. You can even solo a muted track and it will behave as expected, adding that track to the "solo list" until you un-solo it again.
I think it's the mute button that's rather hard to explain in that case:
- Clicking on a grey mute button will mute the track
- Clicking on a purple mute button will
- Unmute it, unless any track is solo'ed
- Do nothing, if a track is solo'ed
- Most importantly: Not show you, which of both is the case. If this was changed, the complexity would be negligible
Besides from that, as stated, mute has no effect, when solo is used anywhere and simply should not be used when solo is in effect. Again, there is no reason to do so in the first place. On the other hand, solo always works as defined.
I hope this makes sense. Have a nice day, guys!
Please sign in to leave a comment.
Comments
10 comments