behaviour of mute and solo

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

behaviour of mute and solo

David Bailes-2
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
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

David Bailes-2
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
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

Gale
Administrator
David Bailes-2 wrote
On Tue, Mar 3, 2009 at 10:01 AM, David Bailes <drbailes@googlemail.com> wrote:
> 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?

David

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




Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

David Bailes-2
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
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

David Bailes-2
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
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

David Bailes-2
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
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

David Bailes-2
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
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

Gale
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




 
 
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

Stevethefiddle
Gale (Audacity Team) 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.   


  
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 
  


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?

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),
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?



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
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

David Bailes-2
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
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

David Bailes-2
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
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

Martyn Shaw-2
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
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

David Bailes-2
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
Reply | Threaded
Open this post in threaded view
|

Re: behaviour of mute and solo

Zach Elko
Hello Martyn and David,


On Tue, Mar 17, 2009 at 12:44 PM, David Bailes <[hidden email]> wrote:

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.


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