Delay typing into a label or dragging tracks vertically

[DickN]

The "audacity_no_autosave" version doesn't work at all here. On XP I got an immediate fatal error and the customary offer to tell Microsoft about it . Same thing on Vista. It's getting exception code c0000005 at offset 0004b417. I would assume the download wasn't corrupted because it unzipped. CRC-32 is BEF696F9. I must be executing at least part of the startup because if I try to run it from a different directory it gets a missing dll error.

I removed the j & k shortcuts long ago in Preferences->Keyboard and just verified they're still removed, so that's not it.

[Gale Andrews]

I can't see the download at all - I get a 404 error

That's because the post above your cited post says "I've removed the "no_autosave" build". It's been superseded by the Nightly Build, which is faster than the "no_autosave" build for editing labels. The direct link for the Windows 2000 and later Nightly Build is: http://www.gaclrecords.org.uk/audacity- ... -alpha.zip. So Peter and DickN, please try the Nightly Build.

I don't understand why the "no_autosave" build doesn't execute for DickN, though. Let me know if the "Nightly" has the same problem for you.

I removed the j & k shortcuts long ago in Preferences->Keyboard and just verified they're still removed, so that's not it.

Since no one else seems to have this problem with ENTER on a label shifting the Timeline when the track isn't moving, you'll have to see if you can give us the steps (but please test in the Nightly, not in 1.3.13 Beta). If the Timeline doesn't move to the start or end of the track, where does it move to?


Thanks,



Gale

[waxcylinder]

I can't see the download at all - I get a 404 error

That's because the post above your cited post says "I've removed the "no_autosave" build". It's been superseded by the Nightly Build, which is faster than the "no_autosave" build for editing labels....

Well that'll teach me to learn to read more thoroughly

I downloaded the May23 nightly build for testing - using my 0ne-hour test show. It still has a delay of 2-3 seconds before displaying the label box when typing Ctrl+B or Ctrl+M - but there is a big improvement in the insertion of the label text which goes back to instantaneous input with no delay once the label box is displayed - and editing of the label has also returned to instantaneous too (which was not the case with 1.3.13 or the earlier 1.3.14s).

WC


Aside to Gale: I will shortly be sending you (via the QA quality list my set of results for Audacity timings).

[steve]

I've tested Audacity nightly (downloaded today) on XP with a 2 hour mono track.
The computer is dual core 2 GHz with 1 MB RAM.
Creating labels and adding text are both immediate (no noticeable delay).

[DickN]

Since no one else seems to have this problem with ENTER on a label shifting the Timeline when the track isn't moving, you'll have to see if you can give us the steps (but please test in the Nightly, not in 1.3.13 Beta). If the Timeline doesn't move to the start or end of the track, where does it move to?

Using the May 23 Nightly Build 1.3.14 Alpha, I see <Enter> has nothing to do with it. I had been seeing the jump when I pushed <Enter> only coincidentally. With 1.3.14 Alpha, if the jump is going to happen it happens while I'm typing. It doesn't affect anything about the label, but the jump is about half a screen to the right (i.e., view window moves backward in time). I usually have the zoom set (at least on the laptop) so about 9 seconds are on-screen. I haven't tried 1.3.14 Alpha on Vista yet, except to verify that it starts up properly. On XP, there's no perceptible delay typing into a label and none worth mentioning when dragging tracks vertically. The delay for Ctrl-M during playback is about a second. I think it's about the same during record.

I had something very strange happen today while editing Sunday's recording with 1.3.14 Alpha. I had duplicated a minute and 2 seconds of audio starting at 1:04:17 so I could apply effects to it and compare it with the original before pasting it back to the original track. After pasting it back I did some more editing, removing extraneous noises etc. At some point, I noticed the label tracks (I had 2 of them) were out of alignment with the audio by 1:02 over about the last half of the recording. I fiddled about with the label tracks to put them back in alignment. Then I discovered what really happened: That 1:02 of audio I had duplicated had been inserted into the main audio track at a point 9:44 prior to where it came from, in addition to being pasted back to its original location as intended. It must have happened when I pasted it back, because the effects had been applied but the later edits I made on it had not been done in this extraneous copy. It would be quite a stretch to recall the exact sequence involved, especially since I didn't even realize what had happened until quite some time later. I'll have to compare it with the cassette recording next week and see if anything's missing at that point - it sounds like something is but the time offset that resulted relative to the label tracks suggests otherwise.

[DickN]

Just remembered, there was a crash & recovery, but I don't recall the state of the project at that time.

[Gale Andrews]

Since no one else seems to have this problem with ENTER on a label shifting the Timeline when the track isn't moving, you'll have to see if you can give us the steps (but please test in the Nightly, not in 1.3.13 Beta). If the Timeline doesn't move to the start or end of the track, where does it move to?

Using the May 23 Nightly Build 1.3.14 Alpha, I see <Enter> has nothing to do with it. I had been seeing the jump when I pushed <Enter> only coincidentally. With 1.3.14 Alpha, if the jump is going to happen it happens while I'm typing. It doesn't affect anything about the label, but the jump is about half a screen to the right (i.e., view window moves backward in time). I usually have the zoom set (at least on the laptop) so about 9 seconds are on-screen.

If it was moving a screenful or more I would have said it was activating one of the cursor jump shortcuts (, or . or SHIFT-modified , or .). So is the effect like dragging the horizontal scrollbar a short way? If your cursor and label was for example at 16 seconds on the Timeline, the cursor remains at 16 seconds, but the 16 seconds point moves left so that it is above the left edge of the waveform, by the mute/solo buttons? Have you identified if any entered characters do this, but others don't?

Can you upload screenshots before and after the move, so we have a clearer idea?

I had something very strange happen today while editing Sunday's recording with 1.3.14 Alpha. I had duplicated a minute and 2 seconds of audio starting at 1:04:17 so I could apply effects to it and compare it with the original before pasting it back to the original track. After pasting it back I did some more editing, removing extraneous noises etc. At some point, I noticed the label tracks (I had 2 of them) were out of alignment with the audio by 1:02 over about the last half of the recording. I fiddled about with the label tracks to put them back in alignment. Then I discovered what really happened: That 1:02 of audio I had duplicated had been inserted into the main audio track at a point 9:44 prior to where it came from, in addition to being pasted back to its original location as intended. It must have happened when I pasted it back, because the effects had been applied but the later edits I made on it had not been done in this extraneous copy. It would be quite a stretch to recall the exact sequence involved, especially since I didn't even realize what had happened until quite some time later. I'll have to compare it with the cassette recording next week and see if anything's missing at that point - it sounds like something is but the time offset that resulted relative to the label tracks suggests otherwise. Just remembered, there was a crash & recovery, but I don't recall the state of the project at that time.

So from your description, you have Tracks > Sync-Lock Tracks checked? The paste would not have moved the labels otherwise. At what point in all this did the crash occur? Again, without screenshots, it is difficult to piece anything together, but it is possible you could have found a repeatable crash scenario. Pasting in two places at once (in the same track) shouldn't happen.


Gale

[DickN]

So from your description, you have Tracks > Sync-Lock Tracks checked? The paste would not have moved the labels otherwise. At what point in all this did the crash occur? Again, without screenshots, it is difficult to piece anything together, but it is possible you could have found a repeatable crash scenario. Pasting in two places at once (in the same track) shouldn't happen.

Guess my description was a bit fuzzy. Sync Lock was OFF and the labels didn't move, I only thought they had because they no longer aligned with the audio. Only the audio moved, because of the insertion that I discovered later. I was pasting into the same select region from which I had originally duplicated the audio, so alignment with the labels should not have changed.

As I said, I don't recall the state of the project when the crash occurred. I believe it happened either during an Undo or when I clicked either Effect or Tracks.

Getting a screen shot before the manifestation would require that I know it's going to happen. So far, I've caught one such event in progress but I couldn't get it to happen again. Here's the sequence:

I have one audio track and 2 label tracks (in that order), duration is about 1 hr 43 min.
Transport is Stopped.
Sync Lock ON (not a necessary condition, but it was on).
Select a region (~2 seconds) in the Audio track.
Shift-Click the panel of 2nd label track to select region therein.
Shift-Click the panel of the Audio track to de-select it.
Move focus to the label track with down-arrow key.
Type 'NS' (uppercase).
Well, guess what - it happened again. But now, again, it won't repeat.
Display jumps to the right. Left margin before the jump was approx. 1:01:39.5. After the jump it was 1:01:33.3. My display is 9 seconds wide. In this case the label didn't go off the screen because the region was initially near the left edge. The label was still open with the text cursor at end of text. This is not the same location in time where it happened previously.

So far I've gotten this to happen exactly twice today, the latter being as I was repeating my steps while typing this post. This time, because I had the browser open, Windows had to do context switching. I had 'NS' typed and was waiting for the hard drive before the jump occurred. I can't say whether it happened due to the N or the S. The previous time this happened, I also am not sure whether it followed the N or the S. I typed it rather quickly and wasn't really expecting a demonstration at the time. Could be typing quickly is a necessary condition, and when Audacity is waiting for Windows to complete a context swap it becomes unnecessary.

Note that I didn't use Ctrl-B here. I have 2 label tracks and I did it this way to make sure the label would go to the right one. I might be using a longer procedure than necessary. On other occasions, this has happened with one label track and I had used Ctrl-B. I am sure on other occasions I wasn't typing "NS" (NS = "noise sample").

[DickN]

Success! It fails!

The determining factor is that a second character for a label is typed before the blank label is created. With 1.3.13 Beta, this happened frequently even if I used Ctrl-B to initiate the label. With 1.3.14 Alpha, Ctrl-B normally (barring OS delays) creates the label quickly enough to avoid the situation. When I create the label by just typing with the region selected in a focused label track, I can easily get ahead of the process and reproduce the problem. The characters themselves don't matter. Procedure is as listed in my previous post, except this time there are 3 label tracks and I didn't have Sync Lock turned on.

Workaround 1: Wait for label to appear before typing 2nd character;
Workaround 2: Initiate the label with a command before typing label text.

Screenshot before event.

fullwindow001.png (54.71 KiB) Viewed 1286 times

Screenshot after event.

fullwindow002.png (55.32 KiB) Viewed 1286 times

[DickN]

Good grief! I just noticed my toolbars have gotten rearranged! It happens when I capture the screenshot. The meters get shorter too, and both volume sliders get set to FS. I just tried to save a screenshot of the toolbars in 1.3.13 to show the change, and the same thing happened.