behaviour of mute and solo
Locked
 
|
Hi,
way back in 1.3.4: - a track couldn't be both mute and solo - there couldn't be more than one track that was solo - if a track was set to solo, then the others were set to mute from 1.3.5 onwards: - a track can be mute and solo - more than one track can be solo - if a track is set to solo, then in the other tracks the audio waveform is greyed out, but the mute buttons aren't updated and so users of screen readers can tell if they're muted. Are these changes by design or accident? I find the new behaviour confusing. David. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: behaviour of mute and solo
|
|
Hi,
On Tue, Mar 3, 2009 at 10:01 AM, David Bailes <[hidden email]> wrote: > Hi, > > way back in 1.3.4: > - a track couldn't be both mute and solo > - there couldn't be more than one track that was solo > - if a track was set to solo, then the others were set to mute > > from 1.3.5 onwards: > - a track can be mute and solo > - more than one track can be solo > - if a track is set to solo, then in the other tracks the audio > waveform is greyed out, but the mute buttons aren't updated and so > users of screen readers can tell if they're muted. just realised that it's reverted to 1.3.3 behaviour. Is this on purpose? thanks, David. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|
Administrator
|
All this was the subject of heated debate at the time of 1.3.5. The 1.3.5 behaviour is basically like hardware mixer behaviour, 1.3.4 is like a consumer tape deck or similar. CVS has not changed back to 1.3.4 behaviour. To accommodate the different mute/solo user requirements, we made it a Preference: http://www.audacityteam.org/manual/index.php?title=Interface_Preferences#Other_interface_choices Default behaviour is called "Standard" and is the hardware mixer behaviour, but you can choose "Simple" to be like the tape deck, or "None" to have no solo buttons at all. I'd have preferred "Simple" was default, but most votes went the other way. Gale |
Re: behaviour of mute and solo
|
|
Hi Gale,
On Wed, Mar 4, 2009 at 9:20 AM, Gale (Audacity Team) <[hidden email]> wrote: > > All this was the subject of heated debate at the time of 1.3.5. The 1.3.5 > behaviour is basically like hardware mixer behaviour, 1.3.4 is like a > consumer tape deck or similar. CVS has not changed back to 1.3.4 > behaviour. To accommodate the different mute/solo user requirements, > we made it a Preference: > http://www.audacityteam.org/manual/index.php?title=Interface_Preferences#Other_interface_choices > > Default behaviour is called "Standard" and is the hardware mixer behaviour, > but you can choose "Simple" to be like the tape deck, or "None" to have > no solo buttons at all. I'd have preferred "Simple" was default, but most > votes went the other way. thanks for the infomation, I think I vaguely remember the discussion, David. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: behaviour of mute and solo
|
|
In reply to this post by Gale
Hi,
On Wed, Mar 4, 2009 at 9:20 AM, Gale (Audacity Team) <[hidden email]> wrote: > > > Default behaviour is called "Standard" and is the hardware mixer behaviour, > but you can choose "Simple" to be like the tape deck, or "None" to have > no solo buttons at all. I'd have preferred "Simple" was default, but most > votes went the other way. I suspect that now that there are the keystrokes ctrl+u, and ctrl+shift+u for muting and unmuting all respectively, vi users may find it easier just to use the mute controls rather than the solo ones as well. However, if the solo behaviour is set to simple, the ctrl+u and ctrl+shift+u don't seem to interact with the buttons correctly. If you start with one track set to solo, and the others set to mute, then: - I think that if you press ctrl+u, then the track set to solo should be set to mute, and the solo setting removing. In fact the solo setting remains, and the track contributes to playback. - I think that if you press ctrl+shift+u, then the track set to solo should have the solo setting removed, and the other tracks should be unmuted. In fact the solo setting remains, and it's the only track that contibutes to playback. (If there were only one track and it were set to solo, then pressing ctrl+shift+u should have no effect) Currently the option of shift+clicking the solo buttons isn't available via the keyboard, but it's probably not a big issue. With the solo set to simple mode, then shift clicking solo ends up with some "illegal" states where tracks are both mute and solo, and what happens when you press mute and solo buttons subsequently can be unintuitive, and probably not immediately obvious if you can't see the screen. David. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: behaviour of mute and solo
|
|
Hi,
with solo button set to standard behaviour, then the solo buttons don't seem to affect exported audio, but the mute buttons do. Is this intended? David. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: behaviour of mute and solo
|
|
Hi,
this is just a repeat of some unanswered questions. I appriciate that people are busy fixing stuff at the moment. With solo button set to standard behaviour, then the solo buttons don't seem to affect exported audio, but the mute buttons do. Is this intended? If the solo button behaviour is set to simple, then ctrl+u and ctrl+shift+u don't seem to interact with the buttons correctly. If you start with one track set to solo, and the others set to mute, then: - I think that if you press ctrl+u, then the track set to solo should be set to mute, and the solo setting removing. In fact the solo setting remains, and the track contributes to playback. - I think that if you press ctrl+shift+u, then the track set to solo should have the solo setting removed, and the other tracks should be unmuted. In fact the solo setting remains, and it's the only track that contibutes to playback. (If there were only one track and it were set to solo, then pressing ctrl+shift+u should have no effect) thanks, David. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|
Administrator
|
In reply to this post by David Bailes-2
Hi David
David Bailes wrote: > with solo button set to standard behaviour, then the solo buttons > don't seem to affect exported audio, but the mute buttons do. Is this > intended? Yes and that's true for all solo behaviours. If the solo button determined export then with the solo preference set to "Simple" there would be no way to export multiple tracks (except by shift-click on the solo buttons), and with it set to "None" there would be no way at all to kill export of a track using a track panel button. >I suspect that now that there are the keystrokes ctrl+u, and >ctrl+shift+u for muting and unmuting all respectively, vi users may >find it easier just to use the mute controls rather than the solo ones >as well. > >However, if the solo behaviour is set to simple, the ctrl+u and >ctrl+shift+u don't seem to interact with the buttons correctly. If you >start with one track set to solo, and the others set to mute, then: >- I think that if you press ctrl+u, then the track set to solo should >be set to mute, and the solo setting removing. In fact the solo >setting remains, and the track contributes to playback. >- I think that if you press ctrl+shift+u, then the track set to solo >should have the solo setting removed, and the other tracks should be >unmuted. In fact the solo setting remains, and it's the only track >that contibutes to playback. (If there were only one track and it were >set to solo, then pressing ctrl+shift+u should have no effect) > >Currently the option of shift+clicking the solo buttons isn't >available via the keyboard, but it's probably not a big issue. With >the solo set to simple mode, then shift clicking solo ends up with >some "illegal" states where tracks are both mute and solo, and what >happens when you press mute and solo buttons subsequently can be >unintuitive, and probably not immediately obvious if you can't see the >screen. Though I follow your reasoning, my view on balance is it's better the mute/unmute all command does exactly what it says and no more, even though in Simple mode it can set up an "illegal" combination, or give an unintuitive playback result. Illegal combinations can also arise by changing from Standard to Simple mode, or by duplicating tracks. Think of the Mute/Unmute All commands as a potentially quicker way than individual mute buttons to control which tracks are exported from a large project, rather than controlling which get heard. The trick is often figuring the best route using the buttons to get the playback result you want. For example, if you're in Simple mode with three tracks muted and one solo but you want to hear all, you might think you need to unmute three tracks, but in fact you just need to unsolo the soloed one. I agree this could be confusing for VI users who cannot see what they are doing and there might be a case for Solo/Unsolo All menu items that essentially give a quick way to control playback (and also set up illegal combinations in Simple mode). Any comments? Gale |
Re: behaviour of mute and solo
|
|
Hi David David Bailes wrote: Just thinking about the manual / explanations to new users on the help forum - which of the following is easier to understand, and which is more useful for the user: 1) Ctrl+U mutes all tracks. Ctrl+SHIFT+U unmutes all tracks. A track can not be set to solo and mute at the same time. Muted tracks will not play back and will not be included in any export. When one or more tracks are set to solo, only the soloed tracks will play, and only the soloed tracks will be included in an Export. 2) Ctrl+U mutes all tracks, but those that were previously set to solo remain set to solo as well as being muted and will play. When in the solo behaviour is set to "Standard" in Preferences (Ctrl+P > Interface tab) to mute a track you must click on "Mute" and if the track was previously set to "Solo" then you must also click on the "Solo" button to deselect solo mode for that track. The same applies to when using Ctrl+U. When in the solo behaviour is set to "Simple" Ctrl+U and Ctrl+SHIFT+U only affect the status of the "Mute" buttons and again, if a track is also set to solo it will play back, but it will not (will/will not?) be included in any Export. And here comes the help forum question: "I have the solo behaviour set to "Simple" in Audacity's Preferences. I have 16 audio tracks and I muted some of them. I then wanted to listen to just a few tracks, so I used SHIFT+Click on the solo button. How do I unmute just one of the muted tracks?" It would be nice to be able to reply "SHIFT+Click on the mute button", but unfortunately that is not the case. In fact, is there any way of doing this? Could the user not just choose between shift-click on solo buttons, or shift-click on mute buttons, (whichever requires the lesser clicks) and only those tracks that play are included in the export?Gale (Audacity Team) wrote: If the solo button determined export then with the solo preference set to "Simple" there would be no way to export multiple tracks (except by shift-click on the solo buttons), My vote goes for: If the user chooses to "mute all tracks", then it should "mute all tracks" (On Ctrl+U all tracks are muted and any soloed tracks become un-soloed). It is easier to explain, it is (in my opinion) more logical, it is better for VI users and it avoids "illegal" combinations. (It also means that in "Standard" mode, multiple tracks can be quickly "un-soloed" by pressing Ctrl+U followed by Ctrl+SHIFT+U). Steve ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: behaviour of mute and solo
|
|
In reply to this post by Gale
Hi Gale,
On Sun, Mar 15, 2009 at 2:31 AM, Gale (Audacity Team) <[hidden email]> wrote: > > Hi David > > David Bailes wrote: > >> with solo button set to standard behaviour, then the solo buttons >> don't seem to affect exported audio, but the mute buttons do. Is this >> intended? > > Yes and that's true for all solo behaviours. If the solo button determined > export then with the solo preference set to "Simple" there would be no > way to export multiple tracks (except by shift-click on the solo buttons), > and with it set to "None" there would be no way at all to kill export of a > track using a track panel button. Currently: Playback is affected by both mute and solo, and any solo settings override all mute settings. Export is only affect by mute. So, if I have two tracks, with the first set to mute and solo, and second with no mute or solo settings, then playback consists of track 1, and export consists of track 2. I think this might be confusing. I'm not suggesting that solo alone determines export. I'm suggesting that it would be less confusing if either export were affected by solo and mute in the same way as playback is, or that export were unaffected by both mute and solo. >>However, if the solo behaviour is set to simple, the ctrl+u and >>ctrl+shift+u don't seem to interact with the buttons correctly. If you >>start with one track set to solo, and the others set to mute, then: >>- I think that if you press ctrl+u, then the track set to solo should >>be set to mute, and the solo setting removing. In fact the solo >>setting remains, and the track contributes to playback. >>- I think that if you press ctrl+shift+u, then the track set to solo >>should have the solo setting removed, and the other tracks should be >>unmuted. In fact the solo setting remains, and it's the only track >>that contibutes to playback. (If there were only one track and it were >>set to solo, then pressing ctrl+shift+u should have no effect) >> >>Currently the option of shift+clicking the solo buttons isn't >>available via the keyboard, but it's probably not a big issue. With >>the solo set to simple mode, then shift clicking solo ends up with >>some "illegal" states where tracks are both mute and solo, and what >>happens when you press mute and solo buttons subsequently can be >>unintuitive, and probably not immediately obvious if you can't see the >>screen. > > Though I follow your reasoning, my view on balance is it's better the > mute/unmute all command does exactly what it says and no more, In the above example, if I press the mute button on the track set to solo, then mute is set to on and solo is set to off. But this doesn't happen if I press ctrl+u. So I don't think that the command does exactly what it says. > Think of the Mute/Unmute All commands as a potentially quicker way > than individual mute buttons to control which tracks are exported from a > large project, rather than controlling which get heard. So if you use individual mute buttons, then playback and export are the same, but if you also use ctrl+u or ctrl+shift+u they aren't? > I agree this could be confusing for VI users who cannot see what they > are doing I think it's confusing for everyone. >and there might be a case for Solo/Unsolo All menu items to be able to unsolo all items might be useful. David. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: behaviour of mute and solo
|
|
In reply to this post by Stevethefiddle
Hi Steve,
On Sun, Mar 15, 2009 at 11:28 AM, Steve the Fiddle <[hidden email]> wrote: > > Just thinking about the manual / explanations to new users on the help forum > - which of the following is easier to understand, and which is more useful > for the user: My initial comments arose out of trying to describe the current behaviour whilst updating my jaws guide to audacity. > > 1) Ctrl+U mutes all tracks. Ctrl+SHIFT+U unmutes all tracks. > A track can not be set to solo and mute at the same time. > Muted tracks will not play back and will not be included in any export. > When one or more tracks are set to solo, only the soloed tracks will play, > and only the soloed tracks will be included in an Export. In solo button simple mode, then a track should not be solo and mute at the same time, but in standard mode it can - that's the desired functionality of the standard mode. Otherwise I agree. > > 2) Ctrl+U mutes all tracks, but those that were previously set to solo > remain set to solo as well as being muted and will play. When in the solo > behaviour is set to "Standard" in Preferences (Ctrl+P > Interface tab) to > mute a track you must click on "Mute" and if the track was previously set to > "Solo" then you must also click on the "Solo" button to deselect solo mode > for that track. Again, in solo standard mode, that's ok. The same applies to when using Ctrl+U. When in the solo > behaviour is set to "Simple" Ctrl+U and Ctrl+SHIFT+U only affect the status > of the "Mute" buttons and again, if a track is also set to solo it will > play back, but it will not (will/will not?) be included in any Export. It's confusing. > My vote goes for: > If the user chooses to "mute all tracks", then it should "mute all tracks" > (On Ctrl+U all tracks are muted and any soloed tracks become un-soloed). > It is easier to explain, it is (in my opinion) more logical, it is better > for VI users and it avoids "illegal" combinations. (It also means that in > "Standard" mode, multiple tracks can be quickly "un-soloed" by pressing > Ctrl+U followed by Ctrl+SHIFT+U). Again, in solo standard mode having tracks both mute and solo is fine, but having a command to unsolo all tracks might be useful for vi users, David. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|
|
In reply to this post by David Bailes-2
I haven't read this thread in detail and tried all the suggestions,
but thought I'd contribute anyway... David Bailes wrote: ... > Currently: > Playback is affected by both mute and solo, and any solo settings > override all mute settings. > Export is only affect by mute. Good! > So, if I have two tracks, with the first set to mute and solo, and > second with no mute or solo settings, > then playback consists of track 1, and export consists of track 2. I > think this might be confusing. Solo and mute are conventions from 'old fashioned' mixing desks, and work very well if you understand the concept. Using any 'solo' switches to a special 'engineers' output, just to listen to a track (or possibly several tracks) for a short time to check noise, EQ etc, then turning it/them off again. On an 'old fashioned' mixing desk a light normally appears if anything is soloed anywhere on the desk, as a warning that you aren't listening to the 'normal' output. The 'normal' output still appear at the tape recorder (or whatever, Export in our case). 'Mute' is used to turn off the track from the main output, maybe because that track was just a backup. You may still want to solo it to see if it is better than the one you are using. So yes, mute should affect the export. Solo shouldn't but should affect what you hear (and I deliberately didn't use the word 'playback' here). Since this has been discussed several times, and at some length, there is obviously a conceptual problem and faults in our interface. 1) We don't have an overall 'solo' light / indicator (which we really should) 2) We allow export of something that is different to what a user is hearing (which is debatable, but probably not good for people who haven't got to grips with the purpose of 'solo' (like, most people)). So I propose that we fix the above 2 items. Maybe a big red line around the 'Control Toolbar' and grey out the 'Export' options when anything is soloed? How do we make those audibly accessible, without upsetting the audio? Just some thoughts Martyn PS I agree with Gale that a command to unsolo-all would be useful, even on an 'old fashioned' mixing desk. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
Re: behaviour of mute and solo
|
|
Hi Martyn,
On Tue, Mar 17, 2009 at 1:21 AM, Martyn Shaw <[hidden email]> wrote: > > So yes, mute should affect the export. Solo shouldn't but should > affect what you hear (and I deliberately didn't use the word > 'playback' here). thanks for explaining whats intended. > > Since this has been discussed several times, and at some length, there > is obviously a conceptual problem and faults in our interface. I probably wasn't paying attention, but as you point out it isn't intuitive from the interface. > 1) We don't have an overall 'solo' light / indicator (which we really > should) > 2) We allow export of something that is different to what a user is > hearing (which is debatable, but probably not good for people who > haven't got to grips with the purpose of 'solo' (like, most people)). > > So I propose that we fix the above 2 items. Maybe a big red line > around the 'Control Toolbar' and grey out the 'Export' options when > anything is soloed? How do we make those audibly accessible, without > upsetting the audio? would it be intuitive why the export was greyed out? I'm not sure about how to make this obvious to visually impaired users other than through documentation. I'll wait and see whether your proposal is supported by others on the list, or whether there are any alternative suggestions. If you have a few more brain cycles spare, any thoughts about the current behaviour with the solo button in simple mode: If you just click the solo and mute buttons with a mouse, or use ctrl+u and ctrl+s, then: 1. a track can't have mute and solo set. 2. If a track is solo, then all the others are mute. The result of this is that what you hear during playback is the same as what is exported. So this solo mode does appear to be simple. However, mute and unmute all, and shift clicking solo currently put an end to the simplicity - tracks can end up with both mute and solo set, and a single track can be set to solo with non of the rest set to mute. If think it would be easier to understand if mute all and unmute all interacted with any solo tracks in the same way as if you went through the tracks individually muting or unmuting them. Also if you shift + solo a track then it should be set to solo, and the mute removed. David. It really is simple. However, using ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|
|
Hello Martyn and David,
On Tue, Mar 17, 2009 at 12:44 PM, David Bailes <[hidden email]> wrote:
I agree here. Solo should behave the same regardless of the method. It isn't so much a matter of simplicity, but in my opinion a matter of "how it should work". I think we can all agree that having a solo track muted makes no sense, and that having a track solo while others are not muted makes equally less sense. Just my two cents. Cheers, Zach J. Elko ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ audacity-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/audacity-devel |
«
Return to audacity-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |