From: Gale Andrews <firstname.lastname@example.org>
Sent: Friday, August 24, 2012 11:18 AM
Subject: Re: [Audacity-quality] Mute and Solo priority.
Summary: I'm mildly supporting the idea of Mute turning
off both playback and export.
If no consensus to do that, and though I only see it as P3/P4,
I think we should make it easier to realise when "what you hear
is not what you export". Some kind of button-with-light that lets
you toggle the playback and export mix, coupled with text in
the export dialogue listing tracks that won't be exported, is my
personal suggestion at the moment.
I'm also raising the question if we could remove the Solo button
preference and the SHIFT-click on Solo that hardly anyone knows
about, and have a second Solo button instead.
| From Steve the Fiddle <email@example.com
| To Gale Andrews <firstname.lastname@example.org
| Subject [Audacity-quality] Mute and Solo priority.
> On 29 July 2012 23:05, Gale Andrews <email@example.com
> > Anyway the suggestion was that button interactions don't change.
> > When considering what tracks to exclude from export, we exclude
> > those that have greyed waveform and disregard Mute button state
> > in that decision.
> So that IS "Solo takes priority over mute for both playback and exporting"?
Yes - what we would change is what determines whether the tracks
But I'm falling out of favour with this idea. It seems unlikely to be
backed, and I feel that muting to kill
the export is more intuitive
than soloing to do so, even for people who know nothing about
So that would leave:
A "Mute has priority for both playback and exporting."
If the Mute button on one or more tracks is depressed, the muted
tracks will not play regardless of whether the Solo button is pressed
or not. Muted tracks will not be exported. You state this is the
default behaviour in Ardour and the usual behaviour on hardware
B As above, but the Mute / Solo buttons on any given track are
interdependent, but as with all the suggestions, you can still solo
I would go with the B in preference as I think it would be better for
novice users who don't find the solo button preference. But if there
was enough consensus for A, I would go with A instead.
What if there is no consensus to change
how the buttons operate?
> > On 30 July 2012 00:45, Steve the Fiddle <firstname.lastname@example.org
> > Thanks for the link to the audacity-devel discussion Gale.
> > http://tinyurl.com/c4euefo
> > Very interesting, and (although much too late now) I agree with your
> > argument that the "Simple" behaviour would have been a better default.
> > The problem raised on the forum lies with the fact that Export has a
> > different mix to the one that is heard.
> > There is nothing in the -devel discussion to suggest why that might be
> > a good idea. Personally I would go as far as to say that it is a very
> > bad idea and an unintended consequence of trying to get the playback
> > behaviour right.
> > I think
that we are considering an important detail that has been overlooked.
> OK, so it hasn't been overlooked. It has been discussed already:
> Martyn is strongly in favour of the current behaviour.
> I strongly disagree :=)
> However Martyn does acknowledge:
> is obviously a conceptual problem and faults in our interface.
> 1) We don't have an overall 'solo' light / indicator (which we really
> 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?"
> I think that it is clear that the current situation is unsatisfactory.
It doesn't come up that often. The thing that I don't like though is
that even if you understood that mute affected export, you could still
fail to notice the mute, and not realise your mistake until next you
time brought in the exported file.
Also given Mute currently turns off export, it seems more sensible to
me for any such "light" indication to be on when a mute button is
depressed, not when a Solo button is depressed, which people can
both see and hear the result of. I appreciate a "solo" light might
mean something to people familiar with mixers, but we are trying
to make it easier for people who are not familiar. I believe almost
everyone understands that soloing a track does not mean only
that track will export.
A possibly more
useful feature-cum-indication might be a button
somewhere to toggle hearing of the playback and export mixes. The
"Export Mix" button would light up only when a mute button was
pressed. But I think it would have to default to "Playback Mix"
(or people wouldn't figure why the track was blue but inaudible).
So I still doubt that or other such indications would warn novice
users sufficiently. Plus, VI users need some other way of being
presented with this indication.
So I think there should at least be some coloured dynamic text
somewhere in the export dialogue "Track numbers <n> muted
from export". This assumes screen readers would read the text.
Also I dislike the hard to discover and accessibility-unfriendly
SHIFT-click to change Solo button behaviour on the fly. If I want
to do a one-press A/B comparison in Standard Solo Button
Mode, I have to Mute and Solo "A" to hear "A" solo, then
"A" to hear "B" solo. Far too complex, and SHIFT-click on Solo is
uncomfortable. And if I switch to "Simple" mode, but want to solo
two tracks, I again I have to SHIFT-click on Solo, or use the
"reverse logic" of no Solo button.
So could we make two "Solo" buttons work somehow? The first
Solo button behaves as "Standard" Mode. The second behaves
as "Simple" mode, making only that track play. Then get rid of
the Preference. My guess is that few people turn on "Simple"
except they want A/B comparison, and even fewer turn "None"
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
Audacity-quality mailing listAudacityemail@example.com://lists.sourceforge.net/lists/listinfo/audacity-quality