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

Audacity Bugzilla



Bug 1348 - Inconsistent behavior of analyzers, and undo errors
Inconsistent behavior of analyzers, and undo errors
Status: RESOLVED FIXED
Product: Audacity
Classification: Unclassified
Component: VAMP
unspecified
Per OS Other
: P4 RepeatableAll
Assigned To: Default Assignee for New Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-27 13:43 UTC by Paul L
Modified: 2018-08-20 11:45 UTC (History)
6 users (show)

See Also:
Steps To Reproduce:
1. Create a long click track (I used max beats/minute and 500 beats), long enough to get a Cancel progress button in steps below. Amplify so it clips. 2. Duplicate it and align tracks end-to-end. 3. Create a label track between the two. 4. Try Sound Finder (a Nyquist analyzer), observe the effects of repeated completion and of cancelling, and undo/redo after either. -- Uses the existing track if it is part of the selection; else only one new label track is made, with default name -- Undo and Redo behave correctly -- It is possible to cancel progress but get partial results; these do undo correctly 5. Same with Find Clipping, parameters 1, 1 -- Only one track holds results, and it is called "Clipping" -- Partial results display before the progress completes -- If a label track is already named "Clipping," uses that, whether or not it is selected. Else creates a new one -- If you cancel, a preexisting label track called "Clipping" moves to the end of track list, no new undo item, and undo then redo restores it to its place -- The code also has wxT("Clipping") not _("Clipping") -- not translated 6. Same with a VAMP analyzer, such as Temnpo (it's very slow, I suggest just 50 beats in each track) -- One new label track is created for each chosen wave track, and they are placed after all tracks, regardless whether existing label track is selected -- Progress bar fills twice, with long periods of unresponsiveness -- If you cancel, one or more new label tracks are not removed, and there is no new undo item See comment 3 for partial fix of the above.
Release Note:
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 Paul L 2016-02-27 13:43:31 UTC

    
Comment 1 Paul L 2016-02-27 13:44:17 UTC
I downloaded from https://github.com/bbcrd/bbc-vamp-plugins/releases and used the Tempo analyzer.
Comment 2 Paul L 2016-02-27 14:12:20 UTC
The description is rather long.  I am working on a fix for the undo strangeness.  Apart from that I don't know yet what we agree should be correct behavior.
Comment 3 Paul L 2016-02-27 18:14:06 UTC
Partial fix here, addressing undo/redo behavior, but not the other inconsistencies.  No change to Nyquist analyzers.

https://github.com/audacity/audacity/commit/0094c4f465e30be85dd6abde5e8c94d5887b5775
Comment 4 Peter Sampson 2018-01-18 05:48:52 UTC
(In reply to Paul L from comment #3)
I have spent some time testing these three use cases on W10 and macOS 10.12.3 with the latest 17Jan 2.2.2 alphas.

I will report on each use case separately in this bug thread - but broadly I see behaviors that I expect (including Undos and Cancels) with the exception of the Nyquist Analyzers which can/do corrupt existing label tracks (but that is a separate issue that I will log as a new bug P3 as it should be Release Noted imo).

I am minded to close this bug 1348 off in favour of the new bug I will create.
Comment 5 Peter Sampson 2018-01-18 05:54:12 UTC
Use Case 1

1. Create a long click track (I used max beats/minute and 500 beats), long enough to get a Cancel progress button in steps below.  Amplify so it clips.
2. Duplicate it and align tracks end-to-end.
3. Create a label track between the two.

I needed a much longer Rhythm Track to get it to take long enough to deployt the Cancel.

4. Try Sound Finder (a Nyquist analyzer), observe the effects of repeated completion and of cancelling, and undo/redo after either.
-- Uses the existing track if it is part of the selection; 

Yes - and I think this is incorrect/bad behavior as it corrupts the existing label track (this is what I shall be logging separately)

else only one new label track is made, with default name

Yes, but an id such as "Sound" would be better - this is common to all Nyquist analyzers and will form part of the new bug I shall create.

-- Undo and Redo behave correctly

Confirmed - and correct behavior

-- It is possible to cancel progress but get partial results; these do undo correctly

Confirmed - and correct behavior
Comment 6 Peter Sampson 2018-01-18 05:57:55 UTC
Use Case 2


5. Same with Find Clipping, parameters 1, 1
-- Only one track holds results, and it is called "Clipping"

Yes, and this is an improvement over current Nyquist analyzer behaviors

-- Partial results display before the progress completes

Yes, not ideal - but I can live with that

-- If a label track is already named "Clipping," uses that, whether or not it is selected.  Else creates a new one

Confirmed 

-- If you cancel, a preexisting label track called "Clipping" moves to the end of track list, no new undo item, and undo then redo restores it to its place

I don't see this (on the alphas)

-- The code also has wxT("Clipping") not _("Clipping") -- not translated

I can't comment on this
Comment 7 Peter Sampson 2018-01-18 06:04:26 UTC
Use Case 3

I can only test this on Mac as the 1.7.1 QM Vamp plug-ins crash Audacity when you try to enable them (logged as Bug #1244).


6. Same with a VAMP analyzer, such as Temnpo (it's very slow, I suggest just 50 beats in each track)

I did not find this slow on my 256 SSD Macbook Pro

-- One new label track is created for each chosen wave track, and they are placed after all tracks, regardless whether existing label track is selected

Confirmed - and acceptable behavior.  Good behavior indeed as it does not corrupt any existing label track.

-- Progress bar fills twice, with long periods of unresponsiveness

Confirmed - but no long periods of responsiveness on my fast SSD Macbook.

-- If you cancel, one or more new label tracks are not removed, and there is no new undo item.

No - both were properly removed.
Comment 8 Peter Sampson 2018-01-18 06:07:57 UTC
Analyzing those test results I see the following residuals that are the only thing preventing the closure of this bug:

Both in Find Clipping:

1) Partial results display before the progress completes 
This just looks odd but we could live with it.

2)The code also has wxT("Clipping") not _("Clipping") -- not translated



Plus of course the separate new bug that I shall raise for the Nyquist analyzers.
Comment 9 Peter Sampson 2018-01-18 07:05:44 UTC
(In reply to Peter Sampson from comment #8)
> ... the separate new bug that I shall raise for the Nyquist analyzers.

Logged as P3 Bug #1827 "Nyquist Analyzers can corrupt an existing label track when selected"
Comment 10 Peter Sampson 2018-04-08 09:28:19 UTC
As I wrote in Comment #4
>I am minded to close this bug 1348 off in favour of the new bug I will create.

Bug #1827 was logged

I am now going to act on that and close this off