Bug 15 – Enh: Scrolling/zooming behaviour doesn't preserve context of audio being worked with

••• Introduction •••
••• Keywords •••

Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla

Bug 15 - Enh: Scrolling/zooming behaviour doesn't preserve context of audio being worked with


Summary:	Enh: Scrolling/zooming behaviour doesn't preserve context of audio being work...

Status:	CLOSED NOT-A-BUG

Product:	Audacity
Classification:	Unclassified
Component:	User Interface
Version:	2.1.3
Hardware:	Per OS All

Importance:	P3 Enhancement
Assigned To:	Default Assignee for New Bugs

URL:	http://wiki.audacityteam.org/wiki/Pro...
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2009-10-30 14:45 UTC by Richard Ash
Modified:	2018-08-20 11:51 UTC (History)
CC List:	6 users (show)

See Also:	1292
Steps To Reproduce:	Use Audacity to scroll and zoom See Release Note below
Release Note:	GROUP:Interface * Audacity has several weaknesses in preserving the context of the audio being worked with: If playback scrolls, pressing Stop leaves the waveform where it stopped and the cursor or left selection edge invisible. Pressing Play to resume then scrolls the waveform to start at the playback start point, hiding the previously visible context before the cursor or left selection edge. '''Workaround:''' Left arrow after Stop centers the view at the cursor position. {{menu\|View > Go to Selection Start}} or {{menu\|View > Go to Selection End}} move the left or right selection edge into view with the edge centered, so can show context that has been moved out of view. Zoom to Selection shows none of the surrounding context
First Git SHA:
Group:	---
Workaround:
Closed:	2018-08-20 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Richard Ash 2009-10-30 14:45:51 UTC

* GA: Import a file, place cursor in centre and zoom in four or five times.
Then play a few seconds of audio so that the cursor goes past the scroll. Press
Space and the timeline remains where stopped (maybe OK). Press Space again and
playback restarts from original point but that is now at far left of scroll,
not in the middle. The context preceding that playback position is now lost,
requiring a fiddly drag back on the horizontal scrollbar, or a zoom out and
back in. Or, you must draw a selection region when you may not want to do so.
Very irritating for repeated zoomed-in editing at one spot.
* JC: This is a P4, or better still a feature request for improved
scrolling/zooming behaviour. Let's get some detailed usability enhancements
written up for a GSoC 2010 idea? Then drop this as a P2. In this area I'd see
'zoom to selection' should be 90% not 100% zoom, so that we get context, plus
also option for smooth scroll on sufficiently fast machines. Can we replace
this P2 with a detailed/motivated feature request?
* GA: Need time to consider exactly what may or may not be a feature request,
however I and several others regard the subject issue as excessively disruptive
to "repeat editing" workflow, and completely unacceptable. I've sometimes
actually exported WAV and used other editors in order to be free of it.

Comment 1 Gale Andrews 2010-04-15 13:30:34 UTC

RA "The current design of horizontal scrolling of the waveform in Audacity is Very irritating for repeated zoomed-in editing at one spot.  When you click space to playback audio the position of cursor and scrolling on the far left means that you don't have the context of the starting point shown.  We know we want to change this to improve close up editing, but haven't had time to do so for this release.

Comment 2 Gale Andrews 2010-05-13 16:11:54 UTC

Another consideration is what should happen if you play a region that isn't in view (say if you drew a region, then dragged the horizontal scrollbar). Play will 
move the view so that the region starts at the extreme left edge of the waveform.
Some people might want the cursor to be centred in the view; others may want it to be a little offset from the left edge.

Comment 3 Gale Andrews 2010-10-06 10:22:10 UTC

Another irritating scenario. If you add a label at the playback position, leave the label open for editing, let playback go past the scroll and then use the shortcut for "Add Label at Playback Position", the view resets to start at the position the label is added at. Using the menu item to add the label does not cause this. If you use the shortcut to add another label before the next scroll, the view won't be reset.

If you use the shortcut to add a label at the same time or immediately after the scroll occurs, the effect of both resets can push the view position further to left and the label will be added off screen. 

Users on OS X have reported that when this shortcut resets view to the position the label was added at, the playback cursor becomes desynchronised with the audio being played (Bug 105). The desync can be cured by adding another label within the scroll.

Comment 4 Gale Andrews 2016-08-01 13:45:49 UTC

Added dependency on bug 1292 and added the bug 1292 issue to this release note.

Removed from this release note that playback cannot scroll continuously.

Comment 5 Peter Sampson 2017-08-05 11:20:47 UTC

(In reply to Gale Andrews from comment #4)

This thread is not really a bug - it is a design discussion, and as such properly belongs in a Wiki Proposal not here in Bugzilla.

I propose that we Close this bug

Bug #1292 still stands though.

Comment 6 James Crook 2017-08-05 11:44:47 UTC

Removed dependency on 1292

CLOSED INVALID

It's as Peter says in Comment #5 a design discussion, and there is now a page for that on the talk page of this wiki page:
http://wiki.audacityteam.org/wiki/Proposal_Zoom_Context

It can be argued that the pinned mode of editing now fixes the main 'issue'.