locked Play Region/cursor

Forum-related announcements, polls, et al.
steve
Site Admin
Posts: 48200
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu

Re: locked Play Region/cursor

Post by steve » Thu Apr 30, 2015 1:35 am

Gale Andrews wrote:I quite like the idea of the extra downward pointing grey "play from" position though we would want that also when there is no selection region.
Yes, the "play position" icon would always indicate the "play position".
Gale Andrews wrote:How does user enable the play speed slider and how do we make that discoverable?
In the long term I would hope that we make much more use of right click context menus, to the extent that it becomes normal to right click on things.
In the short term there could be one of those little downward pointing triangles like we have in the Meter Toolbars.
Gale Andrews wrote:
steve wrote:Conceptually I think it makes no sense to "lock" the "current play position" because it is transient by its nature.
It's useful though, and it would be a feature that we never had before, given 2.1.0 could only "lock the static cursor position as a play region".
You misunderstand my meaning.
It makes little sense to "lock" as in "lock up / prevent from moving / disable.
Gale Andrews wrote:The case is clear to me in 2.1.0. "Lock the static cursor position as a play region" then ...
We will never agree about that. There are just too many contradictions for my poor little head to get round.
Gale Andrews wrote:One advantage of a separate Play button for Transcription Toolbar is the ease of switching between standard 1x and an already determined "transcription speed". In Steve's mockup:
Image
I could envisage the black "1.0" being a separate Play button for that indicated speed and that the main Play button still always plays at 1x.
That's a neat idea that nicely works around one of the main problems in the idea.
Gale Andrews wrote:Disagree that the selection should never have anything to do with the length of the recording. The current "solution" works for me where overdub ties the recording to the selection but recording always starts from the cursor position even if overdub is off.
It looks wrong to me. If I lock a region, then it plays the locked play region, but if I make an overdub it plays a different region. What's the logic?
Gale Andrews wrote:I am not sure if you are saying that we should require setting the playback start/region or recording start/region when we simply want to play or record as we do now, but I would like the locked recording start/region to an additional but not mandatory feature.
I'm saying that when you start the transport, it always starts from the current play position, and if there is a "play region" defined then the cursor always traverses the play region. I think that would be far preferable than having different behaviours for play, record, loop and overdub (as we have now).
9/10 questions are answered in the FREQUENTLY ASKED QUESTIONS (FAQ)

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

Re: locked Play Region/cursor

Post by Gale Andrews » Thu Apr 30, 2015 9:46 am

steve wrote:
Gale Andrews wrote:
steve wrote:Conceptually I think it makes no sense to "lock" the "current play position" because it is transient by its nature.
It's useful though, and it would be a feature that we never had before, given 2.1.0 could only "lock the static cursor position as a play region".
You misunderstand my meaning.
It makes little sense to "lock" as in "lock up / prevent from moving / disable.
I did not think you meant to suggest locking the playhead - there is zero sense in that, indeed Peter objected to Transport > Lock nomenclature because it could be misconstrued as meaning that.

My suggestion was that when the playhead was moving without the presence of a Quick-Play region, your Transport > Lock set a "play from" lock at the current playhead position while the playhead continued (analogous to what happens when you lock a play region when that region is playing - the playhead continues).
steve wrote:
Gale Andrews wrote:The case is clear to me in 2.1.0. "Lock the static cursor position as a play region" then ...
We will never agree about that. There are just too many contradictions for my poor little head to get round.
I dealt individually with all the "contradictions" you listed. When standard SHIFT + SPACE loops from the cursor I understood that your main objection would be met.

That remaining (to me very minor) objection about consistency would occur if user was allowed to drag a locked "play from" point.

To me, there are more contradictions/lack of analogy (plus a feature regression) in not providing a defined play from lock.

We do not force user wanting to standard play from 2s to the end of the track to create a waveform selection to do so. So we should not force user wanting to lock play from 2s to the end of the track to create a waveform selection to do so.
steve wrote:
Gale Andrews wrote:One advantage of a separate Play button for Transcription Toolbar is the ease of switching between standard 1x and an already determined "transcription speed". In Steve's mockup I could envisage the black "1.0" being a separate Play button for that indicated speed and that the main Play button still always plays at 1x.
That's a neat idea that nicely works around one of the main problems in the idea.
If so, would the Play-at-speed slider be enabled all the time (when the Play at Speed button was visible)? That might however make people think the slider was "not working" when using the standard Play button.

If the slider is only enabled when the Play-at-Speed button is depressed, then that means you can only change the slider position when playing-at-speed. Perhaps you might be allowed to double-click the slider to open the speed adjustment dialog, but the slider remains disabled on exiting the speed adjustment box unless the Play-at-speed slider was depressed?
steve wrote:
Gale Andrews wrote:Disagree that the selection should never have anything to do with the length of the recording. The current "solution" works for me where overdub ties the recording to the selection but recording always starts from the cursor position even if overdub is off.
It looks wrong to me. If I lock a region, then it plays the locked play region, but if I make an overdub it plays a different region. What's the logic?
If we agree that the "Transport > Lock" locks the record region, then I would assume that overdub recording plays the locked region (and needless to say if there was a locked "play from" point I would have it play from the locked "play from" point to the end of the track).

All I am saying is that if there is no locked "play from" point or locked region then I expect record to do as now, and not to have to lock an existing selection region first before I can overdub record to that selection.
steve wrote:
Gale Andrews wrote:I am not sure if you are saying that we should require setting the playback start/region or recording start/region when we simply want to play or record as we do now, but I would like the locked recording start/region to an additional but not mandatory feature.
I'm saying that when you start the transport, it always starts from the current play position, and if there is a "play region" defined then the cursor always traverses the play region. I think that would be far preferable than having different behaviours for play, record, loop and overdub (as we have now).
I think there is consensus (at least us two) about what Loop Play should do.

I don't think non-overdub recording continuing past the selection is unreasonable - it saves having to unset a selection that you may not want to unset. If user wants to non-overdub record to the selection, then with your suggested feature they could Transport > Lock that waveform selection.

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

steve
Site Admin
Posts: 48200
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu

Re: locked Play Region/cursor

Post by steve » Thu Apr 30, 2015 9:51 am

Gale Andrews wrote:I did not think you meant to suggest locking the playhead - there is zero sense in that,
Yes, that's what I meant - there is zero sense in that. ;)
9/10 questions are answered in the FREQUENTLY ASKED QUESTIONS (FAQ)

steve
Site Admin
Posts: 48200
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu

Re: locked Play Region/cursor

Post by steve » Thu Apr 30, 2015 10:12 am

Gale Andrews wrote:If the slider is only enabled when the Play-at-Speed button is depressed,
No, I didn't suggest that, and I think that would be far too limited. If we were to do that then there's little point in putting the speed slider into the Control Toolbar.

What I agree is a good idea is providing an extra button (actually I think a "double" button" would be better) to instigate playing at the selected speed so that the "normal" play button can always instigate playback at 1x speed. If you adjust the speed control while Audacity is playing (but we agreed, not recording), then the playback speed is controlled.

The "double button" I have in mind would be:

< x1.0 >

where
">" is a right pointing green triangle to instigate playing forwards
"<" is a left pointing green triangle to instigate playing backwards
"x1.0" is the current speed (either forward or reverse).

On pressing the normal Play button, the "current speed" would change to "x1.0", and on Stop would revert to its previous setting.
On pressing the Record button, the "current speed" would change to "x1.0" and would be greyed out, and the slider indicator would also be greyed out. On "Stop" the "current speed" and slider indicator would be re-enabled at their previous values.
On scrub playback, the slider would change the speed of scrub play (along with whatever mechanism, such as mouse wheel control, that Paul decides to add).
9/10 questions are answered in the FREQUENTLY ASKED QUESTIONS (FAQ)

steve
Site Admin
Posts: 48200
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu

Re: locked Play Region/cursor

Post by steve » Thu Apr 30, 2015 10:41 am

Gale Andrews wrote:If we agree that the "Transport > Lock" locks the record region, then I would assume that overdub recording plays the locked region (and needless to say if there was a locked "play from" point I would have it play from the locked "play from" point to the end of the track).
Yes.

I don't see a strong case for locking the record region. In common cases there is no need to do so, but I see little reason to not allow it, and if we do allow it then I think that it should behave in the same way as during other transport modes.
Gale Andrews wrote:All I am saying is that if there is no locked "play from" point or locked region then I expect record to do as now, and not to have to lock an existing selection region first before I can overdub record to that selection.
Yes. If there is no play region defined, then play, record, loop play, scrub and reverse playback, all play from the current play position. There is always a current play position (assuming the project is not empty), so always a "play position" arrow - green during playback, red during record, and grey when not playing or recording (stopped).
Gale Andrews wrote:I don't think non-overdub recording continuing past the selection is unreasonable
Completely agree - in fact, more than agree - I think the fact that it stops at the end of the selection is a bug.
Gale Andrews wrote:If user wants to non-overdub record to the selection, then with your suggested feature they could Transport > Lock that waveform selection.
Yes, but, we have a decision to make...

If a "play region" is to consistently handle the transport range (start / end positions), then, if defined, it "should" (logically) determine the start / end positions for a recording.
There are two alternative ways that come to mind for dealing with this.
Either:

A) If you want a continuous recording, you can't have a selection (because drawing a selection automatically produces a play region). I'm not keen on this because it would be too easy, especially for those familiar with previous versions) to forget, and thereby have their recording stopped prematurely.

B) On starting recording, the play region is temporarily removed, unless locked, and restored when the user stops the recording. If the play region is locked, then it's locked and recording is confined to the defined region. I prefer this solution.
9/10 questions are answered in the FREQUENTLY ASKED QUESTIONS (FAQ)

steve
Site Admin
Posts: 48200
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu

Re: locked Play Region/cursor

Post by steve » Thu Apr 30, 2015 11:22 am

Gale Andrews wrote:To me, there are more contradictions/lack of analogy (plus a feature regression) in not providing a defined play from lock.
I don't disagree with the "functionality" that you want. In fact I agree.

What I disagree about is how we achieve that functionality. Currently we have a mishmash of features that have been "bolted on" over the years, resulting in a labyrinth of "conditional" statements in the code, and many inconsistencies. This has not been a major problem in the past, because it does what it does and we have all grown used to it, but the cracks are becoming apparent as the transport system is now being developed further with the Quick-Play enhancements and Paul's scrub & seek behaviours.

What I'm trying to do is to tease apart the transport system so that it can be put back together with a unified and consistent underlying scheme. Locking a "play from" position can fit in that scheme, but not the way were previously doing it. What we were previously doing was to actually lock a zero length play region, and because that makes no sense, ignoring the lock and just playing from the current play position. What we need to do to provide this feature is to separate the "play position" from the "transport start / end" positions. Then we can (probably) lock the transport start (the left arrow of the |<====>| region) even without defining the transport end (the right arrow) - this is what we normally do when recording.

Precisely how we expose the features through the GUI is another question, but I don't want to get tied up in arguing about the final menu names before we've worked out exactly what it is doing. One "possibility" is that rather than having "Play region > Lock/Unlock" we could have "Transport lock > Unlocked/Lock Start/Lock End/Lock Region" where "unlocked/start/end/region" are radio buttons (default = unlocked). "Lock Region" would be greyed out unless there was an actual "region" to lock.

To throw in another piece of this puzzle: "Append Record".
9/10 questions are answered in the FREQUENTLY ASKED QUESTIONS (FAQ)

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

Re: locked Play Region/cursor

Post by Gale Andrews » Fri May 01, 2015 2:58 am

Gale Andrews wrote:
steve wrote:
Gale Andrews wrote:Related, do you intend that when you drag from the arrows of a locked play region, it plays the dragged piece plus the entire locked region, or that when you click above either arrow, it plays the locked region? That seems to give no way to quick-play from where you clicked - how about doing that if you clicked above the locked arrows?
Wow, this really is a fringe case. I intend to keep it as simple as possible - if you activate a play region, then the play region plays.

If you want to play from the start of a locked play region to beyond the end of the locked play region, drag the right hand edge of the play region to the right. On mouse up, the play region starts playing from the start of the region and stops at the mouse-up position. If Shift is held down while you do this, then loop play starts from the start of the region and loops when it reaches the mouse-up position.
So it was what you intended. I agree it's handy but it was unexpected to me because the mouse pointer did not change when over the locked region's arrow to indicate that when I started dragging the Quick-Play region it would not start from where I dragged.

It may not be merely a fringe case. We have had users on this Forum who want to Quick-Play from the exact edge of a Quick-Play region/position: http://bugzilla.audacityteam.org/show_bug.cgi?id=704 which you have worked on.

Plus, if I move the mouse pointer in the Timeline to just beyond the edge of a locked Play Region (so that the tip of the green triangle is demonstrably to right of the locked region arrow), then click, it still plays the locked region. What is the rule here to Quick-Play from where you click - that no part of the green triangle that moves with the mouse pointer must be over the edge of the locked Play Region?
This is much better now, Steve, in terms of the pointer icons predicting what will happen. Thanks.

It's still true that you can't Quick-Play from a point exactly at (or very close to) the boundary of a Quick-Play region, but that's a feature request.

A solution to "Enable dragging selection" when there isn't a drag would be good. We see this too with replaying an already dragged Quick-Play region. Drag in the Timeline, release mouse then left-click to replay and a selection is drawn from editing cursor or right edge of waveform selection to right edge of Quick-Play region.

On mouse up, the selection''s left edge moves to the left edge of the Quick-Play region. The left-click was not a drag, because I was using a mouse emulator and it left-clicked at the exact same place I released the drag.


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

waxcylinder
Forum Staff
Posts: 9580
Joined: Tue Jul 31, 2007 11:03 am
Operating System: Windows 10

Re: locked Play Region/cursor

Post by waxcylinder » Fri May 01, 2015 8:35 am

steve wrote:What I'm trying to do is to tease apart the transport system so that it can be put back together with a unified and consistent underlying scheme ...

Precisely how we expose the features through the GUI is another question, but I don't want to get tied up in arguing about the final menu names before we've worked out exactly what it is doing. ...
Since we are now at 1May with "official" alpha testing about to commence does this mean that we are unlikely to see the further changes that Steve is alluding to here in for 2.1.1?

I.e. is what we have now for Timeline/TQP what will be delivered, apart from any required bug fixes, with further work to be delivered in 2.1.2?

Peter
________________________________________FOR INSTANT HELP: (Click on Link below)
* * * * * FAQ * * * * * Tutorials * * * * * Audacity Manual * * * * * Audacity Wiki * * * * *

steve
Site Admin
Posts: 48200
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu

Re: locked Play Region/cursor

Post by steve » Fri May 01, 2015 9:29 am

The handling of behaviours when very close to the start/end of the play region is much better, but still not quite right. I intend to fix that in time for 2.1.1 release, and if successful and is still time, I would like to implement ("normal") loop play from the cursor position. There won't be time to tackle much more than that for 2.1.1.
9/10 questions are answered in the FREQUENTLY ASKED QUESTIONS (FAQ)

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

Re: locked Play Region/cursor

Post by Gale Andrews » Mon May 04, 2015 7:55 am

steve wrote:
Gale Andrews wrote:If the slider is only enabled when the Play-at-Speed button is depressed,
No, I didn't suggest that, and I think that would be far too limited. If we were to do that then there's little point in putting the speed slider into the Control Toolbar.
There is one benefit if Paul uses the Transcription Toolbar speed to set initial scrubbing speed - the connection between the two is much more discoverable.
steve wrote:What I agree is a good idea is providing an extra button (actually I think a "double" button" would be better) to instigate playing at the selected speed so that the "normal" play button can always instigate playback at 1x speed. If you adjust the speed control while Audacity is playing (but we agreed, not recording), then the playback speed is controlled.
So we would have to fix these two bugs first:
steve wrote: The "double button" I have in mind would be:

< x1.0 >

where
">" is a right pointing green triangle to instigate playing forwards
"<" is a left pointing green triangle to instigate playing backwards
"x1.0" is the current speed (either forward or reverse).

On pressing the normal Play button, the "current speed" would change to "x1.0", and on Stop would revert to its previous setting.
On pressing the Record button, the "current speed" would change to "x1.0" and would be greyed out, and the slider indicator would also be greyed out. On "Stop" the "current speed" and slider indicator would be re-enabled at their previous values.
Sorry but I'm still not clear which is the normal play button on the < x1.0 > double button and how the arrow buttons enable direction of playback for both 1.x and modified speed.

And we would still have the issue that you could knock the speed slider accidentally during 1x playback, if I'm understanding you correctly - unless we were to provide a lock control on the speed slider (that could be useful to lock any speed, not just 1x).
steve wrote:On scrub playback, the slider would change the speed of scrub play (along with whatever mechanism, such as mouse wheel control, that Paul decides to add).
You mean, the play speed slider would control the initial speed of scrub play, as now?


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

Locked