Seeking behind cursor after initiating normal playback?

[Andy Coder]

Gale informed me that users want to do this, so I've spent some time trying to work it out, with mixed success.

To clarify, the scenario I've been looking at is when the cursor is at a position in the project, there are tracks to be played, the cursor is at neither the start nor the end, and a region is not selected.  The play button or space bar is used to start playback.  Currently, playback starts at the cursor, but the left arrow key can't be used to seek to audio preceding the cursor.

My approach was to change the way that the ControlToolbar's PlayPlayRegion() computes the region to play when the start and end points it's given are equal, so long as we're not playing in looped mode.  The function, as is, starts a stream that consists of the audio from the cursor to the end, so I thought seeking behind the cursor without changing this wouldn't make sense, since the preceding audio isn't part of the stream.  My change was to add an 'init_seek' variable, which is set to what would be the beginning of the stream, set the beginning of the stream to the beginning of the track, and attempt to have StartStream() use init_seek to adjust the position of the initial playback, while keeping the preceding audio as part of the stream.  (Give the stream the entire project, but tell it to immediately seek to the cursor).

I tried a few different options, but they all were similar, (and behaved exactly like), the attached patch.  That is, all builds and appears to run as expected, except that now, when in the above situation, playback starts at the beginning, the cursor remains in place, and seeking is possible with arrow keys throughout the project.  So, as far as I can tell, the stream must contain the entire range of the project, but I'm lacking a good grip on how to coax out that initial seek.

- Andy Coder

------------------------------------------------------------------------------

_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Hi Andy

This sounds to me like a good approach, and just needs a little more
work (but I haven't tried it).

There must be a method of moving the 'play head' that is implemented
when we use the left/right arrow keys that can be re-used to position
the 'play' position for the initial seek?

Not very useful I know, but I encourage you to keep looking!

TTFN
Martyn

Andy Coder wrote:

> Gale informed me that users want to do this, so I've spent some time
> trying to work it out, with mixed success.
>
> To clarify, the scenario I've been looking at is when the cursor is at a
> position in the project, there are tracks to be played, the cursor is at
> neither the start nor the end, and a region is not selected.  The play
> button or space bar is used to start playback.  Currently, playback
> starts at the cursor, but the left arrow key can't be used to seek to
> audio preceding the cursor.
>
> My approach was to change the way that the ControlToolbar's
> PlayPlayRegion() computes the region to play when the start and end
> points it's given are equal, so long as we're not playing in looped
> mode.  The function, as is, starts a stream that consists of the audio
> from the cursor to the end, so I thought seeking behind the cursor
> without changing this wouldn't make sense, since the preceding audio
> isn't part of the stream.  My change was to add an 'init_seek' variable,
> which is set to what would be the beginning of the stream, set the
> beginning of the stream to the beginning of the track, and attempt to
> have StartStream() use init_seek to adjust the position of the initial
> playback, while keeping the preceding audio as part of the stream.  
> (Give the stream the entire project, but tell it to immediately seek to
> the cursor).
>
> I tried a few different options, but they all were similar, (and behaved
> exactly like), the attached patch.  That is, all builds and appears to
> run as expected, except that now, when in the above situation, playback
> starts at the beginning, the cursor remains in place, and seeking is
> possible with arrow keys throughout the project.  So, as far as I can
> tell, the stream must contain the entire range of the project, but I'm
> lacking a good grip on how to coax out that initial seek.
>
> - Andy Coder
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Andy Coder]

This new patch works for me, and is simpler and less invasive.

- Andy Coder

Index: src/toolbars/ControlToolBar.cpp
===================================================================
RCS file: /cvsroot/audacity/audacity-src/src/toolbars/ControlToolBar.cpp,v
retrieving revision 1.36
diff -u -r1.36 ControlToolBar.cpp
--- src/toolbars/ControlToolBar.cpp    28 Mar 2009 05:14:47 -0000    1.36
+++ src/toolbars/ControlToolBar.cpp    1 Apr 2009 00:27:46 -0000
@@ -439,6 +439,7 @@
    }
 
    double maxofmins,minofmaxs;
+   double init_seek = 0.0;
   
    // JS: clarified how the final play region is computed;
    if (t1 == t0) {
@@ -449,10 +450,16 @@
          t0 = t->GetStartTime();
       } else {
          // move t0 to valid range
-         if (t0 < 0)
+         if (t0 < 0) {
             t0 = t->GetStartTime();
-         if (t0 > t->GetEndTime())
+         }
+         else if (t0 > t->GetEndTime()) {
             t0 = t->GetEndTime();
+         }
+         else {
+            init_seek = t0;         //AC: init_seek is where playback will 'start'
+            t0 = t->GetStartTime();
+         }
       }
      
       // always play to end
@@ -532,6 +539,8 @@
          success = true;
          p->SetAudioIOToken(token);
          mBusyProject = p;
+         //AC: If init_seek was set, now's the time to make it happen.
+         gAudioIO->SeekStream(init_seek);
          SetVUMeters(p);
       }
       else {

On Tue, Mar 31, 2009 at 8:03 PM, Martyn Shaw <[hidden email]> wrote:

Hi Andy

This sounds to me like a good approach, and just needs a little more
work (but I haven't tried it).

There must be a method of moving the 'play head' that is implemented
when we use the left/right arrow keys that can be re-used to position
the 'play' position for the initial seek?

Not very useful I know, but I encourage you to keep looking!

TTFN
Martyn

Andy Coder wrote:
> Gale informed me that users want to do this, so I've spent some time
> trying to work it out, with mixed success.
>
> To clarify, the scenario I've been looking at is when the cursor is at a
> position in the project, there are tracks to be played, the cursor is at
> neither the start nor the end, and a region is not selected.  The play
> button or space bar is used to start playback.  Currently, playback
> starts at the cursor, but the left arrow key can't be used to seek to
> audio preceding the cursor.
>
> My approach was to change the way that the ControlToolbar's
> PlayPlayRegion() computes the region to play when the start and end
> points it's given are equal, so long as we're not playing in looped
> mode.  The function, as is, starts a stream that consists of the audio
> from the cursor to the end, so I thought seeking behind the cursor
> without changing this wouldn't make sense, since the preceding audio
> isn't part of the stream.  My change was to add an 'init_seek' variable,
> which is set to what would be the beginning of the stream, set the
> beginning of the stream to the beginning of the track, and attempt to
> have StartStream() use init_seek to adjust the position of the initial
> playback, while keeping the preceding audio as part of the stream.
> (Give the stream the entire project, but tell it to immediately seek to
> the cursor).
>
> I tried a few different options, but they all were similar, (and behaved
> exactly like), the attached patch.  That is, all builds and appears to
> run as expected, except that now, when in the above situation, playback
> starts at the beginning, the cursor remains in place, and seeking is
> possible with arrow keys throughout the project.  So, as far as I can
> tell, the stream must contain the entire range of the project, but I'm
> lacking a good grip on how to coax out that initial seek.
>
> - Andy Coder
>
>

> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------

_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[André Pinto]

Hi Andy,

I've tested it here and it's working.

Nice patch!

André.

On Wed, Apr 1, 2009 at 1:30 AM, Andy Coder <[hidden email]> wrote:

This new patch works for me, and is simpler and less invasive.

- Andy Coder

Index: src/toolbars/ControlToolBar.cpp
===================================================================
RCS file: /cvsroot/audacity/audacity-src/src/toolbars/ControlToolBar.cpp,v
retrieving revision 1.36
diff -u -r1.36 ControlToolBar.cpp
--- src/toolbars/ControlToolBar.cpp    28 Mar 2009 05:14:47 -0000    1.36
+++ src/toolbars/ControlToolBar.cpp    1 Apr 2009 00:27:46 -0000
@@ -439,6 +439,7 @@
    }
 
    double maxofmins,minofmaxs;
+   double init_seek = 0.0;
   
    // JS: clarified how the final play region is computed;
    if (t1 == t0) {
@@ -449,10 +450,16 @@
          t0 = t->GetStartTime();
       } else {
          // move t0 to valid range
-         if (t0 < 0)
+         if (t0 < 0) {
             t0 = t->GetStartTime();
-         if (t0 > t->GetEndTime())
+         }
+         else if (t0 > t->GetEndTime()) {
             t0 = t->GetEndTime();
+         }
+         else {
+            init_seek = t0;         //AC: init_seek is where playback will 'start'
+            t0 = t->GetStartTime();
+         }
       }
      
       // always play to end
@@ -532,6 +539,8 @@
          success = true;
          p->SetAudioIOToken(token);
          mBusyProject = p;
+         //AC: If init_seek was set, now's the time to make it happen.
+         gAudioIO->SeekStream(init_seek);
          SetVUMeters(p);
       }
       else {

On Tue, Mar 31, 2009 at 8:03 PM, Martyn Shaw <[hidden email]> wrote:

Hi Andy

This sounds to me like a good approach, and just needs a little more
work (but I haven't tried it).

There must be a method of moving the 'play head' that is implemented
when we use the left/right arrow keys that can be re-used to position
the 'play' position for the initial seek?

Not very useful I know, but I encourage you to keep looking!

TTFN
Martyn

Andy Coder wrote:
> Gale informed me that users want to do this, so I've spent some time
> trying to work it out, with mixed success.
>
> To clarify, the scenario I've been looking at is when the cursor is at a
> position in the project, there are tracks to be played, the cursor is at
> neither the start nor the end, and a region is not selected.  The play
> button or space bar is used to start playback.  Currently, playback
> starts at the cursor, but the left arrow key can't be used to seek to
> audio preceding the cursor.
>
> My approach was to change the way that the ControlToolbar's
> PlayPlayRegion() computes the region to play when the start and end
> points it's given are equal, so long as we're not playing in looped
> mode.  The function, as is, starts a stream that consists of the audio
> from the cursor to the end, so I thought seeking behind the cursor
> without changing this wouldn't make sense, since the preceding audio
> isn't part of the stream.  My change was to add an 'init_seek' variable,
> which is set to what would be the beginning of the stream, set the
> beginning of the stream to the beginning of the track, and attempt to
> have StartStream() use init_seek to adjust the position of the initial
> playback, while keeping the preceding audio as part of the stream.
> (Give the stream the entire project, but tell it to immediately seek to
> the cursor).
>
> I tried a few different options, but they all were similar, (and behaved
> exactly like), the attached patch.  That is, all builds and appears to
> run as expected, except that now, when in the above situation, playback
> starts at the beginning, the cursor remains in place, and seeking is
> possible with arrow keys throughout the project.  So, as far as I can
> tell, the stream must contain the entire range of the project, but I'm
> lacking a good grip on how to coax out that initial seek.
>
> - Andy Coder
>
>

> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------

_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------

_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Leland (Audacity Team)]

Andy Coder wrote:
> This new patch works for me, and is simpler and less invasive.
>
Really cool idea Andy and a nice small patch to make it happen.
Consider this though.  What if the user wishes to not seek past the
starting point?  What if they are listening to the first bit of audio
and keep hitting the left arrow to hear it again.  Hitting it too much
would possibly go to far back.

Okay, not a very good scenario or even a very big thing to worry about.
  Just give it some brain activity and see if you think it's important.
  Either way, I think we should probably apply your patch, but I'll
leave that up to Martyn or Michael.

Leland


------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Michael Chinen]

Hi Andy,

Looks good!
This patch looks like a big improvement over the last one.  It was nice to see that.  I've committed your patch.

About Leland's comment:

On Tue, Mar 31, 2009 at 10:14 PM, Leland <[hidden email]> wrote:

Andy Coder wrote:
> This new patch works for me, and is simpler and less invasive.
>

Really cool idea Andy and a nice small patch to make it happen.
Consider this though.  What if the user wishes to not seek past the
starting point?  What if they are listening to the first bit of audio
and keep hitting the left arrow to hear it again.  Hitting it too much
would possibly go to far back.

This was a small concern for me too because it is something I find myself doing.  But, I realized that when I want that behavior, I just hit the spacebar twice, because it pauses then restarts.  It is different: two button presses, and a pause in between, but I think the continuous audio/pause factor is incidental.

The other thing I wanted to mention is just to clarify that the de-niggling aspect for our GSoC is not limited to just new features.  Code optimization (to make things run faster or smoother) or refactoring/cleaning, or small UI touchup is also a possibility.  Of course, you should explore whatever your interests are on your application–I just want you to know these are other possibilities.

I noticed when testing your patch that would be a good example of a UI touchup.  Even if the cursor is in the middle of the track and you hit play, sometimes the green cursor appears at the beginning of the track for a split second.  This does not affect playback behavior, so it's probably not a bug.  But I have noticed it before and it struck me as odd until I forgot about it again.  Stuff like this is 'polish' in my opinion.

Lastly, when it is new features, it should probably be features that are small tweaks to the UI, (this patch is a good example,) instead of brand new UI ideas (e.g. probably not a real-time per track zoom slider and definitely not an audio diff, even if it is really cool) 

Michael

Okay, not a very good scenario or even a very big thing to worry about.
 Just give it some brain activity and see if you think it's important.
 Either way, I think we should probably apply your patch, but I'll
leave that up to Martyn or Michael.

Leland


------------------------------------------------------------------------------

_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------

_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Andy Coder]

On Wed, Apr 1, 2009 at 12:40 AM, Michael Chinen <[hidden email]> wrote:

Hi Andy,

Looks good!
This patch looks like a big improvement over the last one.  It was nice to see that.  I've committed your patch.

 

Thanks! (*excited*) I've envied folks contributing to open source projects since I was 12, (running into Linux for the first time), so it's nice to know I can do something to help.

About Leland's comment:

On Tue, Mar 31, 2009 at 10:14 PM, Leland <[hidden email]> wrote:

Andy Coder wrote:
> This new patch works for me, and is simpler and less invasive.
>

Really cool idea Andy and a nice small patch to make it happen.
Consider this though.  What if the user wishes to not seek past the
starting point?  What if they are listening to the first bit of audio
and keep hitting the left arrow to hear it again.  Hitting it too much
would possibly go to far back.

This was a small concern for me too because it is something I find myself doing.  But, I realized that when I want that behavior, I just hit the spacebar twice, because it pauses then restarts.  It is different: two button presses, and a pause in between, but I think the continuous audio/pause factor is incidental.

It occured to me last night that it might even be reasonable to use the old behavior by default, and allow a modifier to 'unlock' seeking behind the cursor, (ctl + arrow seems unused), or to do the opposite, using the modifier to 'lock' seeking at the cursor.  Since the cursors position is still the start of the selection, it's available to use, and it seems simple enough to allow TrackPanel to trim the mSeek value it passes to SeekStream if the arrow key is (un)modified.  OnCursorMove(), OnCursorLeft(), and OnCursorRight() all spend time figuring mSeek in special cases anyway, so that's all it would take, but I'll need to figure out when each of them is used first, (especially if this seems like a good idea to others, I can poke it some after class).
 

I noticed when testing your patch that would be a good example of a UI touchup.  Even if the cursor is in the middle of the track and you hit play, sometimes the green cursor appears at the beginning of the track for a split second.  This does not affect playback behavior, so it's probably not a bug.  But I have noticed it before and it struck me as odd until I forgot about it again.  Stuff like this is 'polish' in my opinion.

This is also why I originally tried to make it happen in AudioIO, hoping there was a simple way to get the seek to happen before things really got rolling.  I tried playing back a project I had around with 16 tracks and the patch wasn't noticably slower than with 1, so I figured the current solution was at least a good start.  As is, there's nothing in between the call to StartStream() and the call to SeekStream() in ControlToolbar that I think would make an appreciable difference if I put the seek in front of, so any polish likely has to be elsewhere, (something like avoiding drawing the playback cursor/scrolling/setting time things immediately, but that seems like it might be sneaky/dangerous).

- Andy Coder

Lastly, when it is new features, it should probably be features that are small tweaks to the UI, (this patch is a good example,) instead of brand new UI ideas (e.g. probably not a real-time per track zoom slider and definitely not an audio diff, even if it is really cool) 

Michael

Okay, not a very good scenario or even a very big thing to worry about.
 Just give it some brain activity and see if you think it's important.
 Either way, I think we should probably apply your patch, but I'll
leave that up to Martyn or Michael.

Leland


------------------------------------------------------------------------------

_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------

_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------

_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Hi Andy

Thanks for pursuing this, good job!

Andy Coder wrote:

>
> On Wed, Apr 1, 2009 at 12:40 AM, Michael Chinen <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Andy,
>
>     Looks good!
>     This patch looks like a big improvement over the last one.  It was
>     nice to see that.  I've committed your patch.
>
>  
> Thanks! (*excited*) I've envied folks contributing to open source
> projects since I was 12, (running into Linux for the first time), so
> it's nice to know I can do something to help.

It gives you that little warm feeling inside, doesn't it?

>     About Leland's comment:
>
>     On Tue, Mar 31, 2009 at 10:14 PM, Leland <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Andy Coder wrote:
>          > This new patch works for me, and is simpler and less invasive.
>          >
>         Really cool idea Andy and a nice small patch to make it happen.
>         Consider this though.  What if the user wishes to not seek past the
>         starting point?  What if they are listening to the first bit of
>         audio
>         and keep hitting the left arrow to hear it again.  Hitting it
>         too much
>         would possibly go to far back.
>
>     This was a small concern for me too because it is something I find
>     myself doing.  But, I realized that when I want that behavior, I
>     just hit the spacebar twice, because it pauses then restarts.  It is
>     different: two button presses, and a pause in between, but I think
>     the continuous audio/pause factor is incidental.
>
>
> It occured to me last night that it might even be reasonable to use the
> old behavior by default, and allow a modifier to 'unlock' seeking behind
> the cursor, (ctl + arrow seems unused), or to do the opposite, using the
> modifier to 'lock' seeking at the cursor.  Since the cursors position is
> still the start of the selection, it's available to use, and it seems
> simple enough to allow TrackPanel to trim the mSeek value it passes to
> SeekStream if the arrow key is (un)modified.  OnCursorMove(),
> OnCursorLeft(), and OnCursorRight() all spend time figuring mSeek in
> special cases anyway, so that's all it would take, but I'll need to
> figure out when each of them is used first, (especially if this seems
> like a good idea to others, I can poke it some after class).

Given the 'spacebar twice' thing, this doesn't sound worthwhile to me.

TTFN
Martyn

>     I noticed when testing your patch that would be a good example of a
>     UI touchup.  Even if the cursor is in the middle of the track and
>     you hit play, sometimes the green cursor appears at the beginning of
>     the track for a split second.  This does not affect playback
>     behavior, so it's probably not a bug.  But I have noticed it before
>     and it struck me as odd until I forgot about it again.  Stuff like
>     this is 'polish' in my opinion.
>
>
> This is also why I originally tried to make it happen in AudioIO, hoping
> there was a simple way to get the seek to happen before things really
> got rolling.  I tried playing back a project I had around with 16 tracks
> and the patch wasn't noticably slower than with 1, so I figured the
> current solution was at least a good start.  As is, there's nothing in
> between the call to StartStream() and the call to SeekStream() in
> ControlToolbar that I think would make an appreciable difference if I
> put the seek in front of, so any polish likely has to be elsewhere,
> (something like avoiding drawing the playback cursor/scrolling/setting
> time things immediately, but that seems like it might be sneaky/dangerous).
>
> - Andy Coder
>
>
>     Lastly, when it is new features, it should probably be features that
>     are small tweaks to the UI, (this patch is a good example,) instead
>     of brand new UI ideas (e.g. probably not a real-time per track zoom
>     slider and definitely not an audio diff, even if it is really cool)
>
>
>     Michael
>
>
>
>
>         Okay, not a very good scenario or even a very big thing to worry
>         about.
>          Just give it some brain activity and see if you think it's
>         important.
>          Either way, I think we should probably apply your patch, but I'll
>         leave that up to Martyn or Michael.
>
>         Leland
>
>
>         ------------------------------------------------------------------------------
>         _______________________________________________
>         audacity-devel mailing list
>         [hidden email]
>         <mailto:[hidden email]>
>         https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
>     ------------------------------------------------------------------------------
>
>     _______________________________________________
>     audacity-devel mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel