Delay typing into a label or dragging tracks vertically

[Gale Andrews]

I'd like to have a way to specify which label track to use for "Export Multiple" so I don't have to drag the label tracks around.

Note there is already a bugzilla enhancement issue for this that suggests exporting all label tracks but allowing to "mute" the ones not required for export.


Gale

[DickN]

3 more observations:

1: During the delay, Windows (Vista) repaints the Audacity button on the Windows Task Bar multiple times. On two occasions, Windows grayed-out the Audacity window and put "(not responding)" in the title bar, although recording continued uninterrupted.

2: This also happens when typing into Track Name.

3: As noted in my original post, the display sometimes jumps horizontally quite a lot, which becomes apparent at the end of the delay. While Transport was Stopped, I typed a range label and the during the delay I attempted to select a different nearby region of audio. There was no immediate response on the screen, but after the delay a select region appeared in the same screen position as the one I'd tried to select but the action took place after the jump so that a different actual time region was selected. I had a 48 minute Stereo track and two 28 minute Mono tracks at the time.

[Gale Andrews]

I've added Bug 406.

Peter has remarked to me by e-mail that:

Sometimes it does funny things with the waveform display by showing a section that it is not currently playing or labelling.

This isn't (I believe) new to 1.3.13. If you don't close the previous label, then you when you CTRL + M to add the new label, the Timeline position will jump back to the old label while it closes, and then move the Timeline to a new position with the old label centered in the waveform or the new label at the left edge of the waveform.

Also if you hold CTRL while a label is open and playback or recording is in progress, the display jumps between the label position and the playback position. This movement can be quite slow in 1.3.13. I've added these behaviours at:
http://wiki.audacityteam.org/wiki/Propo ... e_Problems

I don't see either of DickN's behaviours on XP or Win 7 in 1.3.13:

I'm finding that when I edit a label the display jumps horizontally when I hit <enter>, enough to put the label (if it's a point label) off the screen.

The display sometimes jumps horizontally quite a lot, which becomes apparent at the end of the delay. While Transport was Stopped, I typed a range label and the during the delay I attempted to select a different nearby region of audio. There was no immediate response on the screen, but after the delay a select region appeared in the same screen position as the one I'd tried to select but the action took place after the jump so that a different actual time region was selected.

Do those two happen in 1.3.12 as well or only 1.3.13? Certainly the second behaviour with the selection in the wrong place occurs if you are playing and the selection isn't drawn until the waveform has moved on.



Gale

[DickN]

I've added Bug 406.

In Step 3, "Start playing the track or recording a new one" is unnecessary in my experience for most of the indicated behavior, although so far I have only seen the OS responses ("not responding" and repainting the task bar icon) while recording.

Previously I wrote that my "fast" quad-core Vista system shows the delay much more than my "slower" XP laptop. I must correct myself here: Vista isn't giving more than 26% of the CPU to any one process even if it's idle the rest of the time!

Peter has remarked to me by e-mail that:

Sometimes it does funny things with the waveform display by showing a section that it is not currently playing or labelling.

This isn't (I believe) new to 1.3.13. If you don't close the previous label, then you when you CTRL + M to add the new label, the Timeline position will jump back to the old label while it closes, and then move the Timeline to a new position with the old label centered in the waveform or the new label at the left edge of the waveform.

I've seen this but never considered it a bug. What should it do instead?

Also if you hold CTRL while a label is open and playback or recording is in progress, the display jumps between the label position and the playback position. This movement can be quite slow in 1.3.13. I've added these behaviours at:
http://wiki.audacityteam.org/wiki/Propo ... e_Problems

This brings to mind another problem I'm having with 1.3.13, which I will have to check next time the time jump occurs. Occasionally the keyboard i/f gets into a state of mis-mapping the keys. The UP arrow and DOWN arrow become RIGHT and LEFT arrows, but the RIGHT and LEFT arrows behave normally. Sometimes the SHIFT key is logically (no, not mechanically!) stuck down as indicated by the icon on the PLAY button (I have a fuzzy memory of this happening with 1.3.12 too.). Tapping the SHIFT key gets that back in sync. I don't recall exactly what fixes the arrow keys, but I've never had to restart Audacity to fix it. Now, if the Ctrl key behaved as I just described for the Shift key, ... just thinking with my fingers here. I think I've only seen the arrow keys problem after I've typed something much faster than the display responds. It happened last night on the XP laptop.

I had another strange experience last night but I'm not sure what led up to it nor was I very observant of the syndrome: Something went completely haywire when I pressed the Shift key and wasn't touching anything else. I think I had been making a string of long timeline jumps with the keyboard during Play, so it might be associated with the stuck Shift key behavior cited above. At some time last night I was unable to jump backward much faster than playback speed. This problem was corrected after I stopped and restarted Playback. It's apparent that something was just going wrong, because I got a "data execution" crash a little while later.

I don't see either of DickN's behaviours on XP or Win 7 in 1.3.13:

I'm finding that when I edit a label the display jumps horizontally when I hit <enter>, enough to put the label (if it's a point label) off the screen.

The display sometimes jumps horizontally quite a lot, which becomes apparent at the end of the delay. While Transport was Stopped, I typed a range label and the during the delay I attempted to select a different nearby region of audio. There was no immediate response on the screen, but after the delay a select region appeared in the same screen position as the one I'd tried to select but the action took place after the jump so that a different actual time region was selected.

Do those two happen in 1.3.12 as well or only 1.3.13? Certainly the second behaviour with the selection in the wrong place occurs if you are playing and the selection isn't drawn until the waveform has moved on.

Only in 1.3.13. I can picture that last part happening, but note that in this case Transport was Stopped.

[Gale Andrews]

I've added Bug 406.

In Step 3, "Start playing the track or recording a new one" is unnecessary in my experience for most of the indicated behavior,

Yes the description says "Does not depend on playing or recording, but doing so usually shows the issue more clearly."

Peter has remarked to me by e-mail that:

Sometimes it does funny things with the waveform display by showing a section that it is not currently playing or labelling.

This isn't (I believe) new to 1.3.13. If you don't close the previous label, then you when you CTRL + M to add the new label, the Timeline position will jump back to the old label while it closes, and then move the Timeline to a new position with the old label centered in the waveform or the new label at the left edge of the waveform.

I've seen this but never considered it a bug. What should it do instead?

It's not being tracked as a bug because "what it should do" is to be discussed as part of a wider proposal about playback scrolling. But in a nutshell, I think it shouldn't move the Timeline position at all - as far as the user's intention is concerned the situation is the same as adding a new label at playback position when the previous label is already closed.

We should retain some way of giving focus back to the label when playback has pushed the label behind the scroll, but CTRL doesn't seem a good choice. Also typing more characters in the label once it has gone behind should not jerk you constantly between the label position and playback position.

Another problem I'm having with 1.3.13, which I will have to check next time the time jump occurs. Occasionally the keyboard i/f gets into a state of mis-mapping the keys. The UP arrow and DOWN arrow become RIGHT and LEFT arrows, but the RIGHT and LEFT arrows behave normally. Sometimes the SHIFT key is logically (no, not mechanically!) stuck down as indicated by the icon on the PLAY button (I have a fuzzy memory of this happening with 1.3.12 too.). Tapping the SHIFT key gets that back in sync. I don't recall exactly what fixes the arrow keys, but I've never had to restart Audacity to fix it. Now, if the Ctrl key behaved as I just described for the Shift key, ... just thinking with my fingers here. I think I've only seen the arrow keys problem after I've typed something much faster than the display responds. It happened last night on the XP laptop.

SHIFT making Play display as Loop Play is already at Bug 307. If you find steps to reproduce the arrow keys problem, please post them 1, 2, 3... At the moment I don't understand the context in which you are using arrow keys.

I had another strange experience last night but I'm not sure what led up to it nor was I very observant of the syndrome: Something went completely haywire when I pressed the Shift key and wasn't touching anything else. I think I had been making a string of long timeline jumps with the keyboard during Play, so it might be associated with the stuck Shift key behavior cited above. At some time last night I was unable to jump backward much faster than playback speed. This problem was corrected after I stopped and restarted Playback. It's apparent that something was just going wrong, because I got a "data execution" crash a little while later.

If you can reproduce this crash, please let us know. Note you can't jump playback behind the cursor - it's functionality we would like but doing it introduces other bugs.

I don't see either of DickN's behaviours on XP or Win 7 in 1.3.13:

(1) I'm finding that when I edit a label the display jumps horizontally when I hit <enter>, enough to put the label (if it's a point label) off the screen.

(2) The display sometimes jumps horizontally quite a lot, which becomes apparent at the end of the delay. While Transport was Stopped, I typed a range label and the during the delay I attempted to select a different nearby region of audio. There was no immediate response on the screen, but after the delay a select region appeared in the same screen position as the one I'd tried to select but the action took place after the jump so that a different actual time region was selected.

Do those two happen in 1.3.12 as well or only 1.3.13? Certainly the second behaviour with the selection in the wrong place occurs if you are playing and the selection isn't drawn until the waveform has moved on.

Only in 1.3.13. I can picture that last part happening, but note that in this case Transport was Stopped.

Does (1) also happen without playing the track?

Can you list steps to reproduce 1, 2, 3... for (1) and (2) from launch of Audacity? Or is (2) a special case of (1)?


Thanks.


Gale

[Gale Andrews]

James has figured out that autosaving every change in project state is a significant part of the problem - we currently save for every letter typed and for every arrow key press when you hold SHIFT and arrow to extend a selection. 1.3.12 has autosave but only saves periodically. It was a bad implementation and gave a lot of problems with faulty crash recoveries.

I built a version with autosave off and found it about halves the delay when typing characters and drawing selections with the keyboard, but I have never had the problem so bad that the selection was never drawn until the keys were released. The reason the delay is only halved is probably that 1.3.13 does complete redraws to fix a display bug with spurious lines appearing on the waveform and focus border.

The build without autosave is here, if Peter and DickN would like to try it. it might give an idea how much it might help if not every single change of state was saved. It's just the .exe, so extract it to your 1.3.13 installation folder and run it instead of the installed audacity.exe.



Gale

[DickN]

Does (1) also happen without playing the track?

Can you list steps to reproduce 1, 2, 3... for (1) and (2) from launch of Audacity? Or is (2) a special case of (1)?

Yes, (1) does happen when neither playing nor recording.
I've only seen (2) on one occasion. It is a special case of (1), since (1) has to happen in order for (2) to happen. I'll try to work out a "make it happen" procedure when I'm back on the Vista system, but essentially what I did was paint a select region with the mouse during the time between hitting <Enter> for a label and the label being echoed on the screen. Audacity was neither playing nor recording at the time, and the label was on the screen until the display jumped.

Am I the only one using Vista? (Not that I'd recommend it....)

The build without autosave is here, if Peter and DickN would like to try it. it might give an idea how much it might help if not every single change of state was saved. It's just the .exe, so extract it to your 1.3.13 installation folder and run it instead of the installed audacity.exe.

Starting download now, hope this transfer goes better than the last one (took at least 3 tries over dialup, kept getting incomplete/corrupted file).

[DickN]

Yep, downloaded in 2 tries this time

[Gale Andrews]

Does (1) also happen without playing the track?

Can you list steps to reproduce 1, 2, 3... for (1) and (2) from launch of Audacity? Or is (2) a special case of (1)?

Yes, (1) does happen when neither playing nor recording.
I've only seen (2) on one occasion. It is a special case of (1), since (1) has to happen in order for (2) to happen. I'll try to work out a "make it happen" procedure when I'm back on the Vista system, but essentially what I did was paint a select region with the mouse during the time between hitting <Enter> for a label and the label being echoed on the screen. Audacity was neither playing nor recording at the time, and the label was on the screen until the display jumped.

I could reproduce it three times in 20 tries. The display jumped to the end of the project and then for a while I could reproduce bug 40 where typing j or k (even slowly) doesn't type the character but activates the shortcut to move the cursor to the start or end of the project. If the cursor was going to the start or end of the project, I think that's the reason for what you are seeing, but that bug is not new to 1.3.13. Possibly typing fast while autosaves are backed up helps to precipitate it.

James has made experimental changes that look as if autosaving isn't done in labels (unless you click to place the cursor in the label) so if you crashed while typing the label you would not recover the label text on restart. This seems faster typing labels than the crude change which merely disabled autosave, but it doesn't address creating selections with the mouse - that still hangs. So I've removed the "no_autosave" build mentioned above. If you want to try James' changes you can get the Nightly Builds (Mac won't show the change until the "2011.05.23-03.15" build).



Gale

[waxcylinder]

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