Audacity Forum

Append record shows this very clearly. If you do SHIFT + R followed by SHIFT + A, SHIFT + R then starts recording from the cursor which is after the end of the track, and so this pads silence between the split line and the cursor. In this case it seems to make sense for SHIFT + R to move the cursor back to the end of the track.

We've had this argument before in fact that if you SHIFT + A after Pause (as you might to make an edit at the Pause point), the cursor appears after the point where the Pause was. I think again here there could be a case that the cursor should move back to the Pause point given it seems to be a defined place. This may be harder to do though, and if you could do it in this case you could probably move the cursor back to a more correct position when you use SHIFT + A after playback.


Gale

I tried going haltingly through a click track with pause instead of ctrl-a and it never seems to omit any part of the playback. It seems it might even be replicating some -- playing a few samples after the stopping cursor point. Even so I'd think that is more acceptable behavior. Is there any good reason, or technical difficulty, preventing ctrl-a from behaving likewise?

I guess you mean 'shift-a', not 'ctrl-a'.
The same behaviour is observable for 'set (or extent) left [right] selection'.

Shift-a, yes, I forget because I use a non-default key preference.

Gale Andrews wrote:Append record shows this very clearly. If you do SHIFT + R followed by SHIFT + A, SHIFT + R then starts recording from the cursor which is after the end of the track, and so this pads silence between the split line and the cursor. In this case it seems to make sense for SHIFT + R to move the cursor back to the end of the track.

On second thoughts, I've suggested before that it may be useful if you deliberately click after the end of the track then append record from there that silence is padded between the current end of the track and the click point. So perhaps it is better that when SHIFT + A sets the cursor after the end of a track, it then returns the cursor to the end of the track.

Robert J. H. wrote:The same behaviour is observable for 'set (or extent) left [right] selection'.

The trouble is that delayed human reactions and latency variability come into play. Even if I set audio to buffer to as low as 25ms (or as low as 10 ms with JACK on Windows), ] still sometimes lands almost as far after the audio I wanted to mark as it usually does when buffering is 100ms.

So although the buffer and the latency are not taken into account when using SHIFT + A, it seems hard to compensate for this, unless Audacity has some record of the Timeline position at which the command was sent and can set the cursor back to that point.

It seems the track end after stopping recording and a Pause position is quite akin to such a Timeline position (more accurate).


Gale

I don't understand what Gale is getting at. Go through a recording start and stop fashion with pause, and you hear everything. Use stop-and-set-cursor instead, and you don't. Why is that inconsistency a "feature?"

Paul L wrote:I don't understand what Gale is getting at. Go through a recording start and stop fashion with pause, and you hear everything. Use stop-and-set-cursor instead, and you don't. Why is that inconsistency a "feature?"

Perhaps I don't understand what your issue is fully. I understand the SHIFT + A causes the cursor to "move too far" (your own description). I think this means the cursor does not stop quickly enough when using SHIFT + A compared to when using SPACE. Right or wrong?

Pause has exactly the issue as you describe it (SHIFT + A used after Pause sets the cursor after the Pause position, so the cursor has moved too far).

If the cursor travels too far, then when you play the selection after ], I would have expected you hear more than you intended, not less. I would have expected when you play after SHIFT + A, you hear less than you intended. Isn't that what you mean?

If that's what you mean, how would you propose fixing it except by moving the cursor back from where SHIFT + A actually sets it down, and how do you propose to ensure that movement accounts for variable latency and variability in your own reaction time? What I am getting at is that when you append record then SHIFT + A, or Pause then SHIFT + A, Audacity has some known point on the Timeline to move the cursor back to.


Gale

Gale Andrews wrote:

Paul L wrote:I don't understand what Gale is getting at. Go through a recording start and stop fashion with pause, and you hear everything. Use stop-and-set-cursor instead, and you don't. Why is that inconsistency a "feature?"

Perhaps I don't understand what your issue is fully. I understand the SHIFT + A causes the cursor to "move too far" (your own description). I think this means the cursor does not stop quickly enough when using SHIFT + A compared to when using SPACE. Right or wrong?

Pause has exactly the issue as you describe it (SHIFT + A used after Pause sets the cursor after the Pause position, so the cursor has moved too far).
Gale

Let me try again.

This problem has nothing to do with my variable human reflexes. This has nothing to do with comparing shift-a with space. The problem is that what the cursor advances over is not exactly what was played back.

Start playing something like a click track at 240 beats per minute. Then just hit pause repeatedly, no shift-a. You hear all the clicks. You miss none.

Go back to start, hit play, and now hit shift-a repeatedly, which should likewise start and stop the replay but march through the whole track. You do miss clicks. Each time you hit shift-a, the place where the cursor stops does not correspond to the last thing you hear. It is instead too far right. With default latency setting, about 100 ms (or perhaps it's always exactly that?) is skipped.

If the program can put the green playback position after pause in the right place, why should correct cursor placement be different?

I hadn't tried pause and shift-a before, but I see what you mean now. Don't you think that alone is undesirable behavior?

@Paul, I see what you are getting at, but I still experience the symptoms I was describing of playback restarted after SHIFT + A. These must be caused by the cursor going too far.

I am not sure the symptoms you are describing (before you restart playback) are caused by the cursor going too far. Perhaps this is where the confusion is.

Paul L wrote:This has nothing to do with comparing shift-a with space.

I think it is exactly to do with it, because if you press SPACE when directly over a click, you always hear that click, just as you do when your press P. But if you press SHIFT + A when directly over a click, you may not hear that click. I quite often do hear it, even at default 100 ms Audio to Buffer, which is why I was finding it hard to follow you.

Paul L wrote:The problem is that what the cursor advances over is not exactly what was played back.

Playback cannot be different until you press one of those choices above, because Audacity cannot predict which you are going to press.

Paul L wrote:Go back to start, hit play, and now hit shift-a repeatedly, which should likewise start and stop the replay but march through the whole track. You do miss clicks. Each time you hit shift-a, the place where the cursor stops does not correspond to the last thing you hear. It is instead too far right.

"Missing clicks" (at the point you SHIFT + A) seems to be another symptom (call it symptom A).

The symptom I was describing (call it symptom B) is also true, that when you restart playback after SHIFT + A, you cannot hear the audio immediately following the point where you pressed SHIFT + A (because the cursor moved too far).

Is the cursor moving too far causing symptom A as your report title suggested? I'm not sure it is. Perhaps the buffered audio is being cut off at the exact point when you press SHIFT + A, instead of being allowed to complete (as it seems to be when using SPACE or P). If so, moving the cursor back won't help symptom A.

Paul L wrote: With default latency setting, about 100 ms (or perhaps it's always exactly that?) is skipped.

I described what I found. At 100 ms the playback is often skipped but by no means always. At 25 ms the playback is usually included but not always.

Also the exact place the cursor ends up after SHIFT + A is variable. A shorter "Audio to buffer" setting usually makes the cursor move less far to right, but not always.

Paul L wrote:If the program can put the green playback position after pause in the right place, why should correct cursor placement be different?

That is what I asked above. I am not defending that. I am saying the following.

• When you SHIFT + A during playback there is no physically obvious place to move the cursor back to.
• Given the latency variability I see (and despite what you say, variable reaction times) it may not be possible to always move the cursor back to the "correct" place.
• There is a physically obvious place for SHIFT + A to move back to if you were append recording before SHIFT + A, or if you paused before SHIFT + A.

Gale