Bugzilla – Bug 177
Unwanted label appears if pasting audio when there are already labels
Last modified: 2018-08-20 11:46:02 UTC
Also if you select in the label track and paste there, the paste into the waveform is correct and no unwanted label is created, but the following labels don't move. Is this is what we want (an on-the-fly way of pasting without moving the labels)? **No release notes if linking is not enabled**
Demoting to P3 as linking is disabled.
If the intention is still to enable the current (reworked/much better) linking for 1.3.13 or 1.3.14 and to include it in 2.0 (which was my understanding), then it is not safe to demote this, as it will be forgotten. Reverted to P2 until definite intention to leave linking out of 2.0 is confirmed.
This is probably related to bug 177. Steps to reproduce: 1) open an audio file (or create some audio) 2) add a label somewhere -- just to create a label track 3) start playing the audio 4) press the keyboard shortcut to "stop here" (SHIFT +a) Result: Playback does indeed stop "here" but a spurious label is created with a capital A as the text; the label has focus.
I see this more as to do with Bug 30 (which should be fixed for "most" intents and purposes though badly needs QA testing on Mac). I'll copy this comment there. Basically there is a conflict between being able to "just type" when the label track has focus, yet use convenient shortcuts at the same time.
(In reply to comment #4) (In reply to comment #9) From bug 30, Gale says "(doesn't depend on linking being enabled/turned on)" but in fact this is 100% dependable on // feature to link audio tracks to a label track #define EXPERIMENTAL_LINKING If I comment out this #define the problem never occurs. With experimental linking on the problem is 100% repeatable in Unicode Release and 75% in Unicode Debug (although previous label position, current play cursor location and size of audio may all come into play). The specific steps to reproduce are: 0) set keyboard shortcut for "play/stop and Set Cursor" to <SHIFT+a> 1) create audio a) generate 30 seconds of "brown noise" works fine 2) add a label (a blank label is more likely to trigger in debug build)--make sure to press <ENTER> to close label text editing but leave focus on label track. 3) use the TOOLBAR to start playing (from current label position) 4) key <SHIFT+a> to "stop here" results in a playback "stopping here" and a spurious label with "A" already entered and the text in edit mode. Here is a Stack Trace: > Audacity.exe!LabelTrack::OnChar(double & newSel0=15.120393589763864, double & newSel1=15.120393589763864, wxKeyEvent & event={...}) Line 1902 C++ Audacity.exe!TrackPanel::OnChar(wxKeyEvent & event={...}) Line 4249 + 0x23 bytes C++ wxbase28ud_vc_custom.dll!wxAppConsole::HandleEvent(wxEvtHandler * handler=0x04a14fa0, void (wxEvent &)* func=0x007fc7b6, wxEvent & event={...}) Line 323 C++ wxbase28ud_vc_custom.dll!wxEvtHandler::ProcessEventIfMatches(const wxEventTableEntryBase & entry={...}, wxEvtHandler * handler=0x04a14fa0, wxEvent & event={...}) Line 1241 C++ wxbase28ud_vc_custom.dll!wxEventHashTable::HandleEvent(wxEvent & event={...}, wxEvtHandler * self=0x04a14fa0) Line 907 + 0x1c bytes C++ wxbase28ud_vc_custom.dll!wxEvtHandler::ProcessEvent(wxEvent & event={...}) Line 1301 + 0x1c bytes C++ wxmsw28ud_core_vc_custom.dll!wxWindow::HandleChar(unsigned int wParam=65, long lParam=1966081, bool isASCII=true) Line 5418 + 0x1c bytes C++ wxmsw28ud_core_vc_custom.dll!wxWindow::MSWWindowProc(unsigned int message=258, unsigned int wParam=65, long lParam=1966081) Line 3096 + 0x16 bytes C++ wxmsw28ud_core_vc_custom.dll!wxWndProc(HWND__ * hWnd=0x0033030a, unsigned int message=258, unsigned int wParam=65, long lParam=1966081) Line 2618 + 0x1c bytes C++ user32.dll!76206af8() [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll] user32.dll!76206d2d() user32.dll!76206cdc() user32.dll!76226fe1() user32.dll!7620d058() wxmsw28ud_core_vc_custom.dll!wxEventLoop::ProcessMessage(tagMSG * msg=0x01c9e714) Line 80 C++ wxmsw28ud_core_vc_custom.dll!wxEventLoop::Dispatch() Line 294 C++ wxmsw28ud_core_vc_custom.dll!wxAppBase::Dispatch() Line 340 + 0x13 bytes C++ wxmsw28ud_core_vc_custom.dll!wxApp::Yield(bool onlyIfNeeded=true) Line 726 + 0x19 bytes C++ Audacity.exe!AudioIO::StopStream() Line 1298 + 0x22 bytes C++ Audacity.exe!ControlToolBar::StopPlaying(bool stopStream=true) Line 711 C++ Audacity.exe!ControlToolBar::OnStop(wxCommandEvent & evt={...}) Line 690 C++ Audacity.exe!AudacityProject::OnPlayStopSelect() Line 1873 C++ Audacity.exe!AudacityProjectCommandFunctor::operator()(int index=0) Line 169 + 0x16 bytes C++ Audacity.exe!CommandManager::HandleCommandEntry(CommandListEntry * entry=0x049a9ed8, unsigned int flags=106339068, unsigned int mask=4294967295) Line 996 + 0x1c bytes C++ Audacity.exe!CommandManager::HandleKey(wxKeyEvent & evt={...}, unsigned int flags=106339068, unsigned int mask=4294967295) Line 1021 + 0x14 bytes C++ Audacity.exe!AudacityProject::HandleKeyDown(wxKeyEvent & event={...}) Line 1651 C++ Audacity.exe!AudacityApp::OnKeyDown(wxKeyEvent & event={...}) Line 1630 + 0xc bytes C++ wxbase28ud_vc_custom.dll!wxAppConsole::HandleEvent(wxEvtHandler * handler=0x03af9108, void (wxEvent &)* func=0x007e8e37, wxEvent & event={...}) Line 323 C++ wxbase28ud_vc_custom.dll!wxEvtHandler::ProcessEventIfMatches(const wxEventTableEntryBase & entry={...}, wxEvtHandler * handler=0x03af9108, wxEvent & event={...}) Line 1241 C++ wxbase28ud_vc_custom.dll!wxEventHashTable::HandleEvent(wxEvent & event={...}, wxEvtHandler * self=0x03af9108) Line 907 + 0x1c bytes C++ wxbase28ud_vc_custom.dll!wxEvtHandler::ProcessEvent(wxEvent & event={...}) Line 1301 + 0x1c bytes C++ wxbase28ud_vc_custom.dll!wxEvtHandler::TryParent(wxEvent & event={...}) Line 1264 + 0x19 bytes C++ wxmsw28ud_core_vc_custom.dll!wxWindowBase::TryParent(wxEvent & event={...}) Line 2667 C++ wxbase28ud_vc_custom.dll!wxEvtHandler::ProcessEvent(wxEvent & event={...}) Line 1315 C++ wxmsw28ud_core_vc_custom.dll!wxWindow::HandleKeyDown(unsigned int wParam=65, long lParam=1966081) Line 5432 + 0x1c bytes C++ wxmsw28ud_core_vc_custom.dll!wxWindow::MSWWindowProc(unsigned int message=256, unsigned int wParam=65, long lParam=1966081) Line 2991 + 0x14 bytes C++ wxmsw28ud_core_vc_custom.dll!wxWndProc(HWND__ * hWnd=0x0033030a, unsigned int message=256, unsigned int wParam=65, long lParam=1966081) Line 2618 + 0x1c bytes C++ user32.dll!76206af8() user32.dll!76206d2d() user32.dll!76206cdc() user32.dll!76226fe1() user32.dll!7620d058() wxmsw28ud_core_vc_custom.dll!wxEventLoop::ProcessMessage(tagMSG * msg=0x01c9fc10) Line 80 C++ wxmsw28ud_core_vc_custom.dll!wxEventLoop::Dispatch() Line 294 C++ wxmsw28ud_core_vc_custom.dll!wxEventLoopManual::Run() Line 115 + 0xd bytes C++ wxmsw28ud_core_vc_custom.dll!wxAppBase::MainLoop() Line 312 + 0x15 bytes C++ wxmsw28ud_core_vc_custom.dll!wxAppBase::OnRun() Line 368 C++ wxbase28ud_vc_custom.dll!wxEntryReal(int & argc=1, wchar_t * * argv=0x03af8fd0) Line 448 + 0x1b bytes C++ wxbase28ud_vc_custom.dll!wxEntry(int & argc=1, wchar_t * * argv=0x03af8fd0) Line 209 + 0xd bytes C++ wxmsw28ud_core_vc_custom.dll!wxEntry(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * __formal=0x00000000, HINSTANCE__ * __formal=0x00000000, int nCmdShow=1) Line 386 + 0xe bytes C++ Audacity.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x01d9626f, int nCmdShow=1) Line 626 + 0x36 bytes C++ Audacity.exe!__tmainCRTStartup() Line 578 + 0x35 bytes C Audacity.exe!WinMainCRTStartup() Line 403 C kernel32.dll!75ed417d() ntdll.dll!77d69e02() ntdll.dll!77d69dd5()
(In reply to comment #5) See Bug 30, comment 12
1. How was there a "reply to comment #9" in a bug with only 6 comments? 2. Anything related to playback or keyboard shortcuts is not this bug. It's probably related to bug 30, as Gale said. 3. The main part of this bug, the extra label, is fixed as of r10579. It was a small oversight in some of the LabelTrack editing logic -- basically to do sync selection there's a Cut and a Paste, and in label tracks a Cut is just a Copy followed by a Clear. The Copy and the Clear had different ideas of whether the last label belonged in or just outside of the selection. 4. The thing with labels not shifting when you paste into label tracks is probably due to some weirdness in AudacityProject::OnPaste(). I don't think it's desired. I'll see what I can find in there, but it's a pretty dangerous bit of code to go poking around in.
I looked a bit more at what happens when you paste audio into a label track with linking enabled and a second audio track below the label track. Actually, the behavior I witnessed in this case is worse than what you described and not even worth describing. It's a bug in OnPaste(), and the desired behavior is that pasting audio into a label track should be disallowed. I have a fix that might affect some other things, but hopefully only in good ways. It prevents OnPaste() from finding non-selected tracks while looking through project tracks for matching types in the case of a track type mismatch, for one thing. And for another, it makes sure that any intermediate changes are backed out in case of error. I don't have time to test it thoroughly now, and I'll try to get to it tomorrow or later this week. I'm a little concerned that part of it doesn't handle linking correctly... it's a really wacky corner case and I'll have to figure out how to test it. In case anyone wants a look I'll attach it to the bug.
Created attachment 29 [details] Disallows a remaining case of type-mismatched paste
(In reply to comment #7) Al said: "1. How was there a "reply to comment #9" in a bug with only 6 comments?" Sorry, that was comment #9 of bug 30.
With r10582 this bug is fixed. Setting status.
Noted - trying to get Mac testing done as the Paste changes in http://code.google.com/p/audacity/source/detail?r=10581 were stated as "significant" and "needs lots of testing".
(In reply to comment #12) Followed steps to reproduce on 1.3.13 alpha Dec 2 PPC Mac 10.5.8. Linking on. Error does not occur. If in step 5 I click in the label track at 10s and Edit > Paste I get an alert "Pasting one type of track into another is not allowed". Click OK and the paste occurs into the audio track above the label track. Is that right, or should nothing happen?
Resolved-fixed. I can't find any obvious problems on Windows or Ubuntu despite the warnings to test thoroughly. (In reply to comment #13) > If in step 5 I click in the label track at 10s and Edit > Paste I get an alert > "Pasting one type of track into another is not allowed". Click OK and the paste > occurs into the audio track above the label track. Is that right, or should > nothing happen? What happens is that 1) the warning occurs, 2) the labels are moved along by 5s and 3) silence is inserted in the audio track (the clipboard contents are not pasted). In the contrary case (copy the selected region in the label track that appears after 2), then paste into the audio track), 4) the warning occurs, 5) the labels are moved along by 5s and 6) silence is inserted into the audio track. I think this is OK. You can't really know what was intended, so we compromise by doing the same thing in both cases (moving the labels along and inserting silence in the audio, which latter must happen with Sync-Lock on). If Sync-Lock is off, the error occurs and nothing further happens. Personally I think at 3) I would have inserted the clipboard contents in the audio track as being more likely to be useful, but I certainly would not argue.
