Audacity Bug Summary
••• Introduction •••
••• Keywords •••
    Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla



Bug 36 - Summary: Mixer Board release-noted issues
Summary: Mixer Board release-noted issues
Status: RESOLVED FIXED
Product: Audacity
Classification: Unclassified
Component: Application Core
2.0.1
Per OS All
: P3 Summary
Assigned To: Default Assignee for New Bugs
:
Depends on: 509 735
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-28 12:30 UTC by James Crook
Modified: 2018-08-20 11:51 UTC (History)
5 users (show)

See Also:
Steps To Reproduce:
See separate bugs
Release Note:
GROUP:Mixer Board * (Linux) Meters may not respond immediately to playback which could cause them to report incorrect peak level or not display clipping.
First Git SHA:
Group: ---
Workaround:
Closed: 2018-08-20 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Crook 2010-01-28 12:30:40 UTC
*  GA:
    * Meter range does not reflect a change in the dB range meter preferences until restart
Comment 1 Paul L 2016-01-19 15:04:37 UTC
The third bullet point of four, fixed in my fork:

https://github.com/Paul-Licameli/audacity/commit/6252cd27f03a1ef33a18e650d822c051c7e5e1fb

I cannot reproduce the other three problems.
Comment 3 Paul L 2016-01-23 10:25:46 UTC
Peter, I see you changed Release Note, just to say "Multi-track" instead of the old term "standard."

Lately though I fixed the third bullet point in 2.1.3.

Is Bugzilla intended to contain correct release notes for 2.1.2 or only the notes for the future release?
Comment 4 Paul L 2016-01-23 10:55:58 UTC
I just observed this:

In multi-track (formerly "standard") mode, shift-click on the Mixer board's Solo buttons behaves no differently from click.  That is unlike the track control buttons.  But in Simple mode, mixer board does respond to the shift key.

Mixer board should instead respond consistently with the track panel to shift-click, in either mode.
Comment 5 Paul L 2017-06-24 14:07:35 UTC
Part of this release note was just removed by Gale, because James reported that 735 does not reproduce.

Are you, James, now examining the other linked bugs?
Comment 6 James Crook 2017-06-24 15:01:18 UTC
Re: Comment #5:
Best asked (and answered) on quality email list.  The quick answer is 'no'.
Comment 7 James Crook 2017-06-24 17:43:55 UTC
From release notes:
* If you change the meter range in Preferences this is not reflected in the Mixer Board meters until restart.

Believed fixed by the fix for 745.

* '''Soloing or unsoloing a track in Mixer Board when in "Multi-track" Solo button mode''' may not immediately update the Solo button or waveform greyed/ungreyed state in the project window. 

Believed fixed by the fix for 509.
Comment 8 James Crook 2017-06-26 09:26:11 UTC
I removed this from the release notes:
'* If you change the meter range in Preferences this is not reflected in the Mixer Board meters until restart.'

My testing on Windows indicates it is now fine.  I believe I accidentally fixed it by this commit, which causes MixerBoard to be recreated on closing preferences.

https://github.com/audacity/audacity/commit/86901a00a1aa08051c6c19a5da20aa3fce3b3ccc

See the comment on the commit, and the new function RecreateMixerBoard().
Comment 9 Peter Sampson 2017-08-05 11:59:58 UTC
I will be testing this on Mac and Windows - as James' Comment #8 indicates this may no longer be an issue
Comment 10 Peter Sampson 2017-08-10 04:16:30 UTC
(In reply to James Crook from comment #8)
>Meter range does not reflect a change in the dB range meter preferences until restart

This now tests ok on both the latest Windows andMac nightlies
Comment 11 James Crook 2017-08-10 06:37:36 UTC
RESOLVED FIXED

This was a summary bug for Mixer board issues.

However, it only has one live issue left in it, which is Bug 289.  There is no active onward development of Mixer Board, so we no longer need a summary bug for Mixer Board.  Bug 289 on its own will do fine.  I took Bug 289 out of the dependencies and moved it to 'see also'.

Peter's comment #10 indicates that the issue fixed in the commit for comment #8 has now been tested OK.