Improved seeking

This read-only archive contains discussions from the Adding Feature forum.
New feature request may be posted to the Adding Feature forum.
Technical support is available via the Help forum.
Gale Andrews
Quality Assurance
Posts: 41761
Joined: Fri Jul 27, 2007 12:02 am
Operating System: Windows 10

Re: Improved seeking

Post by Gale Andrews » Mon Nov 03, 2014 1:59 pm

Paul L wrote:
Gale Andrews wrote: As I understand it there are two complaints.
  • During playback, there is no way to move the editing cursor and/or expand or contract arbitrary selections using the keyboard.
  • When not playing, there is no way to nudge the editing cursor by a fixed amount irrespective of zoom level.
So I would say that LEFT/RIGHT arrow and modifiers do the same when playing as not playing, and a new shortcut is needed to nudge the editing cursor (when playing or not).
These "complaints" are not what I said, maybe someone else has said them.
Yes, VI users complain exactly about those issues. ;)

How did you want to solve the "inconsistency"?
Paul L wrote:The second point is incorrect. See the , and . and shift-, and shift-. commands. These jump by 1 s or, with shift, 15 s. Or, other fixed times that you can specify in Playback preferences.
Yes, as I wrote it, it is technically incorrect ;) but to clarify, the request is for a fixed short distance nudge (as in Goldwave), for example 100 ms. Users don't want to set the seek shortcuts to such short times as they will then be of no value for seeking.


Gale
________________________________________FOR INSTANT HELP: (Click on Link below)
* * * * * Tips * * * * * Tutorials * * * * * Quick Start Guide * * * * * Audacity Manual

Paul L
Posts: 1788
Joined: Mon Mar 11, 2013 7:37 pm
Operating System: Please select

Re: Improved seeking

Post by Paul L » Mon Nov 03, 2014 3:13 pm

All easily done as variations on what we have, if someone specifies.

Gale Andrews
Quality Assurance
Posts: 41761
Joined: Fri Jul 27, 2007 12:02 am
Operating System: Windows 10

Re: Improved seeking

Post by Gale Andrews » Mon Nov 03, 2014 3:47 pm

Paul L wrote:All easily done as variations on what we have, if someone specifies.
You still have not specified what your complaints are, given they are different from those of VI users.

I gave my "solution", which is a portmanteau of the suggestions that have been made. Robert J.H. may have some useful input, especially on the shortcuts to be used, so you could PM him and ask him to comment in this thread.

Thanks,

Gale
________________________________________FOR INSTANT HELP: (Click on Link below)
* * * * * Tips * * * * * Tutorials * * * * * Quick Start Guide * * * * * Audacity Manual

Paul L
Posts: 1788
Joined: Mon Mar 11, 2013 7:37 pm
Operating System: Please select

Re: Improved seeking

Post by Paul L » Mon Nov 03, 2014 3:55 pm

I have improved my patch again. I have also implemented "scrubbing" of a sort, for CTRL-drag. Try this!

http://audacity.238276.n2.nabble.com/Pa ... 64841.html

As for "complaints," I wasn't really complaining, just remarking on a minor inconsistency that doesn't bother me much.

The real problem I am trying to solve is that pressing and holding arrow keys should not cause playback to go silent.

Paul L
Posts: 1788
Joined: Mon Mar 11, 2013 7:37 pm
Operating System: Please select

Re: Improved seeking

Post by Paul L » Mon Nov 03, 2014 4:10 pm

Paul L wrote:I have improved my patch again. I have also implemented "scrubbing" of a sort, for CTRL-drag. Try this!

http://audacity.238276.n2.nabble.com/Pa ... 64841.html
Oh, and let me add: the CTRL-drag is not limited to the boundaries of the prior selection. But I did not try to make seeking with arrow keys or , and . unlimited.

Robert J. H.
Posts: 3633
Joined: Thu May 31, 2012 8:33 am
Operating System: Windows 10

Re: Improved seeking

Post by Robert J. H. » Mon Nov 03, 2014 9:55 pm

Paul L wrote:I have improved my patch again. I have also implemented "scrubbing" of a sort, for CTRL-drag. Try this!

http://audacity.238276.n2.nabble.com/Pa ... 64841.html

As for "complaints," I wasn't really complaining, just remarking on a minor inconsistency that doesn't bother me much.

The real problem I am trying to solve is that pressing and holding arrow keys should not cause playback to go silent.
Seems to work quite well (the scrubbing feature is of course not testable for me).
One little thing:
One cannot switch easily from long jumps to short ones and vis-versa by simply pressing and releasing the shift-key. I don't think that you can do much about that as it is probably due to the keyboard input handling on the operating system in question (and the interception of the screen reader as well).
However, it only means that one has to release all keys and then press the new key (-combination) again, a really minor issue.

I've already mentioned the inconsistency in another thread and my thoughts about it but I must search it.

I don't know how valuable the additional audio output is for a IV user, the continuous playback buffer seems a little short.
An audio book will for instance sound alike throughout, although big gaps can be made out much easier with your patch. And Chapter or song breaks can thus probably be better spotted than ever before.
We do actually lack a additional time output for when a key is released or the actual position makes a greater jump. However, this goes rather into a screen reader script.
A similar functionality would mean for your algorithm that the playback is a little bit longer after a certain amount of keypresses.
For instance, after 30 times, the playback could last half a second instead of a single buffer, short seek of 1 s would announce half a minute and 15 s seeks 7:30 minutes.

A further possibility that I've described earlier is *Fast jump" or "Quick Select" (since it works like the famous algorithm):
- two keys to jump 50 % to either the left or the right.
- one key to go a level back
Thus, you'll need around 12 keystrokes to find a specific second in a one hour recording.
This is especially useful if you've listened to /worked on e.g. an audio book or a song compilation of several hours length.
If you recognize the played part, you'll jump 50 % to the right, otherwise to the left.

The scrubbing feature would be fast as well, however, for IV users, it should all be relative to the current cursor position and not the mouse pointer itself. As soon as you press the modifier and the mouse button, the scrubbing feature starts, regardless if the pointer is in the waveform or even outside the Audacity window.

Anyway, thanks for the patch, a really fine thing.

By the way, you could examine why the Wasapi host refuses to play the selected region by cutting off the end... (this is a general bug and not related to your patch)

Regards
Robert

Robert J. H.
Posts: 3633
Joined: Thu May 31, 2012 8:33 am
Operating System: Windows 10

Re: Improved seeking

Post by Robert J. H. » Tue Nov 04, 2014 4:20 pm

Also, the patch fails at the right selection boundary.
It moves the cursor to a new position between right selection edge and end of the track/project.
If nothing is selected, the cursor will be newly at the right edge or a bit before it.

Try it on a Chirp or something.

Paul L
Posts: 1788
Joined: Mon Mar 11, 2013 7:37 pm
Operating System: Please select

Re: Improved seeking

Post by Paul L » Tue Nov 04, 2014 4:33 pm

Robert J. H. wrote:Also, the patch fails at the right selection boundary.
It moves the cursor to a new position between right selection edge and end of the track/project.
If nothing is selected, the cursor will be newly at the right edge or a bit before it.

Try it on a Chirp or something.
You refer to the seeking with right arrow or period, not the ctrl-drag.

I think what you describe is not different from the version without the patch. If you call it a bug, it was existing already.

Robert J. H.
Posts: 3633
Joined: Thu May 31, 2012 8:33 am
Operating System: Windows 10

Re: Improved seeking

Post by Robert J. H. » Tue Nov 04, 2014 6:54 pm

Paul L wrote:
Robert J. H. wrote:Also, the patch fails at the right selection boundary.
It moves the cursor to a new position between right selection edge and end of the track/project.
If nothing is selected, the cursor will be newly at the right edge or a bit before it.

Try it on a Chirp or something.
You refer to the seeking with right arrow or period, not the ctrl-drag.

I think what you describe is not different from the version without the patch. If you call it a bug, it was existing already.
I do certainly call it a bug.
You're right, it seems to happen in a fairly recent nightly built too (rev 13419) but too a much lesser degree. Short seeking restores the correct cursor in most cases, unless one presses dot or right arrow quite long.
I think that this issue should be solved apart from your patch.

What do you think should happen when the boundary is reached?

I could imagine that it would be useful to indicate the boundary by repeating a pling sound, just the way e.g. Windows indicates a full keyboard buffer.


Another thing, would it be possible to introduce a micro- cross-fade or to jump at a zero crossing towards the end of the audio buffer to make the seeking less clicky? Perhaps too complicated to implement for now.

Gale Andrews
Quality Assurance
Posts: 41761
Joined: Fri Jul 27, 2007 12:02 am
Operating System: Windows 10

Re: Improved seeking

Post by Gale Andrews » Wed Nov 05, 2014 11:10 am

Robert J. H. wrote:
Paul L wrote:
Robert J. H. wrote:Also, the patch fails at the right selection boundary.
It moves the cursor to a new position between right selection edge and end of the track/project.
If nothing is selected, the cursor will be newly at the right edge or a bit before it.

Try it on a Chirp or something.
You refer to the seeking with right arrow or period, not the ctrl-drag.

I think what you describe is not different from the version without the patch. If you call it a bug, it was existing already.
I do certainly call it a bug.
You're right, it seems to happen in a fairly recent nightly built too (rev 13419) but too a much lesser degree. Short seeking restores the correct cursor in most cases, unless one presses dot or right arrow quite long.
I think that this issue should be solved apart from your patch.
Robert, can you please write steps out 1,2,3 for the bug. I can't understand exactly what you mean.

Thanks


Gale
________________________________________FOR INSTANT HELP: (Click on Link below)
* * * * * Tips * * * * * Tutorials * * * * * Quick Start Guide * * * * * Audacity Manual

Locked