Quantcast

Commands to navigate between clips

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

Gale
Administrator
On 7 April 2017 at 10:21, James Crook <[hidden email]> wrote:

> On 4/7/2017 9:53 AM, David Bailes wrote:
>> James has already suggested that there should also be commands that
>> work in
>> more than one track, and I agree with that. The possibilities for what
>> tracks clip commands work on are obviously:
>> 1. focused track
>> 2. selected tracks
>> 3. all tracks.
>>
>> It's just a question of working out which of these would be useful.
>>
>> David.
>
> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
> all tracks, if none selected'.

That seems reasonable.


Gale


> I am a little concerned at the menus ballooning again as we add more
> options, some of which are extremely useful to VI users but that may be
> overload for sighted users.
>
> The current ideas do seem to be pointing to a Track dialog for VI use.
> Just as we have a Labels editor dialog that was created for VI use, but
> is useful to sighted users too, thinking in terms of a grid based track
> editor may be more fruitful than ballooning of the menus.
>
> --James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

Gale
Administrator
In reply to this post by James Crook
I find the commands to move to the next / previous clip very useful
as a sighted user - remember this is something that is very hard
to do with the mouse, because of "click to merge".

Labels Editor needs lots of work to be fully intuitive so grids aren't
necessarily an easy solution if they are to be more than a two
column list.

If it was easier than it is to restore accessibility on Mac/improve it on
Linux I expect we would rate grids as of somewhat less potential use
than we do now.


Gale


On 7 April 2017 at 15:16, James Crook <[hidden email]> wrote:

> David,
>
> I want Audacity to be accessible for VI users and also accessible for people
> new to the program.
> Both groups benefit from decisions such as logical menu organisation,
> avoidance of repetition, consistency in where on/off commands go.
>
> There is no question that in 2.2.0 the reduced menus are rapidly gaining
> useful new commands.  I'd argue that we should even consider more zoom
> commands, such as Zoom-Max (useful for people who want to edit at the sample
> level) and Zoom-Toggle (which we used to have, and that switches between two
> zoom levels).  Are we at risk of ballooning?  I hope not.  I don't want the
> work I've done on better menus to be wasted.
>
> I also want the UI for both VI users and power users who use the keyboard a
> lot to be excellent.  I wasn't aware that Jaws has issues with grids.  Is
> there a bugzilla issue for that?  I previously saw grids as win-win for VI
> and non VI alike, wherever we have 'lists' of things, e.g. lists of labels,
> lists of tracks, lists of clips, lists of effects.  Potentially they allow
> us to write VI accessible code faster, benefit non VI users at the same
> time, and allow us to then retrofit accessibility onto features currently
> accessed by mouse.  That is how we now have accessible start and stop times
> for labels in the label tracks.  The label track menus invoke the label
> editor dialog to provide that.
>
> --James.
>
>
>
>
>
>
>
> On 4/7/2017 2:02 PM, David Bailes wrote:
>
> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>
> On 4/7/2017 9:53 AM, David Bailes wrote:
>
> James has already suggested that there should also be commands that
> work in
> more than one track, and I agree with that. The possibilities for what
> tracks clip commands work on are obviously:
> 1. focused track
> 2. selected tracks
> 3. all tracks.
>
> It's just a question of working out which of these would be useful.
>
> David.
>
> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
> all tracks, if none selected'.
>
> I am a little concerned at the menus ballooning again as we add more
> options, some of which are extremely useful to VI users but that may be
> overload for sighted users.
>
> These commands are useful for both sighted and VI keyboard users.
> I don't think that the user interface should be optimized for mouse users
> at the expense of keyboard users.
>
>
> The current ideas do seem to be pointing to a Track dialog for VI use.
> Just as we have a Labels editor dialog that was created for VI use, but
> is useful to sighted users too, thinking in terms of a grid based track
> editor may be more fruitful than ballooning of the menus.
>
> I presume that the labels editor was created because it wasn't obvious at
> the time how to make labels accessible in the main window. But making
> labels accessible in the main windows is the far preferable option. See the
> second comment on this article:
> http://chrishofstader.com/the-irony-of-inaccessible-music-technologies/
>
> In addition, primarily because a problem with Jaws, grids are read by
> screen readers with a lot of distracting verbosity. So I don't think that a
> grid editor is the way to go. A comparatively small number of additional
> commands in the menus is far more user friendly.
>
> I certainly don't think that the menus are ballooning, but if they do, then
> maybe there are other options to consider, like the action list in Reaper.
>
> If Audacity wishes to prioritize mouse users over keyboard users, then
> that's its decision, but I don't agree with it.
>
> David.
>
>
> --James.
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

David Bailes-3
In reply to this post by James Crook
On Fri, Apr 7, 2017 at 3:16 PM, James Crook <[hidden email]> wrote:
David,

I want Audacity to be accessible for VI users and also accessible for people new to the program.
Both groups benefit from decisions such as logical menu organisation, avoidance of repetition, consistency in where on/off commands go.

There is no question that in 2.2.0 the reduced menus are rapidly gaining useful new commands.  I'd argue that we should even consider more zoom commands, such as Zoom-Max (useful for people who want to edit at the sample level) and Zoom-Toggle (which we used to have, and that switches between two zoom levels).  Are we at risk of ballooning?  I hope not.  I don't want the work I've done on better menus to be wasted.

I also want the UI for both VI users and power users who use the keyboard a lot to be excellent.  I wasn't aware that Jaws has issues with grids.  Is there a bugzilla issue for that?

The problem of how screen readers read the grids occurred a while back. Originally, in the accessibility interface the role of the cells was cell. However, Jaws stopped supporting that role (no idea why). So Leland changed the role to text - the only other alternative that got Jaws to read the contents of a cell. However this is far from ideal, as screen readers present all the cells as if they are text boxes, along with erroneous instructions on how to edit them. This issue isn't logged on Bugzilla - it's essentially a Jaws problem, and my guess it would be a very low priority for them to fix.  

 
  I previously saw grids as win-win for VI and non VI alike, wherever we have 'lists' of things, e.g. lists of labels, lists of tracks, lists of clips, lists of effects.  Potentially they allow us to write VI accessible code faster,

But just as for the mouse interactions, the keyboard interactions should be user friendly. Just making things accessible, though tedious to use is not good enough. Lists may be useful for some tasks, but they aren't in general sufficient on their own. For example, if a user want to navigate to some point, eg a label, clip boundary, or an envelope point. If they can do this in the main window, then they have immediate access to playback to check where they are, and they can do so with a small number of keystrokes. If they have to use a dialog, this involves more keystrokes. Here's one reaction to the label commands that were added in 2.1.3:

benefit non VI users at the same time, and allow us 
to then retrofit accessibility onto features currently accessed by mouse. 
 
 
That is how we now have accessible start and stop times for labels in the label tracks.  The label track menus invoke the label editor dialog to provide that.

As I've said above, lists may be useful for some tasks. But you can't just provide a list for something, and think that this alone will make something usefully accessible.

David.


--James.







On 4/7/2017 2:02 PM, David Bailes wrote:
On Fri, Apr 7, 2017 at 10:21 AM, James Crook [hidden email] wrote:

On 4/7/2017 9:53 AM, David Bailes wrote:
James has already suggested that there should also be commands that
work in
more than one track, and I agree with that. The possibilities for what
tracks clip commands work on are obviously:
1. focused track
2. selected tracks
3. all tracks.

It's just a question of working out which of these would be useful.

David.
Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
all tracks, if none selected'.

I am a little concerned at the menus ballooning again as we add more
options, some of which are extremely useful to VI users but that may be
overload for sighted users.

These commands are useful for both sighted and VI keyboard users.
I don't think that the user interface should be optimized for mouse users
at the expense of keyboard users.


The current ideas do seem to be pointing to a Track dialog for VI use.
Just as we have a Labels editor dialog that was created for VI use, but
is useful to sighted users too, thinking in terms of a grid based track
editor may be more fruitful than ballooning of the menus.
I presume that the labels editor was created because it wasn't obvious at
the time how to make labels accessible in the main window. But making
labels accessible in the main windows is the far preferable option. See the
second comment on this article:
http://chrishofstader.com/the-irony-of-inaccessible-music-technologies/

In addition, primarily because a problem with Jaws, grids are read by
screen readers with a lot of distracting verbosity. So I don't think that a
grid editor is the way to go. A comparatively small number of additional
commands in the menus is far more user friendly.

I certainly don't think that the menus are ballooning, but if they do, then
maybe there are other options to consider, like the action list in Reaper.

If Audacity wishes to prioritize mouse users over keyboard users, then
that's its decision, but I don't agree with it.

David.


      

      
--James.



------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

David Bailes-3
In reply to this post by James Crook
On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
On 4/7/2017 9:53 AM, David Bailes wrote:
> James has already suggested that there should also be commands that
> work in
> more than one track, and I agree with that. The possibilities for what
> tracks clip commands work on are obviously:
> 1. focused track
> 2. selected tracks
> 3. all tracks.
>
> It's just a question of working out which of these would be useful.
>
> David.

Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
all tracks, if none selected'.

This probably mainly of interest to Robert. I've implemented James' suggestion of   'All selected tracks, or
all tracks, if none selected' for the cursor to clip boundaries, and select to clip boundaries. It's available in the clipnavbnd branch in my fork of Audacity.

David.


I am a little concerned at the menus ballooning again as we add more
options, some of which are extremely useful to VI users but that may be
overload for sighted users.

The current ideas do seem to be pointing to a Track dialog for VI use.
Just as we have a Labels editor dialog that was created for VI use, but
is useful to sighted users too, thinking in terms of a grid based track
editor may be more fruitful than ballooning of the menus.

--James.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

David Bailes-3
On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]> wrote:
On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
On 4/7/2017 9:53 AM, David Bailes wrote:
> James has already suggested that there should also be commands that
> work in
> more than one track, and I agree with that. The possibilities for what
> tracks clip commands work on are obviously:
> 1. focused track
> 2. selected tracks
> 3. all tracks.
>
> It's just a question of working out which of these would be useful.
>
> David.

Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
all tracks, if none selected'.

This probably mainly of interest to Robert. I've implemented James' suggestion of   'All selected tracks, or
all tracks, if none selected' for the cursor to clip boundaries, and select to clip boundaries. It's available in the clipnavbnd branch in my fork of Audacity.

I've updated the behaviour of the six commands listed below so that if any audio tracks are selected, the clips in those tracks are used, otherwise the clips in all audio tracks are used:
Cursor to Previous clip boundary
Cursor to Next clip boundary
Select previous clip boundary to cursor
Select cursor to next clip boundary
Select Previous Clip
Select Next clip

relevant commits:

David.


David.


I am a little concerned at the menus ballooning again as we add more
options, some of which are extremely useful to VI users but that may be
overload for sighted users.

The current ideas do seem to be pointing to a Track dialog for VI use.
Just as we have a Labels editor dialog that was created for VI use, but
is useful to sighted users too, thinking in terms of a grid based track
editor may be more fruitful than ballooning of the menus.

--James.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

Gale
Administrator
On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:

> On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]> wrote:
>>
>> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>>>
>>> On 4/7/2017 9:53 AM, David Bailes wrote:
>>> > James has already suggested that there should also be commands that
>>> > work in
>>> > more than one track, and I agree with that. The possibilities for what
>>> > tracks clip commands work on are obviously:
>>> > 1. focused track
>>> > 2. selected tracks
>>> > 3. all tracks.
>>> >
>>> > It's just a question of working out which of these would be useful.
>>> >
>>> > David.
>>>
>>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
>>> all tracks, if none selected'.
>>
>>
>> This probably mainly of interest to Robert. I've implemented James'
>> suggestion of   'All selected tracks, or
>> all tracks, if none selected' for the cursor to clip boundaries, and
>> select to clip boundaries. It's available in the clipnavbnd branch in my
>> fork of Audacity.
>
>
> I've updated the behaviour of the six commands listed below so that if any
> audio tracks are selected, the clips in those tracks are used, otherwise the
> clips in all audio tracks are used:
> Cursor to Previous clip boundary
> Cursor to Next clip boundary
> Select previous clip boundary to cursor
> Select cursor to next clip boundary
> Select Previous Clip
> Select Next clip
>
> relevant commits:
> https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
> https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0

Thanks, David. I added some text to the Manual.

However, Select > Clip Boundaries > Previous Clip behaves differently to
Next Clip in the same menu, which seems wrong to me.

Starting from a cursor or partial selection somewhere in a clip, Next Clip
goes straight to the next clip and fully selects it. But Previous Clip,
starting from a cursor or partial selection in a clip, first fully selects in
the current clip. So you need another activation of the command to move
into and fully select the previous clip.

Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
Cursor to Next Clip Boundary seem to do nothing every other command.

Example, create three clips in a track. Click in the first clip, then call
Cursor to Next Clip Boundary.That selects to the end of the left edge of
the next clip, but the next call of the command does nothing. Call it again
and it extends the selection to the left edge of the next clip, as expected.

This "double action required" also affects Transport > Cursor to >  Previous
Clip Boundary and Next Clip Boundary.


Gale


>>> I am a little concerned at the menus ballooning again as we add more
>>> options, some of which are extremely useful to VI users but that may be
>>> overload for sighted users.
>>>
>>> The current ideas do seem to be pointing to a Track dialog for VI use.
>>> Just as we have a Labels editor dialog that was created for VI use, but
>>> is useful to sighted users too, thinking in terms of a grid based track
>>> editor may be more fruitful than ballooning of the menus.
>>>
>>> --James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

David Bailes-3
On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]> wrote:
On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
> On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]> wrote:
>>
>> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>>>
>>> On 4/7/2017 9:53 AM, David Bailes wrote:
>>> > James has already suggested that there should also be commands that
>>> > work in
>>> > more than one track, and I agree with that. The possibilities for what
>>> > tracks clip commands work on are obviously:
>>> > 1. focused track
>>> > 2. selected tracks
>>> > 3. all tracks.
>>> >
>>> > It's just a question of working out which of these would be useful.
>>> >
>>> > David.
>>>
>>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
>>> all tracks, if none selected'.
>>
>>
>> This probably mainly of interest to Robert. I've implemented James'
>> suggestion of   'All selected tracks, or
>> all tracks, if none selected' for the cursor to clip boundaries, and
>> select to clip boundaries. It's available in the clipnavbnd branch in my
>> fork of Audacity.
>
>
> I've updated the behaviour of the six commands listed below so that if any
> audio tracks are selected, the clips in those tracks are used, otherwise the
> clips in all audio tracks are used:
> Cursor to Previous clip boundary
> Cursor to Next clip boundary
> Select previous clip boundary to cursor
> Select cursor to next clip boundary
> Select Previous Clip
> Select Next clip
>
> relevant commits:
> https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
> https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0

Thanks, David. I added some text to the Manual.

However, Select > Clip Boundaries > Previous Clip behaves differently to
Next Clip in the same menu, which seems wrong to me.

Starting from a cursor or partial selection somewhere in a clip, Next Clip
goes straight to the next clip and fully selects it. But Previous Clip,
starting from a cursor or partial selection in a clip, first fully selects in
the current clip. So you need another activation of the command to move
into and fully select the previous clip.

I think this behaviour is what a user would expect.
eg in text editors, if you place the cursor in the middle of a word, then:
1. Pressing ctrl + right arrow moves you the the start of the next word.
2. Pressing ctrl + left arrow moves you to the start of the current word.

As another example, in the Reaper audio editor, if the edit cursor is in the middle of an item(similar to clips), then:
1. Select next item, selects the next item.
2. Select previous item, selects the current item.

With the current behaviour, if the cursor is somewhere in the clip, you can always select the current clip by using next or previous clip.
 

Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
Cursor to Next Clip Boundary seem to do nothing every other command.

Example, create three clips in a track. Click in the first clip, then call
Cursor to Next Clip Boundary.That selects to the end of the left edge of
the next clip, but the next call of the command does nothing. Call it again
and it extends the selection to the left edge of the next clip, as expected.

This "double action required" also affects Transport > Cursor to >  Previous
Clip Boundary and Next Clip Boundary.

Thanks for testing this. Unfortunately, I can't reproduce your results. Most strange.
Could others test this please,

thanks,
David. 


Gale


>>> I am a little concerned at the menus ballooning again as we add more
>>> options, some of which are extremely useful to VI users but that may be
>>> overload for sighted users.
>>>
>>> The current ideas do seem to be pointing to a Track dialog for VI use.
>>> Just as we have a Labels editor dialog that was created for VI use, but
>>> is useful to sighted users too, thinking in terms of a grid based track
>>> editor may be more fruitful than ballooning of the menus.
>>>
>>> --James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

Cliff Scott

On May 3, 2017, at 7:15 AM, David Bailes <[hidden email]> wrote:

On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]> wrote:
On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
> On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]> wrote:
>>
>> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>>>
>>> On 4/7/2017 9:53 AM, David Bailes wrote:
>>> > James has already suggested that there should also be commands that
>>> > work in
>>> > more than one track, and I agree with that. The possibilities for what
>>> > tracks clip commands work on are obviously:
>>> > 1. focused track
>>> > 2. selected tracks
>>> > 3. all tracks.
>>> >
>>> > It's just a question of working out which of these would be useful.
>>> >
>>> > David.
>>>
>>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
>>> all tracks, if none selected'.
>>
>>
>> This probably mainly of interest to Robert. I've implemented James'
>> suggestion of   'All selected tracks, or
>> all tracks, if none selected' for the cursor to clip boundaries, and
>> select to clip boundaries. It's available in the clipnavbnd branch in my
>> fork of Audacity.
>
>
> I've updated the behaviour of the six commands listed below so that if any
> audio tracks are selected, the clips in those tracks are used, otherwise the
> clips in all audio tracks are used:
> Cursor to Previous clip boundary
> Cursor to Next clip boundary
> Select previous clip boundary to cursor
> Select cursor to next clip boundary
> Select Previous Clip
> Select Next clip
>
> relevant commits:
> https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
> https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0

Thanks, David. I added some text to the Manual.

However, Select > Clip Boundaries > Previous Clip behaves differently to
Next Clip in the same menu, which seems wrong to me.

Starting from a cursor or partial selection somewhere in a clip, Next Clip
goes straight to the next clip and fully selects it. But Previous Clip,
starting from a cursor or partial selection in a clip, first fully selects in
the current clip. So you need another activation of the command to move
into and fully select the previous clip.

I think this behaviour is what a user would expect.
eg in text editors, if you place the cursor in the middle of a word, then:
1. Pressing ctrl + right arrow moves you the the start of the next word.
2. Pressing ctrl + left arrow moves you to the start of the current word.

As another example, in the Reaper audio editor, if the edit cursor is in the middle of an item(similar to clips), then:
1. Select next item, selects the next item.
2. Select previous item, selects the current item.

With the current behaviour, if the cursor is somewhere in the clip, you can always select the current clip by using next or previous clip.
 

Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
Cursor to Next Clip Boundary seem to do nothing every other command.

Example, create three clips in a track. Click in the first clip, then call
Cursor to Next Clip Boundary.That selects to the end of the left edge of
the next clip, but the next call of the command does nothing. Call it again
and it extends the selection to the left edge of the next clip, as expected.

This "double action required" also affects Transport > Cursor to >  Previous
Clip Boundary and Next Clip Boundary.

Thanks for testing this. Unfortunately, I can't reproduce your results. Most strange.
Could others test this please,

thanks,
David. 

Works as it should here on Mac Sierra 10.12.4 using Select and Transport menus.

Pardon my ignorance, but what shortcut keys do the angled arrows on Transport>Project Start or Project End represent?

Cliff



Gale


>>> I am a little concerned at the menus ballooning again as we add more
>>> options, some of which are extremely useful to VI users but that may be
>>> overload for sighted users.
>>>
>>> The current ideas do seem to be pointing to a Track dialog for VI use.
>>> Just as we have a Labels editor dialog that was created for VI use, but
>>> is useful to sighted users too, thinking in terms of a grid based track
>>> editor may be more fruitful than ballooning of the menus.
>>>
>>> --James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

David Bailes-3
On Wed, May 3, 2017 at 1:53 PM, Cliff Scott <[hidden email]> wrote:

On May 3, 2017, at 7:15 AM, David Bailes <[hidden email]> wrote:

On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]> wrote:
On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
> On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]> wrote:
>>
>> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>>>
>>> On 4/7/2017 9:53 AM, David Bailes wrote:
>>> > James has already suggested that there should also be commands that
>>> > work in
>>> > more than one track, and I agree with that. The possibilities for what
>>> > tracks clip commands work on are obviously:
>>> > 1. focused track
>>> > 2. selected tracks
>>> > 3. all tracks.
>>> >
>>> > It's just a question of working out which of these would be useful.
>>> >
>>> > David.
>>>
>>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
>>> all tracks, if none selected'.
>>
>>
>> This probably mainly of interest to Robert. I've implemented James'
>> suggestion of   'All selected tracks, or
>> all tracks, if none selected' for the cursor to clip boundaries, and
>> select to clip boundaries. It's available in the clipnavbnd branch in my
>> fork of Audacity.
>
>
> I've updated the behaviour of the six commands listed below so that if any
> audio tracks are selected, the clips in those tracks are used, otherwise the
> clips in all audio tracks are used:
> Cursor to Previous clip boundary
> Cursor to Next clip boundary
> Select previous clip boundary to cursor
> Select cursor to next clip boundary
> Select Previous Clip
> Select Next clip
>
> relevant commits:
> https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
> https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0

Thanks, David. I added some text to the Manual.

However, Select > Clip Boundaries > Previous Clip behaves differently to
Next Clip in the same menu, which seems wrong to me.

Starting from a cursor or partial selection somewhere in a clip, Next Clip
goes straight to the next clip and fully selects it. But Previous Clip,
starting from a cursor or partial selection in a clip, first fully selects in
the current clip. So you need another activation of the command to move
into and fully select the previous clip.

I think this behaviour is what a user would expect.
eg in text editors, if you place the cursor in the middle of a word, then:
1. Pressing ctrl + right arrow moves you the the start of the next word.
2. Pressing ctrl + left arrow moves you to the start of the current word.

As another example, in the Reaper audio editor, if the edit cursor is in the middle of an item(similar to clips), then:
1. Select next item, selects the next item.
2. Select previous item, selects the current item.

With the current behaviour, if the cursor is somewhere in the clip, you can always select the current clip by using next or previous clip.
 

Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
Cursor to Next Clip Boundary seem to do nothing every other command.

Example, create three clips in a track. Click in the first clip, then call
Cursor to Next Clip Boundary.That selects to the end of the left edge of
the next clip, but the next call of the command does nothing. Call it again
and it extends the selection to the left edge of the next clip, as expected.

This "double action required" also affects Transport > Cursor to >  Previous
Clip Boundary and Next Clip Boundary.

Thanks for testing this. Unfortunately, I can't reproduce your results. Most strange.
Could others test this please,

thanks,
David. 

Works as it should here on Mac Sierra 10.12.4 using Select and Transport menus.

thanks for testing. 

Pardon my ignorance, but what shortcut keys do the angled arrows on Transport>Project Start or Project End represent?

Is it the shortcuts keys on Transport>Cursor to>Project Start/End that you are referring to? They are set to Home and End here,

David.


Cliff



Gale


>>> I am a little concerned at the menus ballooning again as we add more
>>> options, some of which are extremely useful to VI users but that may be
>>> overload for sighted users.
>>>
>>> The current ideas do seem to be pointing to a Track dialog for VI use.
>>> Just as we have a Labels editor dialog that was created for VI use, but
>>> is useful to sighted users too, thinking in terms of a grid based track
>>> editor may be more fruitful than ballooning of the menus.
>>>
>>> --James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.orghttp://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's mostesting.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

Cliff Scott

On May 3, 2017, at 8:03 AM, David Bailes <[hidden email]> wrote:

On Wed, May 3, 2017 at 1:53 PM, Cliff Scott <[hidden email]> wrote:

On May 3, 2017, at 7:15 AM, David Bailes <[hidden email]> wrote:

On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]> wrote:
On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
> On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]> wrote:
>>
>> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>>>
>>> On 4/7/2017 9:53 AM, David Bailes wrote:
>>> > James has already suggested that there should also be commands that
>>> > work in
>>> > more than one track, and I agree with that. The possibilities for what
>>> > tracks clip commands work on are obviously:
>>> > 1. focused track
>>> > 2. selected tracks
>>> > 3. all tracks.
>>> >
>>> > It's just a question of working out which of these would be useful.
>>> >
>>> > David.
>>>
>>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
>>> all tracks, if none selected'.
>>
>>
>> This probably mainly of interest to Robert. I've implemented James'
>> suggestion of   'All selected tracks, or
>> all tracks, if none selected' for the cursor to clip boundaries, and
>> select to clip boundaries. It's available in the clipnavbnd branch in my
>> fork of Audacity.
>
>
> I've updated the behaviour of the six commands listed below so that if any
> audio tracks are selected, the clips in those tracks are used, otherwise the
> clips in all audio tracks are used:
> Cursor to Previous clip boundary
> Cursor to Next clip boundary
> Select previous clip boundary to cursor
> Select cursor to next clip boundary
> Select Previous Clip
> Select Next clip
>
> relevant commits:
> https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
> https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0

Thanks, David. I added some text to the Manual.

However, Select > Clip Boundaries > Previous Clip behaves differently to
Next Clip in the same menu, which seems wrong to me.

Starting from a cursor or partial selection somewhere in a clip, Next Clip
goes straight to the next clip and fully selects it. But Previous Clip,
starting from a cursor or partial selection in a clip, first fully selects in
the current clip. So you need another activation of the command to move
into and fully select the previous clip.

I think this behaviour is what a user would expect.
eg in text editors, if you place the cursor in the middle of a word, then:
1. Pressing ctrl + right arrow moves you the the start of the next word.
2. Pressing ctrl + left arrow moves you to the start of the current word.

As another example, in the Reaper audio editor, if the edit cursor is in the middle of an item(similar to clips), then:
1. Select next item, selects the next item.
2. Select previous item, selects the current item.

With the current behaviour, if the cursor is somewhere in the clip, you can always select the current clip by using next or previous clip.
 

Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
Cursor to Next Clip Boundary seem to do nothing every other command.

Example, create three clips in a track. Click in the first clip, then call
Cursor to Next Clip Boundary.That selects to the end of the left edge of
the next clip, but the next call of the command does nothing. Call it again
and it extends the selection to the left edge of the next clip, as expected.

This "double action required" also affects Transport > Cursor to >  Previous
Clip Boundary and Next Clip Boundary.

Thanks for testing this. Unfortunately, I can't reproduce your results. Most strange.
Could others test this please,

thanks,
David. 

Works as it should here on Mac Sierra 10.12.4 using Select and Transport menus.

thanks for testing. 

Pardon my ignorance, but what shortcut keys do the angled arrows on Transport>Project Start or Project End represent?

Is it the shortcuts keys on Transport>Cursor to>Project Start/End that you are referring to? They are set to Home and End here,

David.

Thanks. I suspected as much. My Mac laptop keyboard does not have those keys.

Cliff



Cliff



Gale


>>> I am a little concerned at the menus ballooning again as we add more
>>> options, some of which are extremely useful to VI users but that may be
>>> overload for sighted users.
>>>
>>> The current ideas do seem to be pointing to a Track dialog for VI use.
>>> Just as we have a Labels editor dialog that was created for VI use, but
>>> is useful to sighted users too, thinking in terms of a grid based track
>>> editor may be more fruitful than ballooning of the menus.
>>>
>>> --James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.orghttp://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's mostesting.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

Gale
Administrator
In reply to this post by David Bailes-3
On 3 May 2017 at 13:15, David Bailes <[hidden email]> wrote:

> On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]> wrote:
>>
>> On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
>> > On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]>
>> > wrote:
>> >>
>> >> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>> >>>
>> >>> On 4/7/2017 9:53 AM, David Bailes wrote:
>> >>> > James has already suggested that there should also be commands that
>> >>> > work in
>> >>> > more than one track, and I agree with that. The possibilities for
>> >>> > what
>> >>> > tracks clip commands work on are obviously:
>> >>> > 1. focused track
>> >>> > 2. selected tracks
>> >>> > 3. all tracks.
>> >>> >
>> >>> > It's just a question of working out which of these would be useful.
>> >>> >
>> >>> > David.
>> >>>
>> >>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
>> >>> all tracks, if none selected'.
>> >>
>> >>
>> >> This probably mainly of interest to Robert. I've implemented James'
>> >> suggestion of   'All selected tracks, or
>> >> all tracks, if none selected' for the cursor to clip boundaries, and
>> >> select to clip boundaries. It's available in the clipnavbnd branch in
>> >> my
>> >> fork of Audacity.
>> >
>> >
>> > I've updated the behaviour of the six commands listed below so that if
>> > any
>> > audio tracks are selected, the clips in those tracks are used, otherwise
>> > the
>> > clips in all audio tracks are used:
>> > Cursor to Previous clip boundary
>> > Cursor to Next clip boundary
>> > Select previous clip boundary to cursor
>> > Select cursor to next clip boundary
>> > Select Previous Clip
>> > Select Next clip
>> >
>> > relevant commits:
>> >
>> > https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
>> >
>> > https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0
>>
>> Thanks, David. I added some text to the Manual.
>>
>> However, Select > Clip Boundaries > Previous Clip behaves differently to
>> Next Clip in the same menu, which seems wrong to me.
>>
>> Starting from a cursor or partial selection somewhere in a clip, Next Clip
>> goes straight to the next clip and fully selects it. But Previous Clip,
>> starting from a cursor or partial selection in a clip, first fully selects
>> in
>> the current clip. So you need another activation of the command to move
>> into and fully select the previous clip.
>
>
> I think this behaviour is what a user would expect.
> eg in text editors, if you place the cursor in the middle of a word, then:
> 1. Pressing ctrl + right arrow moves you the the start of the next word.
> 2. Pressing ctrl + left arrow moves you to the start of the current word.
>
> As another example, in the Reaper audio editor, if the edit cursor is in the
> middle of an item(similar to clips), then:
> 1. Select next item, selects the next item.
> 2. Select previous item, selects the current item.

OK, thanks David. I'll have to accept this, but as someone who doesn't
use keyboard navigation in documents, it seems unintuitive to me.
I can only guess the logic as giving primacy to the start of the word.

>From what I understood from a quick search, there is no universal shortcut
for the opposite of Ctrl + Left (move the cursor to the end of a word) or
for the opposite of Ctrl + Right (move to the start of the previous word).


> With the current behaviour, if the cursor is somewhere in the clip, you can
> always select the current clip by using next or previous clip.

Doesn't work for me. To select the current clip I must use Select > Clip
Boundaries > Previous Clip, as you have just described. Next Clip
always selects the next clip.


>>
>> Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
>> Cursor to Next Clip Boundary seem to do nothing every other command.
>>
>> Example, create three clips in a track. Click in the first clip, then call
>> Cursor to Next Clip Boundary.That selects to the end of the left edge of
>> the next clip, but the next call of the command does nothing. Call it
>> again
>> and it extends the selection to the left edge of the next clip, as
>> expected.
>>
>> This "double action required" also affects Transport > Cursor to >
>> Previous Clip Boundary and Next Clip Boundary.
>
>
> Thanks for testing this. Unfortunately, I can't reproduce your results. Most
> strange.

It might have something to do with the position of the clip boundaries or
even the window size, but something isn't right. If the problem happens,
it is 100% repeatable for me.

Could you try http://gaclrecords.org.uk/bugs/clip_commands_tests.zip ?

A) Testing on Windows 10, window maximised, if I open the "clips1" project,
     Select > Clip Boundaries > Previous Clip Boundary to Cursor does nothing
     until called a second time.

B) If I then use Selection Toolbar to place the cursor at 10.000 seconds,
     Select > Clip Boundaries > Cursor to Next Clip Boundary selects from
     10s to the next boundary, called again it does nothing, called again
     it selects to the end of the track.

If I move this project to my Linux netbook, then A) reproduces the same,
but in B), Cursor to Next Clip Boundary does nothing after selecting from
10s to the next boundary, however many times I call it.

Then try the "linux clip" project. I created this on Ubuntu 14.04. It shows
the same behaviour there as B) in the "clips1" project:  Select > Clip
Boundaries > Cursor to Next Clip Boundary refuses to do anything. But
on Windows 10, the command works first time.


Gale


> Could others test this please,
>
> thanks,
> David.
>>
>>
>>
>> Gale
>>
>>
>> >>> I am a little concerned at the menus ballooning again as we add more
>> >>> options, some of which are extremely useful to VI users but that may
>> >>> be
>> >>> overload for sighted users.
>> >>>
>> >>> The current ideas do seem to be pointing to a Track dialog for VI use.
>> >>> Just as we have a Labels editor dialog that was created for VI use,
>> >>> but
>> >>> is useful to sighted users too, thinking in terms of a grid based
>> >>> track
>> >>> editor may be more fruitful than ballooning of the menus.
>> >>>
>> >>> --James.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

David Bailes-3
On Wed, May 3, 2017 at 6:51 PM, Gale Andrews <[hidden email]> wrote:
On 3 May 2017 at 13:15, David Bailes <[hidden email]> wrote:
> On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]> wrote:
>>
>> On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
>> > On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]>
>> > wrote:
>> >>
>> >> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>> >>>
>> >>> On 4/7/2017 9:53 AM, David Bailes wrote:
>> >>> > James has already suggested that there should also be commands that
>> >>> > work in
>> >>> > more than one track, and I agree with that. The possibilities for
>> >>> > what
>> >>> > tracks clip commands work on are obviously:
>> >>> > 1. focused track
>> >>> > 2. selected tracks
>> >>> > 3. all tracks.
>> >>> >
>> >>> > It's just a question of working out which of these would be useful.
>> >>> >
>> >>> > David.
>> >>>
>> >>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
>> >>> all tracks, if none selected'.
>> >>
>> >>
>> >> This probably mainly of interest to Robert. I've implemented James'
>> >> suggestion of   'All selected tracks, or
>> >> all tracks, if none selected' for the cursor to clip boundaries, and
>> >> select to clip boundaries. It's available in the clipnavbnd branch in
>> >> my
>> >> fork of Audacity.
>> >
>> >
>> > I've updated the behaviour of the six commands listed below so that if
>> > any
>> > audio tracks are selected, the clips in those tracks are used, otherwise
>> > the
>> > clips in all audio tracks are used:
>> > Cursor to Previous clip boundary
>> > Cursor to Next clip boundary
>> > Select previous clip boundary to cursor
>> > Select cursor to next clip boundary
>> > Select Previous Clip
>> > Select Next clip
>> >
>> > relevant commits:
>> >
>> > https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
>> >
>> > https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0
>>
>> Thanks, David. I added some text to the Manual.
>>
>> However, Select > Clip Boundaries > Previous Clip behaves differently to
>> Next Clip in the same menu, which seems wrong to me.
>>
>> Starting from a cursor or partial selection somewhere in a clip, Next Clip
>> goes straight to the next clip and fully selects it. But Previous Clip,
>> starting from a cursor or partial selection in a clip, first fully selects
>> in
>> the current clip. So you need another activation of the command to move
>> into and fully select the previous clip.
>
>
> I think this behaviour is what a user would expect.
> eg in text editors, if you place the cursor in the middle of a word, then:
> 1. Pressing ctrl + right arrow moves you the the start of the next word.
> 2. Pressing ctrl + left arrow moves you to the start of the current word.
>
> As another example, in the Reaper audio editor, if the edit cursor is in the
> middle of an item(similar to clips), then:
> 1. Select next item, selects the next item.
> 2. Select previous item, selects the current item.

OK, thanks David. I'll have to accept this, but as someone who doesn't
use keyboard navigation in documents, it seems unintuitive to me.
I can only guess the logic as giving primacy to the start of the word.

>From what I understood from a quick search, there is no universal shortcut
for the opposite of Ctrl + Left (move the cursor to the end of a word) or
for the opposite of Ctrl + Right (move to the start of the previous word).


> With the current behaviour, if the cursor is somewhere in the clip, you can
> always select the current clip by using next or previous clip.

Doesn't work for me. To select the current clip I must use Select > Clip
Boundaries > Previous Clip, as you have just described. Next Clip
always selects the next clip.

If the cursor is exactly at the start of the clip, then the clip can be selected using select next clip. If the cursor is anywhere else in the clip, then select previous clip has to be used. 


>>
>> Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
>> Cursor to Next Clip Boundary seem to do nothing every other command.
>>
>> Example, create three clips in a track. Click in the first clip, then call
>> Cursor to Next Clip Boundary.That selects to the end of the left edge of
>> the next clip, but the next call of the command does nothing. Call it
>> again
>> and it extends the selection to the left edge of the next clip, as
>> expected.
>>
>> This "double action required" also affects Transport > Cursor to >
>> Previous Clip Boundary and Next Clip Boundary.
>
>
> Thanks for testing this. Unfortunately, I can't reproduce your results. Most
> strange.

It might have something to do with the position of the clip boundaries or
even the window size, but something isn't right. If the problem happens,
it is 100% repeatable for me.

Could you try http://gaclrecords.org.uk/bugs/clip_commands_tests.zip ?

Thanks for these. I've had a quick look - it may be a problem due to rounding errors. I've been aware that they might cause a problem, but they hadn't shown up with my own experiments. I'll take a close look in the near future.

Did you use the command clip boundaries->split to create the clips? (This may sound like a silly question, but I just want to check).

Some info: If two clips are immediately next to each other, then (apart from rounding errors) the end of the first clip, and the start of the second clip occur at the same time. My code interprets that as a single boundary.

In the clips 1 projects, the end of the first clip comes after the start of the second clip, I presume due to rounding errors.

If you want to find out which boundaries my code thinks it has found, just run NVDA, and it will tell you.
If you time shift the clips so that there are gaps between them, then there won't be any problems with rounding errors.

David.


A) Testing on Windows 10, window maximised, if I open the "clips1" project,
     Select > Clip Boundaries > Previous Clip Boundary to Cursor does nothing
     until called a second time.

B) If I then use Selection Toolbar to place the cursor at 10.000 seconds,
     Select > Clip Boundaries > Cursor to Next Clip Boundary selects from
     10s to the next boundary, called again it does nothing, called again
     it selects to the end of the track.

If I move this project to my Linux netbook, then A) reproduces the same,
but in B), Cursor to Next Clip Boundary does nothing after selecting from
10s to the next boundary, however many times I call it.

Then try the "linux clip" project. I created this on Ubuntu 14.04. It shows
the same behaviour there as B) in the "clips1" project:  Select > Clip
Boundaries > Cursor to Next Clip Boundary refuses to do anything. But
on Windows 10, the command works first time.


Gale


> Could others test this please,
>
> thanks,
> David.
>>
>>
>>
>> Gale
>>
>>
>> >>> I am a little concerned at the menus ballooning again as we add more
>> >>> options, some of which are extremely useful to VI users but that may
>> >>> be
>> >>> overload for sighted users.
>> >>>
>> >>> The current ideas do seem to be pointing to a Track dialog for VI use.
>> >>> Just as we have a Labels editor dialog that was created for VI use,
>> >>> but
>> >>> is useful to sighted users too, thinking in terms of a grid based
>> >>> track
>> >>> editor may be more fruitful than ballooning of the menus.
>> >>>
>> >>> --James.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

David Bailes-3
On Wed, May 3, 2017 at 7:36 PM, David Bailes <[hidden email]> wrote:
On Wed, May 3, 2017 at 6:51 PM, Gale Andrews <[hidden email]> wrote:
On 3 May 2017 at 13:15, David Bailes <[hidden email]> wrote:
> On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]> wrote:
>>
>> On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
>> > On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]>
>> > wrote:
>> >>
>> >> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>> >>>
>> >>> On 4/7/2017 9:53 AM, David Bailes wrote:
>> >>> > James has already suggested that there should also be commands that
>> >>> > work in
>> >>> > more than one track, and I agree with that. The possibilities for
>> >>> > what
>> >>> > tracks clip commands work on are obviously:
>> >>> > 1. focused track
>> >>> > 2. selected tracks
>> >>> > 3. all tracks.
>> >>> >
>> >>> > It's just a question of working out which of these would be useful.
>> >>> >
>> >>> > David.
>> >>>
>> >>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
>> >>> all tracks, if none selected'.
>> >>
>> >>
>> >> This probably mainly of interest to Robert. I've implemented James'
>> >> suggestion of   'All selected tracks, or
>> >> all tracks, if none selected' for the cursor to clip boundaries, and
>> >> select to clip boundaries. It's available in the clipnavbnd branch in
>> >> my
>> >> fork of Audacity.
>> >
>> >
>> > I've updated the behaviour of the six commands listed below so that if
>> > any
>> > audio tracks are selected, the clips in those tracks are used, otherwise
>> > the
>> > clips in all audio tracks are used:
>> > Cursor to Previous clip boundary
>> > Cursor to Next clip boundary
>> > Select previous clip boundary to cursor
>> > Select cursor to next clip boundary
>> > Select Previous Clip
>> > Select Next clip
>> >
>> > relevant commits:
>> >
>> > https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
>> >
>> > https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0
>>
>> Thanks, David. I added some text to the Manual.
>>
>> However, Select > Clip Boundaries > Previous Clip behaves differently to
>> Next Clip in the same menu, which seems wrong to me.
>>
>> Starting from a cursor or partial selection somewhere in a clip, Next Clip
>> goes straight to the next clip and fully selects it. But Previous Clip,
>> starting from a cursor or partial selection in a clip, first fully selects
>> in
>> the current clip. So you need another activation of the command to move
>> into and fully select the previous clip.
>
>
> I think this behaviour is what a user would expect.
> eg in text editors, if you place the cursor in the middle of a word, then:
> 1. Pressing ctrl + right arrow moves you the the start of the next word.
> 2. Pressing ctrl + left arrow moves you to the start of the current word.
>
> As another example, in the Reaper audio editor, if the edit cursor is in the
> middle of an item(similar to clips), then:
> 1. Select next item, selects the next item.
> 2. Select previous item, selects the current item.

OK, thanks David. I'll have to accept this, but as someone who doesn't
use keyboard navigation in documents, it seems unintuitive to me.
I can only guess the logic as giving primacy to the start of the word.

>From what I understood from a quick search, there is no universal shortcut
for the opposite of Ctrl + Left (move the cursor to the end of a word) or
for the opposite of Ctrl + Right (move to the start of the previous word).


> With the current behaviour, if the cursor is somewhere in the clip, you can
> always select the current clip by using next or previous clip.

Doesn't work for me. To select the current clip I must use Select > Clip
Boundaries > Previous Clip, as you have just described. Next Clip
always selects the next clip.

If the cursor is exactly at the start of the clip, then the clip can be selected using select next clip. If the cursor is anywhere else in the clip, then select previous clip has to be used. 


>>
>> Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
>> Cursor to Next Clip Boundary seem to do nothing every other command.
>>
>> Example, create three clips in a track. Click in the first clip, then call
>> Cursor to Next Clip Boundary.That selects to the end of the left edge of
>> the next clip, but the next call of the command does nothing. Call it
>> again
>> and it extends the selection to the left edge of the next clip, as
>> expected.
>>
>> This "double action required" also affects Transport > Cursor to >
>> Previous Clip Boundary and Next Clip Boundary.
>
>
> Thanks for testing this. Unfortunately, I can't reproduce your results. Most
> strange.

It might have something to do with the position of the clip boundaries or
even the window size, but something isn't right. If the problem happens,
it is 100% repeatable for me.

Could you try http://gaclrecords.org.uk/bugs/clip_commands_tests.zip ?

Thanks for these. I've had a quick look - it may be a problem due to rounding errors. I've been aware that they might cause a problem, but they hadn't shown up with my own experiments. I'll take a close look in the near future.

Did you use the command clip boundaries->split to create the clips? (This may sound like a silly question, but I just want to check).

supplementary question:
Assuming that you used clip boundaries->split, to get the three clips, did you:
1. Select a region, then use the command.
2. (Position the cursor, use the command) twice.

thanks
David.  

Some info: If two clips are immediately next to each other, then (apart from rounding errors) the end of the first clip, and the start of the second clip occur at the same time. My code interprets that as a single boundary.

In the clips 1 projects, the end of the first clip comes after the start of the second clip, I presume due to rounding errors.

If you want to find out which boundaries my code thinks it has found, just run NVDA, and it will tell you.
If you time shift the clips so that there are gaps between them, then there won't be any problems with rounding errors.

David.


A) Testing on Windows 10, window maximised, if I open the "clips1" project,
     Select > Clip Boundaries > Previous Clip Boundary to Cursor does nothing
     until called a second time.

B) If I then use Selection Toolbar to place the cursor at 10.000 seconds,
     Select > Clip Boundaries > Cursor to Next Clip Boundary selects from
     10s to the next boundary, called again it does nothing, called again
     it selects to the end of the track.

If I move this project to my Linux netbook, then A) reproduces the same,
but in B), Cursor to Next Clip Boundary does nothing after selecting from
10s to the next boundary, however many times I call it.

Then try the "linux clip" project. I created this on Ubuntu 14.04. It shows
the same behaviour there as B) in the "clips1" project:  Select > Clip
Boundaries > Cursor to Next Clip Boundary refuses to do anything. But
on Windows 10, the command works first time.


Gale


> Could others test this please,
>
> thanks,
> David.
>>
>>
>>
>> Gale
>>
>>
>> >>> I am a little concerned at the menus ballooning again as we add more
>> >>> options, some of which are extremely useful to VI users but that may
>> >>> be
>> >>> overload for sighted users.
>> >>>
>> >>> The current ideas do seem to be pointing to a Track dialog for VI use.
>> >>> Just as we have a Labels editor dialog that was created for VI use,
>> >>> but
>> >>> is useful to sighted users too, thinking in terms of a grid based
>> >>> track
>> >>> editor may be more fruitful than ballooning of the menus.
>> >>>
>> >>> --James.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

Gale
Administrator
In reply to this post by David Bailes-3
On 3 May 2017 at 19:36, David Bailes <[hidden email]> wrote:

> On Wed, May 3, 2017 at 6:51 PM, Gale Andrews <[hidden email]> wrote:
>>
>> On 3 May 2017 at 13:15, David Bailes <[hidden email]> wrote:
>> > On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]>
>> > wrote:
>> >>
>> >> On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
>> >> > On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]>
>> >> >> wrote:
>> >> >>>
>> >> >>> On 4/7/2017 9:53 AM, David Bailes wrote:
>> >> >>> > James has already suggested that there should also be commands
>> >> >>> > that
>> >> >>> > work in
>> >> >>> > more than one track, and I agree with that. The possibilities for
>> >> >>> > what
>> >> >>> > tracks clip commands work on are obviously:
>> >> >>> > 1. focused track
>> >> >>> > 2. selected tracks
>> >> >>> > 3. all tracks.
>> >> >>> >
>> >> >>> > It's just a question of working out which of these would be
>> >> >>> > useful.
>> >> >>> >
>> >> >>> > David.
>> >> >>>
>> >> >>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks,
>> >> >>> or
>> >> >>> all tracks, if none selected'.
>> >> >>
>> >> >>
>> >> >> This probably mainly of interest to Robert. I've implemented James'
>> >> >> suggestion of   'All selected tracks, or
>> >> >> all tracks, if none selected' for the cursor to clip boundaries, and
>> >> >> select to clip boundaries. It's available in the clipnavbnd branch
>> >> >> in
>> >> >> my
>> >> >> fork of Audacity.
>> >> >
>> >> >
>> >> > I've updated the behaviour of the six commands listed below so that
>> >> > if
>> >> > any
>> >> > audio tracks are selected, the clips in those tracks are used,
>> >> > otherwise
>> >> > the
>> >> > clips in all audio tracks are used:
>> >> > Cursor to Previous clip boundary
>> >> > Cursor to Next clip boundary
>> >> > Select previous clip boundary to cursor
>> >> > Select cursor to next clip boundary
>> >> > Select Previous Clip
>> >> > Select Next clip
>> >> >
>> >> > relevant commits:
>> >> >
>> >> >
>> >> > https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
>> >> >
>> >> >
>> >> > https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0
>> >>
>> >> Thanks, David. I added some text to the Manual.
>> >>
>> >> However, Select > Clip Boundaries > Previous Clip behaves differently
>> >> to
>> >> Next Clip in the same menu, which seems wrong to me.
>> >>
>> >> Starting from a cursor or partial selection somewhere in a clip, Next
>> >> Clip
>> >> goes straight to the next clip and fully selects it. But Previous Clip,
>> >> starting from a cursor or partial selection in a clip, first fully
>> >> selects
>> >> in
>> >> the current clip. So you need another activation of the command to move
>> >> into and fully select the previous clip.
>> >
>> >
>> > I think this behaviour is what a user would expect.
>> > eg in text editors, if you place the cursor in the middle of a word,
>> > then:
>> > 1. Pressing ctrl + right arrow moves you the the start of the next word.
>> > 2. Pressing ctrl + left arrow moves you to the start of the current
>> > word.
>> >
>> > As another example, in the Reaper audio editor, if the edit cursor is in
>> > the
>> > middle of an item(similar to clips), then:
>> > 1. Select next item, selects the next item.
>> > 2. Select previous item, selects the current item.
>>
>> OK, thanks David. I'll have to accept this, but as someone who doesn't
>> use keyboard navigation in documents, it seems unintuitive to me.
>> I can only guess the logic as giving primacy to the start of the word.
>>
>> >From what I understood from a quick search, there is no universal
>> shortcut
>> for the opposite of Ctrl + Left (move the cursor to the end of a word) or
>> for the opposite of Ctrl + Right (move to the start of the previous word).
>>
>>
>> > With the current behaviour, if the cursor is somewhere in the clip, you
>> > can
>> > always select the current clip by using next or previous clip.
>>
>> Doesn't work for me. To select the current clip I must use Select > Clip
>> Boundaries > Previous Clip, as you have just described. Next Clip
>> always selects the next clip.
>
>
> If the cursor is exactly at the start of the clip, then the clip can be
> selected using select next clip.

And if the cursor is exactly at the start of a clip, should "Previous Clip"
select the previous clip?

If I double-click in the second clip in the "clips1" project, OR if I press
Home then use Select menu's "Next Clip" command twice, then Left
arrow, sometimes "Previous Clip" will select the previous clip,
sometimes it will select the current (second) clip.


> If the cursor is anywhere else in the clip, then select previous clip has
> to be used.
>>
>>
>>
>> >>
>> >> Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
>> >> Cursor to Next Clip Boundary seem to do nothing every other command.
>> >>
>> >> Example, create three clips in a track. Click in the first clip, then
>> >> call
>> >> Cursor to Next Clip Boundary.That selects to the end of the left edge
>> >> of
>> >> the next clip, but the next call of the command does nothing. Call it
>> >> again
>> >> and it extends the selection to the left edge of the next clip, as
>> >> expected.
>> >>
>> >> This "double action required" also affects Transport > Cursor to >
>> >> Previous Clip Boundary and Next Clip Boundary.
>> >
>> >
>> > Thanks for testing this. Unfortunately, I can't reproduce your results.
>> > Most
>> > strange.
>>
>> It might have something to do with the position of the clip boundaries or
>> even the window size, but something isn't right. If the problem happens,
>> it is 100% repeatable for me.
>>
>> Could you try http://gaclrecords.org.uk/bugs/clip_commands_tests.zip ?
>
>
> Thanks for these. I've had a quick look - it may be a problem due to
> rounding errors. I've been aware that they might cause a problem, but they
> hadn't shown up with my own experiments. I'll take a close look in the near
> future.
>
> Did you use the command clip boundaries->split to create the clips? (This
> may sound like a silly question, but I just want to check).

Yes, but always with the shortcut CTRL + I, not going through the menus.

And I always placed the cursor with the mouse, not with Selection Toolbar,
before issuing the Split command.


> Some info: If two clips are immediately next to each other, then (apart from
> rounding errors) the end of the first clip, and the start of the second clip
> occur at the same time. My code interprets that as a single boundary.
>
> In the clips 1 projects, the end of the first clip comes after the start of
> the second clip, I presume due to rounding errors.

How are you determining that's the case? In NVDA?

If I press HOME, then use Transport > Cursor to > Next Clip Boundary,
I hear with the first execution of the command "Start 2 of 3". The
next execution is read as "End 1 of 3" and that command does nothing.

Continuing, I hear "End 2 of 3", "Start 3 of 3" (the command does nothing)
and finally "End 3 of 3".


> If you want to find out which boundaries my code thinks it has found, just
> run NVDA, and it will tell you.
> If you time shift the clips so that there are gaps between them, then there
> won't be any problems with rounding errors.
>
> Supplementary question:
>
> Assuming that you used clip boundaries->split, to get the three clips, did
> you:
> 1. Select a region, then use the command.
> 2. (Position the cursor, use the command) twice.

Position the cursor with the mouse, Ctrl + I, position the cursor further
down the track, Ctrl + I.



Gale

>>
>> A) Testing on Windows 10, window maximised, if I open the "clips1"
>> project,
>>      Select > Clip Boundaries > Previous Clip Boundary to Cursor does
>> nothing
>>      until called a second time.
>>
>> B) If I then use Selection Toolbar to place the cursor at 10.000 seconds,
>>      Select > Clip Boundaries > Cursor to Next Clip Boundary selects from
>>      10s to the next boundary, called again it does nothing, called again
>>      it selects to the end of the track.
>>
>> If I move this project to my Linux netbook, then A) reproduces the same,
>> but in B), Cursor to Next Clip Boundary does nothing after selecting from
>> 10s to the next boundary, however many times I call it.
>>
>> Then try the "linux clip" project. I created this on Ubuntu 14.04. It
>> shows
>> the same behaviour there as B) in the "clips1" project:  Select > Clip
>> Boundaries > Cursor to Next Clip Boundary refuses to do anything. But
>> on Windows 10, the command works first time.
>>
>>
>> Gale
>>
>>
>> > Could others test this please,
>> >
>> > thanks,
>> > David.
>> >>
>> >>
>> >>
>> >> Gale
>> >>
>> >>
>> >> >>> I am a little concerned at the menus ballooning again as we add
>> >> >>> more
>> >> >>> options, some of which are extremely useful to VI users but that
>> >> >>> may
>> >> >>> be
>> >> >>> overload for sighted users.
>> >> >>>
>> >> >>> The current ideas do seem to be pointing to a Track dialog for VI
>> >> >>> use.
>> >> >>> Just as we have a Labels editor dialog that was created for VI use,
>> >> >>> but
>> >> >>> is useful to sighted users too, thinking in terms of a grid based
>> >> >>> track
>> >> >>> editor may be more fruitful than ballooning of the menus.
>> >> >>>
>> >> >>> --James.
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

Cliff Scott
In reply to this post by David Bailes-3

On May 3, 2017, at 1:36 PM, David Bailes <[hidden email]> wrote:

On Wed, May 3, 2017 at 6:51 PM, Gale Andrews <[hidden email]> wrote:
On 3 May 2017 at 13:15, David Bailes <[hidden email]> wrote:
> On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]> wrote:
>>
>> On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
>> > On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]>
>> > wrote:
>> >>
>> >> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>> >>>
>> >>> On 4/7/2017 9:53 AM, David Bailes wrote:
>> >>> > James has already suggested that there should also be commands that
>> >>> > work in
>> >>> > more than one track, and I agree with that. The possibilities for
>> >>> > what
>> >>> > tracks clip commands work on are obviously:
>> >>> > 1. focused track
>> >>> > 2. selected tracks
>> >>> > 3. all tracks.
>> >>> >
>> >>> > It's just a question of working out which of these would be useful.
>> >>> >
>> >>> > David.
>> >>>
>> >>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
>> >>> all tracks, if none selected'.
>> >>
>> >>
>> >> This probably mainly of interest to Robert. I've implemented James'
>> >> suggestion of   'All selected tracks, or
>> >> all tracks, if none selected' for the cursor to clip boundaries, and
>> >> select to clip boundaries. It's available in the clipnavbnd branch in
>> >> my
>> >> fork of Audacity.
>> >
>> >
>> > I've updated the behaviour of the six commands listed below so that if
>> > any
>> > audio tracks are selected, the clips in those tracks are used, otherwise
>> > the
>> > clips in all audio tracks are used:
>> > Cursor to Previous clip boundary
>> > Cursor to Next clip boundary
>> > Select previous clip boundary to cursor
>> > Select cursor to next clip boundary
>> > Select Previous Clip
>> > Select Next clip
>> >
>> > relevant commits:
>> >
>> > https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
>> >
>> > https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0
>>
>> Thanks, David. I added some text to the Manual.
>>
>> However, Select > Clip Boundaries > Previous Clip behaves differently to
>> Next Clip in the same menu, which seems wrong to me.
>>
>> Starting from a cursor or partial selection somewhere in a clip, Next Clip
>> goes straight to the next clip and fully selects it. But Previous Clip,
>> starting from a cursor or partial selection in a clip, first fully selects
>> in
>> the current clip. So you need another activation of the command to move
>> into and fully select the previous clip.
>
>
> I think this behaviour is what a user would expect.
> eg in text editors, if you place the cursor in the middle of a word, then:
> 1. Pressing ctrl + right arrow moves you the the start of the next word.
> 2. Pressing ctrl + left arrow moves you to the start of the current word.
>
> As another example, in the Reaper audio editor, if the edit cursor is in the
> middle of an item(similar to clips), then:
> 1. Select next item, selects the next item.
> 2. Select previous item, selects the current item.

OK, thanks David. I'll have to accept this, but as someone who doesn't
use keyboard navigation in documents, it seems unintuitive to me.
I can only guess the logic as giving primacy to the start of the word.

>From what I understood from a quick search, there is no universal shortcut
for the opposite of Ctrl + Left (move the cursor to the end of a word) or
for the opposite of Ctrl + Right (move to the start of the previous word).


> With the current behaviour, if the cursor is somewhere in the clip, you can
> always select the current clip by using next or previous clip.

Doesn't work for me. To select the current clip I must use Select > Clip
Boundaries > Previous Clip, as you have just described. Next Clip
always selects the next clip.

If the cursor is exactly at the start of the clip, then the clip can be selected using select next clip. If the cursor is anywhere else in the clip, then select previous clip has to be used. 


>>
>> Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
>> Cursor to Next Clip Boundary seem to do nothing every other command.
>>
>> Example, create three clips in a track. Click in the first clip, then call
>> Cursor to Next Clip Boundary.That selects to the end of the left edge of
>> the next clip, but the next call of the command does nothing. Call it
>> again
>> and it extends the selection to the left edge of the next clip, as
>> expected.
>>
>> This "double action required" also affects Transport > Cursor to >
>> Previous Clip Boundary and Next Clip Boundary.
>
>
> Thanks for testing this. Unfortunately, I can't reproduce your results. Most
> strange.

It might have something to do with the position of the clip boundaries or
even the window size, but something isn't right. If the problem happens,
it is 100% repeatable for me.

Could you try http://gaclrecords.org.uk/bugs/clip_commands_tests.zip ?

Thanks for these. I've had a quick look - it may be a problem due to rounding errors. I've been aware that they might cause a problem, but they hadn't shown up with my own experiments. I'll take a close look in the near future.

Did you use the command clip boundaries->split to create the clips? (This may sound like a silly question, but I just want to check).

Some info: If two clips are immediately next to each other, then (apart from rounding errors) the end of the first clip, and the start of the second clip occur at the same time. My code interprets that as a single boundary.

In the clips 1 projects, the end of the first clip comes after the start of the second clip, I presume due to rounding errors.

If you want to find out which boundaries my code thinks it has found, just run NVDA, and it will tell you.
If you time shift the clips so that there are gaps between them, then there won't be any problems with rounding errors.

David.

I can confirm that the spaces eliminates the duplicate uses of the command. I initially created my file with 3 recordings with a slight space in between. No problem with that track. Create a track with no spaces and I see the duplicate commands.

Cliff



A) Testing on Windows 10, window maximised, if I open the "clips1" project,
     Select > Clip Boundaries > Previous Clip Boundary to Cursor does nothing
     until called a second time.

B) If I then use Selection Toolbar to place the cursor at 10.000 seconds,
     Select > Clip Boundaries > Cursor to Next Clip Boundary selects from
     10s to the next boundary, called again it does nothing, called again
     it selects to the end of the track.

If I move this project to my Linux netbook, then A) reproduces the same,
but in B), Cursor to Next Clip Boundary does nothing after selecting from
10s to the next boundary, however many times I call it.

Then try the "linux clip" project. I created this on Ubuntu 14.04. It shows
the same behaviour there as B) in the "clips1" project:  Select > Clip
Boundaries > Cursor to Next Clip Boundary refuses to do anything. But
on Windows 10, the command works first time.


Gale


> Could others test this please,
>
> thanks,
> David.
>>
>>
>>
>> Gale
>>
>>
>> >>> I am a little concerned at the menus ballooning again as we add more
>> >>> options, some of which are extremely useful to VI users but that may
>> >>> be
>> >>> overload for sighted users.
>> >>>
>> >>> The current ideas do seem to be pointing to a Track dialog for VI use.
>> >>> Just as we have a Labels editor dialog that was created for VI use,
>> >>> but
>> >>> is useful to sighted users too, thinking in terms of a grid based
>> >>> track
>> >>> editor may be more fruitful than ballooning of the menus.
>> >>>
>> >>> --James.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

David Bailes-3
In reply to this post by Gale
On Wed, May 3, 2017 at 8:59 PM, Gale Andrews <[hidden email]> wrote:
On 3 May 2017 at 19:36, David Bailes <[hidden email]> wrote:
> On Wed, May 3, 2017 at 6:51 PM, Gale Andrews <[hidden email]> wrote:
>>
>> On 3 May 2017 at 13:15, David Bailes <[hidden email]> wrote:
>> > On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]>
>> > wrote:
>> >>
>> >> On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
>> >> > On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]>
>> >> >> wrote:
>> >> >>>
>> >> >>> On 4/7/2017 9:53 AM, David Bailes wrote:
>> >> >>> > James has already suggested that there should also be commands
>> >> >>> > that
>> >> >>> > work in
>> >> >>> > more than one track, and I agree with that. The possibilities for
>> >> >>> > what
>> >> >>> > tracks clip commands work on are obviously:
>> >> >>> > 1. focused track
>> >> >>> > 2. selected tracks
>> >> >>> > 3. all tracks.
>> >> >>> >
>> >> >>> > It's just a question of working out which of these would be
>> >> >>> > useful.
>> >> >>> >
>> >> >>> > David.
>> >> >>>
>> >> >>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks,
>> >> >>> or
>> >> >>> all tracks, if none selected'.
>> >> >>
>> >> >>
>> >> >> This probably mainly of interest to Robert. I've implemented James'
>> >> >> suggestion of   'All selected tracks, or
>> >> >> all tracks, if none selected' for the cursor to clip boundaries, and
>> >> >> select to clip boundaries. It's available in the clipnavbnd branch
>> >> >> in
>> >> >> my
>> >> >> fork of Audacity.
>> >> >
>> >> >
>> >> > I've updated the behaviour of the six commands listed below so that
>> >> > if
>> >> > any
>> >> > audio tracks are selected, the clips in those tracks are used,
>> >> > otherwise
>> >> > the
>> >> > clips in all audio tracks are used:
>> >> > Cursor to Previous clip boundary
>> >> > Cursor to Next clip boundary
>> >> > Select previous clip boundary to cursor
>> >> > Select cursor to next clip boundary
>> >> > Select Previous Clip
>> >> > Select Next clip
>> >> >
>> >> > relevant commits:
>> >> >
>> >> >
>> >> > https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
>> >> >
>> >> >
>> >> > https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0
>> >>
>> >> Thanks, David. I added some text to the Manual.
>> >>
>> >> However, Select > Clip Boundaries > Previous Clip behaves differently
>> >> to
>> >> Next Clip in the same menu, which seems wrong to me.
>> >>
>> >> Starting from a cursor or partial selection somewhere in a clip, Next
>> >> Clip
>> >> goes straight to the next clip and fully selects it. But Previous Clip,
>> >> starting from a cursor or partial selection in a clip, first fully
>> >> selects
>> >> in
>> >> the current clip. So you need another activation of the command to move
>> >> into and fully select the previous clip.
>> >
>> >
>> > I think this behaviour is what a user would expect.
>> > eg in text editors, if you place the cursor in the middle of a word,
>> > then:
>> > 1. Pressing ctrl + right arrow moves you the the start of the next word.
>> > 2. Pressing ctrl + left arrow moves you to the start of the current
>> > word.
>> >
>> > As another example, in the Reaper audio editor, if the edit cursor is in
>> > the
>> > middle of an item(similar to clips), then:
>> > 1. Select next item, selects the next item.
>> > 2. Select previous item, selects the current item.
>>
>> OK, thanks David. I'll have to accept this, but as someone who doesn't
>> use keyboard navigation in documents, it seems unintuitive to me.
>> I can only guess the logic as giving primacy to the start of the word.
>>
>> >From what I understood from a quick search, there is no universal
>> shortcut
>> for the opposite of Ctrl + Left (move the cursor to the end of a word) or
>> for the opposite of Ctrl + Right (move to the start of the previous word).
>>
>>
>> > With the current behaviour, if the cursor is somewhere in the clip, you
>> > can
>> > always select the current clip by using next or previous clip.
>>
>> Doesn't work for me. To select the current clip I must use Select > Clip
>> Boundaries > Previous Clip, as you have just described. Next Clip
>> always selects the next clip.
>
>
> If the cursor is exactly at the start of the clip, then the clip can be
> selected using select next clip.

And if the cursor is exactly at the start of a clip, should "Previous Clip"
select the previous clip?

Yes.
 

If I double-click in the second clip in the "clips1" project, OR if I press
Home then use Select menu's "Next Clip" command twice, then Left
arrow, sometimes "Previous Clip" will select the previous clip,
sometimes it will select the current (second) clip.

this could be due to the rounding errors. I'll look at this later. 


> If the cursor is anywhere else in the clip, then select previous clip has
> to be used.
>>
>>
>>
>> >>
>> >> Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
>> >> Cursor to Next Clip Boundary seem to do nothing every other command.
>> >>
>> >> Example, create three clips in a track. Click in the first clip, then
>> >> call
>> >> Cursor to Next Clip Boundary.That selects to the end of the left edge
>> >> of
>> >> the next clip, but the next call of the command does nothing. Call it
>> >> again
>> >> and it extends the selection to the left edge of the next clip, as
>> >> expected.
>> >>
>> >> This "double action required" also affects Transport > Cursor to >
>> >> Previous Clip Boundary and Next Clip Boundary.
>> >
>> >
>> > Thanks for testing this. Unfortunately, I can't reproduce your results.
>> > Most
>> > strange.
>>
>> It might have something to do with the position of the clip boundaries or
>> even the window size, but something isn't right. If the problem happens,
>> it is 100% repeatable for me.
>>
>> Could you try http://gaclrecords.org.uk/bugs/clip_commands_tests.zip ?
>
>
> Thanks for these. I've had a quick look - it may be a problem due to
> rounding errors. I've been aware that they might cause a problem, but they
> hadn't shown up with my own experiments. I'll take a close look in the near
> future.
>
> Did you use the command clip boundaries->split to create the clips? (This
> may sound like a silly question, but I just want to check).

Yes, but always with the shortcut CTRL + I, not going through the menus.

And I always placed the cursor with the mouse, not with Selection Toolbar,
before issuing the Split command.


> Some info: If two clips are immediately next to each other, then (apart from
> rounding errors) the end of the first clip, and the start of the second clip
> occur at the same time. My code interprets that as a single boundary.
>
> In the clips 1 projects, the end of the first clip comes after the start of
> the second clip, I presume due to rounding errors.

How are you determining that's the case? In NVDA?

I was just basing it on what NVDA was reading out - that is it was finding the start of the first clip before the end of the first. I've since confirmed this by some debuging. 

If I press HOME, then use Transport > Cursor to > Next Clip Boundary,
I hear with the first execution of the command "Start 2 of 3". The
next execution is read as "End 1 of 3" and that command does nothing.

Continuing, I hear "End 2 of 3", "Start 3 of 3" (the command does nothing)
and finally "End 3 of 3".

Just to add that when the command does nothing, it's in fact moving the cursor by a very very small amount. As I've said, the intention is that if two clips are immediately next to each other, then the end of the first clip and the start of the second, which barring rounding errors have the same times, will be treated as a single boundary. 


> If you want to find out which boundaries my code thinks it has found, just
> run NVDA, and it will tell you.
> If you time shift the clips so that there are gaps between them, then there
> won't be any problems with rounding errors.
>
> Supplementary question:
>
> Assuming that you used clip boundaries->split, to get the three clips, did
> you:
> 1. Select a region, then use the command.
> 2. (Position the cursor, use the command) twice.

Position the cursor with the mouse, Ctrl + I, position the cursor further
down the track, Ctrl + I.

thanks for all your testing and feedback,
David.
 



Gale

>>
>> A) Testing on Windows 10, window maximised, if I open the "clips1"
>> project,
>>      Select > Clip Boundaries > Previous Clip Boundary to Cursor does
>> nothing
>>      until called a second time.
>>
>> B) If I then use Selection Toolbar to place the cursor at 10.000 seconds,
>>      Select > Clip Boundaries > Cursor to Next Clip Boundary selects from
>>      10s to the next boundary, called again it does nothing, called again
>>      it selects to the end of the track.
>>
>> If I move this project to my Linux netbook, then A) reproduces the same,
>> but in B), Cursor to Next Clip Boundary does nothing after selecting from
>> 10s to the next boundary, however many times I call it.
>>
>> Then try the "linux clip" project. I created this on Ubuntu 14.04. It
>> shows
>> the same behaviour there as B) in the "clips1" project:  Select > Clip
>> Boundaries > Cursor to Next Clip Boundary refuses to do anything. But
>> on Windows 10, the command works first time.
>>
>>
>> Gale
>>
>>
>> > Could others test this please,
>> >
>> > thanks,
>> > David.
>> >>
>> >>
>> >>
>> >> Gale
>> >>
>> >>
>> >> >>> I am a little concerned at the menus ballooning again as we add
>> >> >>> more
>> >> >>> options, some of which are extremely useful to VI users but that
>> >> >>> may
>> >> >>> be
>> >> >>> overload for sighted users.
>> >> >>>
>> >> >>> The current ideas do seem to be pointing to a Track dialog for VI
>> >> >>> use.
>> >> >>> Just as we have a Labels editor dialog that was created for VI use,
>> >> >>> but
>> >> >>> is useful to sighted users too, thinking in terms of a grid based
>> >> >>> track
>> >> >>> editor may be more fruitful than ballooning of the menus.
>> >> >>>
>> >> >>> --James.
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

Robert Hänggi
Hi David

Sorry that I'm replying so late.
My computer has been down for three weeks due to an attempted upgrade
to Windows 10 (well, it works now more or less).

Clips are still somewhat mysterious to me, especially when we are
dealing with multiple tracks.
I will focus (cross your fingers) on one track projects for now.

I gave clips a lot of thought and know therefore what problems you're
facing. Thanks for your engagement.

In my view, it would be enough to call the submenu of "Select" simply
"Clips" because it also holds commands that select clips and not just
boundaries.

I'm navigating full clips with control+arrows and it works fine, in
the way you've defined it.

However, the nomenclature is somewhat confusing. I get an output like
"two of four, one of one". I would always add "Clips" after e.g. "of
four" because navigating through unnamed labels would give the same
output.

As I said earlier, I would also include the gaps in the navigation,
e.g. "White space before 3 of 5 Clips". However, this can easily be
achieved by "cursor to next Clip Boundary" and multiple tracks are
certainly challenging in this respect...


Expanding a selected clip to the next boundary does not appropriately
change the "track" name.
For example, with clip two selected, "Cursor to Next Boundary" returns
"End 3 of 5 and start 4" whereas it should read something like
"Start 2 to end 3 (of 5 clips)"
With a bit context-sensitive differentiation this could be simplified to e.g.
"Clips two to 3 of 5".

That's all for now.
Thanks
Robert

On 04/05/2017, David Bailes <[hidden email]> wrote:

> On Wed, May 3, 2017 at 8:59 PM, Gale Andrews <[hidden email]> wrote:
>
>> On 3 May 2017 at 19:36, David Bailes <[hidden email]> wrote:
>> > On Wed, May 3, 2017 at 6:51 PM, Gale Andrews <[hidden email]>
>> wrote:
>> >>
>> >> On 3 May 2017 at 13:15, David Bailes <[hidden email]> wrote:
>> >> > On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
>> >> >> > On Thu, Apr 13, 2017 at 1:54 PM, David Bailes
>> >> >> > <[hidden email]>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]>
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> On 4/7/2017 9:53 AM, David Bailes wrote:
>> >> >> >>> > James has already suggested that there should also be
>> >> >> >>> > commands
>> >> >> >>> > that
>> >> >> >>> > work in
>> >> >> >>> > more than one track, and I agree with that. The possibilities
>> for
>> >> >> >>> > what
>> >> >> >>> > tracks clip commands work on are obviously:
>> >> >> >>> > 1. focused track
>> >> >> >>> > 2. selected tracks
>> >> >> >>> > 3. all tracks.
>> >> >> >>> >
>> >> >> >>> > It's just a question of working out which of these would be
>> >> >> >>> > useful.
>> >> >> >>> >
>> >> >> >>> > David.
>> >> >> >>>
>> >> >> >>> Tracks->Pan already combines 2 and 3.  It is 'All selected
>> tracks,
>> >> >> >>> or
>> >> >> >>> all tracks, if none selected'.
>> >> >> >>
>> >> >> >>
>> >> >> >> This probably mainly of interest to Robert. I've implemented
>> James'
>> >> >> >> suggestion of   'All selected tracks, or
>> >> >> >> all tracks, if none selected' for the cursor to clip boundaries,
>> and
>> >> >> >> select to clip boundaries. It's available in the clipnavbnd
>> >> >> >> branch
>> >> >> >> in
>> >> >> >> my
>> >> >> >> fork of Audacity.
>> >> >> >
>> >> >> >
>> >> >> > I've updated the behaviour of the six commands listed below so
>> >> >> > that
>> >> >> > if
>> >> >> > any
>> >> >> > audio tracks are selected, the clips in those tracks are used,
>> >> >> > otherwise
>> >> >> > the
>> >> >> > clips in all audio tracks are used:
>> >> >> > Cursor to Previous clip boundary
>> >> >> > Cursor to Next clip boundary
>> >> >> > Select previous clip boundary to cursor
>> >> >> > Select cursor to next clip boundary
>> >> >> > Select Previous Clip
>> >> >> > Select Next clip
>> >> >> >
>> >> >> > relevant commits:
>> >> >> >
>> >> >> >
>> >> >> > https://github.com/audacity/audacity/commit/
>> ce1d067f84f87e945dcef55a61625ed532e85bfc
>> >> >> >
>> >> >> >
>> >> >> > https://github.com/audacity/audacity/commit/
>> baf46c1f855501fce572a20fb3676d9d2dd41bf0
>> >> >>
>> >> >> Thanks, David. I added some text to the Manual.
>> >> >>
>> >> >> However, Select > Clip Boundaries > Previous Clip behaves
>> >> >> differently
>> >> >> to
>> >> >> Next Clip in the same menu, which seems wrong to me.
>> >> >>
>> >> >> Starting from a cursor or partial selection somewhere in a clip,
>> >> >> Next
>> >> >> Clip
>> >> >> goes straight to the next clip and fully selects it. But Previous
>> Clip,
>> >> >> starting from a cursor or partial selection in a clip, first fully
>> >> >> selects
>> >> >> in
>> >> >> the current clip. So you need another activation of the command to
>> move
>> >> >> into and fully select the previous clip.
>> >> >
>> >> >
>> >> > I think this behaviour is what a user would expect.
>> >> > eg in text editors, if you place the cursor in the middle of a word,
>> >> > then:
>> >> > 1. Pressing ctrl + right arrow moves you the the start of the next
>> word.
>> >> > 2. Pressing ctrl + left arrow moves you to the start of the current
>> >> > word.
>> >> >
>> >> > As another example, in the Reaper audio editor, if the edit cursor
>> >> > is
>> in
>> >> > the
>> >> > middle of an item(similar to clips), then:
>> >> > 1. Select next item, selects the next item.
>> >> > 2. Select previous item, selects the current item.
>> >>
>> >> OK, thanks David. I'll have to accept this, but as someone who doesn't
>> >> use keyboard navigation in documents, it seems unintuitive to me.
>> >> I can only guess the logic as giving primacy to the start of the word.
>> >>
>> >> >From what I understood from a quick search, there is no universal
>> >> shortcut
>> >> for the opposite of Ctrl + Left (move the cursor to the end of a word)
>> or
>> >> for the opposite of Ctrl + Right (move to the start of the previous
>> word).
>> >>
>> >>
>> >> > With the current behaviour, if the cursor is somewhere in the clip,
>> you
>> >> > can
>> >> > always select the current clip by using next or previous clip.
>> >>
>> >> Doesn't work for me. To select the current clip I must use Select >
>> >> Clip
>> >> Boundaries > Previous Clip, as you have just described. Next Clip
>> >> always selects the next clip.
>> >
>> >
>> > If the cursor is exactly at the start of the clip, then the clip can be
>> > selected using select next clip.
>>
>> And if the cursor is exactly at the start of a clip, should "Previous
>> Clip"
>> select the previous clip?
>>
>
> Yes.
>
>
>>
>> If I double-click in the second clip in the "clips1" project, OR if I
>> press
>> Home then use Select menu's "Next Clip" command twice, then Left
>> arrow, sometimes "Previous Clip" will select the previous clip,
>> sometimes it will select the current (second) clip.
>>
>
> this could be due to the rounding errors. I'll look at this later.
>
>>
>>
>> > If the cursor is anywhere else in the clip, then select previous clip
>> > has
>> > to be used.
>> >>
>> >>
>> >>
>> >> >>
>> >> >> Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor
>> >> >> and
>> >> >> Cursor to Next Clip Boundary seem to do nothing every other
>> >> >> command.
>> >> >>
>> >> >> Example, create three clips in a track. Click in the first clip,
>> >> >> then
>> >> >> call
>> >> >> Cursor to Next Clip Boundary.That selects to the end of the left
>> >> >> edge
>> >> >> of
>> >> >> the next clip, but the next call of the command does nothing. Call
>> >> >> it
>> >> >> again
>> >> >> and it extends the selection to the left edge of the next clip, as
>> >> >> expected.
>> >> >>
>> >> >> This "double action required" also affects Transport > Cursor to >
>> >> >> Previous Clip Boundary and Next Clip Boundary.
>> >> >
>> >> >
>> >> > Thanks for testing this. Unfortunately, I can't reproduce your
>> results.
>> >> > Most
>> >> > strange.
>> >>
>> >> It might have something to do with the position of the clip boundaries
>> or
>> >> even the window size, but something isn't right. If the problem
>> >> happens,
>> >> it is 100% repeatable for me.
>> >>
>> >> Could you try http://gaclrecords.org.uk/bugs/clip_commands_tests.zip ?
>> >
>> >
>> > Thanks for these. I've had a quick look - it may be a problem due to
>> > rounding errors. I've been aware that they might cause a problem, but
>> they
>> > hadn't shown up with my own experiments. I'll take a close look in the
>> near
>> > future.
>> >
>> > Did you use the command clip boundaries->split to create the clips?
>> > (This
>> > may sound like a silly question, but I just want to check).
>>
>> Yes, but always with the shortcut CTRL + I, not going through the menus.
>>
>> And I always placed the cursor with the mouse, not with Selection
>> Toolbar,
>> before issuing the Split command.
>>
>>
>> > Some info: If two clips are immediately next to each other, then (apart
>> from
>> > rounding errors) the end of the first clip, and the start of the second
>> clip
>> > occur at the same time. My code interprets that as a single boundary.
>> >
>> > In the clips 1 projects, the end of the first clip comes after the
>> > start
>> of
>> > the second clip, I presume due to rounding errors.
>>
>> How are you determining that's the case? In NVDA?
>>
>
> I was just basing it on what NVDA was reading out - that is it was finding
> the start of the first clip before the end of the first. I've since
> confirmed this by some debuging.
>
>>
>> If I press HOME, then use Transport > Cursor to > Next Clip Boundary,
>> I hear with the first execution of the command "Start 2 of 3". The
>> next execution is read as "End 1 of 3" and that command does nothing.
>>
>> Continuing, I hear "End 2 of 3", "Start 3 of 3" (the command does
>> nothing)
>> and finally "End 3 of 3".
>>
>
> Just to add that when the command does nothing, it's in fact moving the
> cursor by a very very small amount. As I've said, the intention is that if
> two clips are immediately next to each other, then the end of the first
> clip and the start of the second, which barring rounding errors have the
> same times, will be treated as a single boundary.
>
>>
>>
>> > If you want to find out which boundaries my code thinks it has found,
>> just
>> > run NVDA, and it will tell you.
>> > If you time shift the clips so that there are gaps between them, then
>> there
>> > won't be any problems with rounding errors.
>> >
>> > Supplementary question:
>> >
>> > Assuming that you used clip boundaries->split, to get the three clips,
>> did
>> > you:
>> > 1. Select a region, then use the command.
>> > 2. (Position the cursor, use the command) twice.
>>
>> Position the cursor with the mouse, Ctrl + I, position the cursor further
>> down the track, Ctrl + I.
>>
>
> thanks for all your testing and feedback,
> David.
>
>
>>
>>
>>
>> Gale
>>
>> >>
>> >> A) Testing on Windows 10, window maximised, if I open the "clips1"
>> >> project,
>> >>      Select > Clip Boundaries > Previous Clip Boundary to Cursor does
>> >> nothing
>> >>      until called a second time.
>> >>
>> >> B) If I then use Selection Toolbar to place the cursor at 10.000
>> seconds,
>> >>      Select > Clip Boundaries > Cursor to Next Clip Boundary selects
>> from
>> >>      10s to the next boundary, called again it does nothing, called
>> again
>> >>      it selects to the end of the track.
>> >>
>> >> If I move this project to my Linux netbook, then A) reproduces the
>> >> same,
>> >> but in B), Cursor to Next Clip Boundary does nothing after selecting
>> from
>> >> 10s to the next boundary, however many times I call it.
>> >>
>> >> Then try the "linux clip" project. I created this on Ubuntu 14.04. It
>> >> shows
>> >> the same behaviour there as B) in the "clips1" project:  Select > Clip
>> >> Boundaries > Cursor to Next Clip Boundary refuses to do anything. But
>> >> on Windows 10, the command works first time.
>> >>
>> >>
>> >> Gale
>> >>
>> >>
>> >> > Could others test this please,
>> >> >
>> >> > thanks,
>> >> > David.
>> >> >>
>> >> >>
>> >> >>
>> >> >> Gale
>> >> >>
>> >> >>
>> >> >> >>> I am a little concerned at the menus ballooning again as we add
>> >> >> >>> more
>> >> >> >>> options, some of which are extremely useful to VI users but
>> >> >> >>> that
>> >> >> >>> may
>> >> >> >>> be
>> >> >> >>> overload for sighted users.
>> >> >> >>>
>> >> >> >>> The current ideas do seem to be pointing to a Track dialog for
>> >> >> >>> VI
>> >> >> >>> use.
>> >> >> >>> Just as we have a Labels editor dialog that was created for VI
>> use,
>> >> >> >>> but
>> >> >> >>> is useful to sighted users too, thinking in terms of a grid
>> >> >> >>> based
>> >> >> >>> track
>> >> >> >>> editor may be more fruitful than ballooning of the menus.
>> >> >> >>>
>> >> >> >>> --James.
>> >> >>
>> >> >>
>> >> >>
>> >> >> ------------------------------------------------------------
>> ------------------
>> >> >> Check out the vibrant tech community on one of the world's most
>> >> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> >> _______________________________________________
>> >> >> Audacity-quality mailing list
>> >> >> [hidden email]
>> >> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------
>> ------------------
>> >> > Check out the vibrant tech community on one of the world's most
>> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> > _______________________________________________
>> >> > Audacity-quality mailing list
>> >> > [hidden email]
>> >> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >
>> >>
>> >>
>> >> ------------------------------------------------------------
>> ------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>> >
>> >
>> > ------------------------------------------------------------
>> ------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

David Bailes-3
In reply to this post by Gale
On Wed, May 3, 2017 at 6:51 PM, Gale Andrews <[hidden email]> wrote:
On 3 May 2017 at 13:15, David Bailes <[hidden email]> wrote:
> On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]> wrote:
>>
>> On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
>> > On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]>
>> > wrote:
>> >>
>> >> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>> >>>
>> >>> On 4/7/2017 9:53 AM, David Bailes wrote:
>> >>> > James has already suggested that there should also be commands that
>> >>> > work in
>> >>> > more than one track, and I agree with that. The possibilities for
>> >>> > what
>> >>> > tracks clip commands work on are obviously:
>> >>> > 1. focused track
>> >>> > 2. selected tracks
>> >>> > 3. all tracks.
>> >>> >
>> >>> > It's just a question of working out which of these would be useful.
>> >>> >
>> >>> > David.
>> >>>
>> >>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
>> >>> all tracks, if none selected'.
>> >>
>> >>
>> >> This probably mainly of interest to Robert. I've implemented James'
>> >> suggestion of   'All selected tracks, or
>> >> all tracks, if none selected' for the cursor to clip boundaries, and
>> >> select to clip boundaries. It's available in the clipnavbnd branch in
>> >> my
>> >> fork of Audacity.
>> >
>> >
>> > I've updated the behaviour of the six commands listed below so that if
>> > any
>> > audio tracks are selected, the clips in those tracks are used, otherwise
>> > the
>> > clips in all audio tracks are used:
>> > Cursor to Previous clip boundary
>> > Cursor to Next clip boundary
>> > Select previous clip boundary to cursor
>> > Select cursor to next clip boundary
>> > Select Previous Clip
>> > Select Next clip
>> >
>> > relevant commits:
>> >
>> > https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
>> >
>> > https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0
>>
>> Thanks, David. I added some text to the Manual.
>>
>> However, Select > Clip Boundaries > Previous Clip behaves differently to
>> Next Clip in the same menu, which seems wrong to me.
>>
>> Starting from a cursor or partial selection somewhere in a clip, Next Clip
>> goes straight to the next clip and fully selects it. But Previous Clip,
>> starting from a cursor or partial selection in a clip, first fully selects
>> in
>> the current clip. So you need another activation of the command to move
>> into and fully select the previous clip.
>
>
> I think this behaviour is what a user would expect.
> eg in text editors, if you place the cursor in the middle of a word, then:
> 1. Pressing ctrl + right arrow moves you the the start of the next word.
> 2. Pressing ctrl + left arrow moves you to the start of the current word.
>
> As another example, in the Reaper audio editor, if the edit cursor is in the
> middle of an item(similar to clips), then:
> 1. Select next item, selects the next item.
> 2. Select previous item, selects the current item.

OK, thanks David. I'll have to accept this, but as someone who doesn't
use keyboard navigation in documents, it seems unintuitive to me.
I can only guess the logic as giving primacy to the start of the word.

>From what I understood from a quick search, there is no universal shortcut
for the opposite of Ctrl + Left (move the cursor to the end of a word) or
for the opposite of Ctrl + Right (move to the start of the previous word).


> With the current behaviour, if the cursor is somewhere in the clip, you can
> always select the current clip by using next or previous clip.

Doesn't work for me. To select the current clip I must use Select > Clip
Boundaries > Previous Clip, as you have just described. Next Clip
always selects the next clip.


>>
>> Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
>> Cursor to Next Clip Boundary seem to do nothing every other command.
>>
>> Example, create three clips in a track. Click in the first clip, then call
>> Cursor to Next Clip Boundary.That selects to the end of the left edge of
>> the next clip, but the next call of the command does nothing. Call it
>> again
>> and it extends the selection to the left edge of the next clip, as
>> expected.
>>
>> This "double action required" also affects Transport > Cursor to >
>> Previous Clip Boundary and Next Clip Boundary.
>
>
> Thanks for testing this. Unfortunately, I can't reproduce your results. Most
> strange.

It might have something to do with the position of the clip boundaries or
even the window size, but something isn't right. If the problem happens,
it is 100% repeatable for me.

Could you try http://gaclrecords.org.uk/bugs/clip_commands_tests.zip ?

A) Testing on Windows 10, window maximised, if I open the "clips1" project,
     Select > Clip Boundaries > Previous Clip Boundary to Cursor does nothing
     until called a second time.

B) If I then use Selection Toolbar to place the cursor at 10.000 seconds,
     Select > Clip Boundaries > Cursor to Next Clip Boundary selects from
     10s to the next boundary, called again it does nothing, called again
     it selects to the end of the track.

If I move this project to my Linux netbook, then A) reproduces the same,
but in B), Cursor to Next Clip Boundary does nothing after selecting from
10s to the next boundary, however many times I call it.

Then try the "linux clip" project. I created this on Ubuntu 14.04. It shows
the same behaviour there as B) in the "clips1" project:  Select > Clip
Boundaries > Cursor to Next Clip Boundary refuses to do anything. But
on Windows 10, the command works first time.

I've committed a fix for the rounding error problem that I think was causing this:

On Windows, the clip commands now seem to work with the two projects which you posted.

David.
 


Gale


> Could others test this please,
>
> thanks,
> David.
>>
>>
>>
>> Gale
>>
>>
>> >>> I am a little concerned at the menus ballooning again as we add more
>> >>> options, some of which are extremely useful to VI users but that may
>> >>> be
>> >>> overload for sighted users.
>> >>>
>> >>> The current ideas do seem to be pointing to a Track dialog for VI use.
>> >>> Just as we have a Labels editor dialog that was created for VI use,
>> >>> but
>> >>> is useful to sighted users too, thinking in terms of a grid based
>> >>> track
>> >>> editor may be more fruitful than ballooning of the menus.
>> >>>
>> >>> --James.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

Cliff Scott

On May 10, 2017, at 4:02 AM, David Bailes <[hidden email]> wrote:

On Wed, May 3, 2017 at 6:51 PM, Gale Andrews <[hidden email]> wrote:
On 3 May 2017 at 13:15, David Bailes <[hidden email]> wrote:
> On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]> wrote:
>>
>> On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
>> > On Thu, Apr 13, 2017 at 1:54 PM, David Bailes <[hidden email]>
>> > wrote:
>> >>
>> >> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
>> >>>
>> >>> On 4/7/2017 9:53 AM, David Bailes wrote:
>> >>> > James has already suggested that there should also be commands that
>> >>> > work in
>> >>> > more than one track, and I agree with that. The possibilities for
>> >>> > what
>> >>> > tracks clip commands work on are obviously:
>> >>> > 1. focused track
>> >>> > 2. selected tracks
>> >>> > 3. all tracks.
>> >>> >
>> >>> > It's just a question of working out which of these would be useful.
>> >>> >
>> >>> > David.
>> >>>
>> >>> Tracks->Pan already combines 2 and 3.  It is 'All selected tracks, or
>> >>> all tracks, if none selected'.
>> >>
>> >>
>> >> This probably mainly of interest to Robert. I've implemented James'
>> >> suggestion of   'All selected tracks, or
>> >> all tracks, if none selected' for the cursor to clip boundaries, and
>> >> select to clip boundaries. It's available in the clipnavbnd branch in
>> >> my
>> >> fork of Audacity.
>> >
>> >
>> > I've updated the behaviour of the six commands listed below so that if
>> > any
>> > audio tracks are selected, the clips in those tracks are used, otherwise
>> > the
>> > clips in all audio tracks are used:
>> > Cursor to Previous clip boundary
>> > Cursor to Next clip boundary
>> > Select previous clip boundary to cursor
>> > Select cursor to next clip boundary
>> > Select Previous Clip
>> > Select Next clip
>> >
>> > relevant commits:
>> >
>> > https://github.com/audacity/audacity/commit/ce1d067f84f87e945dcef55a61625ed532e85bfc
>> >
>> > https://github.com/audacity/audacity/commit/baf46c1f855501fce572a20fb3676d9d2dd41bf0
>>
>> Thanks, David. I added some text to the Manual.
>>
>> However, Select > Clip Boundaries > Previous Clip behaves differently to
>> Next Clip in the same menu, which seems wrong to me.
>>
>> Starting from a cursor or partial selection somewhere in a clip, Next Clip
>> goes straight to the next clip and fully selects it. But Previous Clip,
>> starting from a cursor or partial selection in a clip, first fully selects
>> in
>> the current clip. So you need another activation of the command to move
>> into and fully select the previous clip.
>
>
> I think this behaviour is what a user would expect.
> eg in text editors, if you place the cursor in the middle of a word, then:
> 1. Pressing ctrl + right arrow moves you the the start of the next word.
> 2. Pressing ctrl + left arrow moves you to the start of the current word.
>
> As another example, in the Reaper audio editor, if the edit cursor is in the
> middle of an item(similar to clips), then:
> 1. Select next item, selects the next item.
> 2. Select previous item, selects the current item.

OK, thanks David. I'll have to accept this, but as someone who doesn't
use keyboard navigation in documents, it seems unintuitive to me.
I can only guess the logic as giving primacy to the start of the word.

>From what I understood from a quick search, there is no universal shortcut
for the opposite of Ctrl + Left (move the cursor to the end of a word) or
for the opposite of Ctrl + Right (move to the start of the previous word).


> With the current behaviour, if the cursor is somewhere in the clip, you can
> always select the current clip by using next or previous clip.

Doesn't work for me. To select the current clip I must use Select > Clip
Boundaries > Previous Clip, as you have just described. Next Clip
always selects the next clip.


>>
>> Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor and
>> Cursor to Next Clip Boundary seem to do nothing every other command.
>>
>> Example, create three clips in a track. Click in the first clip, then call
>> Cursor to Next Clip Boundary.That selects to the end of the left edge of
>> the next clip, but the next call of the command does nothing. Call it
>> again
>> and it extends the selection to the left edge of the next clip, as
>> expected.
>>
>> This "double action required" also affects Transport > Cursor to >
>> Previous Clip Boundary and Next Clip Boundary.
>
>
> Thanks for testing this. Unfortunately, I can't reproduce your results. Most
> strange.

It might have something to do with the position of the clip boundaries or
even the window size, but something isn't right. If the problem happens,
it is 100% repeatable for me.

Could you try http://gaclrecords.org.uk/bugs/clip_commands_tests.zip ?

A) Testing on Windows 10, window maximised, if I open the "clips1" project,
     Select > Clip Boundaries > Previous Clip Boundary to Cursor does nothing
     until called a second time.

B) If I then use Selection Toolbar to place the cursor at 10.000 seconds,
     Select > Clip Boundaries > Cursor to Next Clip Boundary selects from
     10s to the next boundary, called again it does nothing, called again
     it selects to the end of the track.

If I move this project to my Linux netbook, then A) reproduces the same,
but in B), Cursor to Next Clip Boundary does nothing after selecting from
10s to the next boundary, however many times I call it.

Then try the "linux clip" project. I created this on Ubuntu 14.04. It shows
the same behaviour there as B) in the "clips1" project:  Select > Clip
Boundaries > Cursor to Next Clip Boundary refuses to do anything. But
on Windows 10, the command works first time.

I've committed a fix for the rounding error problem that I think was causing this:

On Windows, the clip commands now seem to work with the two projects which you posted.

David.

Built Audacity today and it seems good on the Mac w/Sierra.

Cliff

 


Gale


> Could others test this please,
>
> thanks,
> David.
>>
>>
>>
>> Gale
>>
>>
>> >>> I am a little concerned at the menus ballooning again as we add more
>> >>> options, some of which are extremely useful to VI users but that may
>> >>> be
>> >>> overload for sighted users.
>> >>>
>> >>> The current ideas do seem to be pointing to a Track dialog for VI use.
>> >>> Just as we have a Labels editor dialog that was created for VI use,
>> >>> but
>> >>> is useful to sighted users too, thinking in terms of a grid based
>> >>> track
>> >>> editor may be more fruitful than ballooning of the menus.
>> >>>
>> >>> --James.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Commands to navigate between clips

David Bailes-3
In reply to this post by Robert Hänggi
On Fri, May 5, 2017 at 5:57 AM, Robert Hänggi <[hidden email]> wrote:
Hi David

Sorry that I'm replying so late.
My computer has been down for three weeks due to an attempted upgrade
to Windows 10 (well, it works now more or less).

Clips are still somewhat mysterious to me, especially when we are
dealing with multiple tracks.
I will focus (cross your fingers) on one track projects for now.

I gave clips a lot of thought and know therefore what problems you're
facing. Thanks for your engagement.

In my view, it would be enough to call the submenu of "Select" simply
"Clips" because it also holds commands that select clips and not just
boundaries.

Yes, I agree.
 

I'm navigating full clips with control+arrows and it works fine, in
the way you've defined it.

However, the nomenclature is somewhat confusing. I get an output like
"two of four, one of one". I would always add "Clips" after e.g. "of
four" because navigating through unnamed labels would give the same
output.

I've added the word clip or clips where appropriate. Is that better?
 

As I said earlier, I would also include the gaps in the navigation,
e.g. "White space before 3 of 5 Clips". However, this can easily be
achieved by "cursor to next Clip Boundary" and multiple tracks are
certainly challenging in this respect...

I don't think the select clip commands should also select the gaps. I don't think the user would expect this, and it would slow the traversal of clips down. As you say, the gaps can be selected using the clip boundary commands.


Expanding a selected clip to the next boundary does not appropriately
change the "track" name.
For example, with clip two selected, "Cursor to Next Boundary" returns
"End 3 of 5 and start 4" whereas it should read something like
"Start 2 to end 3 (of 5 clips)"
With a bit context-sensitive differentiation this could be simplified to e.g.
"Clips two to 3 of 5".

The commands currently tell the user where one end of the selection has been moved to. I think that's normal when you extend a selection. For example, if a number of files in a list are selected, and you add another file to the selection, screen readers just read out the name of the file added to the selection. I think that describing the current selection, like the Jaws command for reading the current selection is another task. Also if you select from the cursor to the next clip boundary, the cursor is not necessarily on a clip boundary and so description of the selection is not just in terms of clips.

thanks for the feedback,
David.
 

That's all for now.
Thanks
Robert

On 04/05/2017, David Bailes <[hidden email]> wrote:
> On Wed, May 3, 2017 at 8:59 PM, Gale Andrews <[hidden email]> wrote:
>
>> On 3 May 2017 at 19:36, David Bailes <[hidden email]> wrote:
>> > On Wed, May 3, 2017 at 6:51 PM, Gale Andrews <[hidden email]>
>> wrote:
>> >>
>> >> On 3 May 2017 at 13:15, David Bailes <[hidden email]> wrote:
>> >> > On Wed, May 3, 2017 at 3:29 AM, Gale Andrews <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> On 1 May 2017 at 10:27, David Bailes <[hidden email]> wrote:
>> >> >> > On Thu, Apr 13, 2017 at 1:54 PM, David Bailes
>> >> >> > <[hidden email]>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Fri, Apr 7, 2017 at 10:21 AM, James Crook <[hidden email]>
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> On 4/7/2017 9:53 AM, David Bailes wrote:
>> >> >> >>> > James has already suggested that there should also be
>> >> >> >>> > commands
>> >> >> >>> > that
>> >> >> >>> > work in
>> >> >> >>> > more than one track, and I agree with that. The possibilities
>> for
>> >> >> >>> > what
>> >> >> >>> > tracks clip commands work on are obviously:
>> >> >> >>> > 1. focused track
>> >> >> >>> > 2. selected tracks
>> >> >> >>> > 3. all tracks.
>> >> >> >>> >
>> >> >> >>> > It's just a question of working out which of these would be
>> >> >> >>> > useful.
>> >> >> >>> >
>> >> >> >>> > David.
>> >> >> >>>
>> >> >> >>> Tracks->Pan already combines 2 and 3.  It is 'All selected
>> tracks,
>> >> >> >>> or
>> >> >> >>> all tracks, if none selected'.
>> >> >> >>
>> >> >> >>
>> >> >> >> This probably mainly of interest to Robert. I've implemented
>> James'
>> >> >> >> suggestion of   'All selected tracks, or
>> >> >> >> all tracks, if none selected' for the cursor to clip boundaries,
>> and
>> >> >> >> select to clip boundaries. It's available in the clipnavbnd
>> >> >> >> branch
>> >> >> >> in
>> >> >> >> my
>> >> >> >> fork of Audacity.
>> >> >> >
>> >> >> >
>> >> >> > I've updated the behaviour of the six commands listed below so
>> >> >> > that
>> >> >> > if
>> >> >> > any
>> >> >> > audio tracks are selected, the clips in those tracks are used,
>> >> >> > otherwise
>> >> >> > the
>> >> >> > clips in all audio tracks are used:
>> >> >> > Cursor to Previous clip boundary
>> >> >> > Cursor to Next clip boundary
>> >> >> > Select previous clip boundary to cursor
>> >> >> > Select cursor to next clip boundary
>> >> >> > Select Previous Clip
>> >> >> > Select Next clip
>> >> >> >
>> >> >> > relevant commits:
>> >> >> >
>> >> >> >
>> >> >> > https://github.com/audacity/audacity/commit/
>> ce1d067f84f87e945dcef55a61625ed532e85bfc
>> >> >> >
>> >> >> >
>> >> >> > https://github.com/audacity/audacity/commit/
>> baf46c1f855501fce572a20fb3676d9d2dd41bf0
>> >> >>
>> >> >> Thanks, David. I added some text to the Manual.
>> >> >>
>> >> >> However, Select > Clip Boundaries > Previous Clip behaves
>> >> >> differently
>> >> >> to
>> >> >> Next Clip in the same menu, which seems wrong to me.
>> >> >>
>> >> >> Starting from a cursor or partial selection somewhere in a clip,
>> >> >> Next
>> >> >> Clip
>> >> >> goes straight to the next clip and fully selects it. But Previous
>> Clip,
>> >> >> starting from a cursor or partial selection in a clip, first fully
>> >> >> selects
>> >> >> in
>> >> >> the current clip. So you need another activation of the command to
>> move
>> >> >> into and fully select the previous clip.
>> >> >
>> >> >
>> >> > I think this behaviour is what a user would expect.
>> >> > eg in text editors, if you place the cursor in the middle of a word,
>> >> > then:
>> >> > 1. Pressing ctrl + right arrow moves you the the start of the next
>> word.
>> >> > 2. Pressing ctrl + left arrow moves you to the start of the current
>> >> > word.
>> >> >
>> >> > As another example, in the Reaper audio editor, if the edit cursor
>> >> > is
>> in
>> >> > the
>> >> > middle of an item(similar to clips), then:
>> >> > 1. Select next item, selects the next item.
>> >> > 2. Select previous item, selects the current item.
>> >>
>> >> OK, thanks David. I'll have to accept this, but as someone who doesn't
>> >> use keyboard navigation in documents, it seems unintuitive to me.
>> >> I can only guess the logic as giving primacy to the start of the word.
>> >>
>> >> >From what I understood from a quick search, there is no universal
>> >> shortcut
>> >> for the opposite of Ctrl + Left (move the cursor to the end of a word)
>> or
>> >> for the opposite of Ctrl + Right (move to the start of the previous
>> word).
>> >>
>> >>
>> >> > With the current behaviour, if the cursor is somewhere in the clip,
>> you
>> >> > can
>> >> > always select the current clip by using next or previous clip.
>> >>
>> >> Doesn't work for me. To select the current clip I must use Select >
>> >> Clip
>> >> Boundaries > Previous Clip, as you have just described. Next Clip
>> >> always selects the next clip.
>> >
>> >
>> > If the cursor is exactly at the start of the clip, then the clip can be
>> > selected using select next clip.
>>
>> And if the cursor is exactly at the start of a clip, should "Previous
>> Clip"
>> select the previous clip?
>>
>
> Yes.
>
>
>>
>> If I double-click in the second clip in the "clips1" project, OR if I
>> press
>> Home then use Select menu's "Next Clip" command twice, then Left
>> arrow, sometimes "Previous Clip" will select the previous clip,
>> sometimes it will select the current (second) clip.
>>
>
> this could be due to the rounding errors. I'll look at this later.
>
>>
>>
>> > If the cursor is anywhere else in the clip, then select previous clip
>> > has
>> > to be used.
>> >>
>> >>
>> >>
>> >> >>
>> >> >> Also, Select > Clip Boundaries > Previous Clip Boundary to Cursor
>> >> >> and
>> >> >> Cursor to Next Clip Boundary seem to do nothing every other
>> >> >> command.
>> >> >>
>> >> >> Example, create three clips in a track. Click in the first clip,
>> >> >> then
>> >> >> call
>> >> >> Cursor to Next Clip Boundary.That selects to the end of the left
>> >> >> edge
>> >> >> of
>> >> >> the next clip, but the next call of the command does nothing. Call
>> >> >> it
>> >> >> again
>> >> >> and it extends the selection to the left edge of the next clip, as
>> >> >> expected.
>> >> >>
>> >> >> This "double action required" also affects Transport > Cursor to >
>> >> >> Previous Clip Boundary and Next Clip Boundary.
>> >> >
>> >> >
>> >> > Thanks for testing this. Unfortunately, I can't reproduce your
>> results.
>> >> > Most
>> >> > strange.
>> >>
>> >> It might have something to do with the position of the clip boundaries
>> or
>> >> even the window size, but something isn't right. If the problem
>> >> happens,
>> >> it is 100% repeatable for me.
>> >>
>> >> Could you try http://gaclrecords.org.uk/bugs/clip_commands_tests.zip ?
>> >
>> >
>> > Thanks for these. I've had a quick look - it may be a problem due to
>> > rounding errors. I've been aware that they might cause a problem, but
>> they
>> > hadn't shown up with my own experiments. I'll take a close look in the
>> near
>> > future.
>> >
>> > Did you use the command clip boundaries->split to create the clips?
>> > (This
>> > may sound like a silly question, but I just want to check).
>>
>> Yes, but always with the shortcut CTRL + I, not going through the menus.
>>
>> And I always placed the cursor with the mouse, not with Selection
>> Toolbar,
>> before issuing the Split command.
>>
>>
>> > Some info: If two clips are immediately next to each other, then (apart
>> from
>> > rounding errors) the end of the first clip, and the start of the second
>> clip
>> > occur at the same time. My code interprets that as a single boundary.
>> >
>> > In the clips 1 projects, the end of the first clip comes after the
>> > start
>> of
>> > the second clip, I presume due to rounding errors.
>>
>> How are you determining that's the case? In NVDA?
>>
>
> I was just basing it on what NVDA was reading out - that is it was finding
> the start of the first clip before the end of the first. I've since
> confirmed this by some debuging.
>
>>
>> If I press HOME, then use Transport > Cursor to > Next Clip Boundary,
>> I hear with the first execution of the command "Start 2 of 3". The
>> next execution is read as "End 1 of 3" and that command does nothing.
>>
>> Continuing, I hear "End 2 of 3", "Start 3 of 3" (the command does
>> nothing)
>> and finally "End 3 of 3".
>>
>
> Just to add that when the command does nothing, it's in fact moving the
> cursor by a very very small amount. As I've said, the intention is that if
> two clips are immediately next to each other, then the end of the first
> clip and the start of the second, which barring rounding errors have the
> same times, will be treated as a single boundary.
>
>>
>>
>> > If you want to find out which boundaries my code thinks it has found,
>> just
>> > run NVDA, and it will tell you.
>> > If you time shift the clips so that there are gaps between them, then
>> there
>> > won't be any problems with rounding errors.
>> >
>> > Supplementary question:
>> >
>> > Assuming that you used clip boundaries->split, to get the three clips,
>> did
>> > you:
>> > 1. Select a region, then use the command.
>> > 2. (Position the cursor, use the command) twice.
>>
>> Position the cursor with the mouse, Ctrl + I, position the cursor further
>> down the track, Ctrl + I.
>>
>
> thanks for all your testing and feedback,
> David.
>
>
>>
>>
>>
>> Gale
>>
>> >>
>> >> A) Testing on Windows 10, window maximised, if I open the "clips1"
>> >> project,
>> >>      Select > Clip Boundaries > Previous Clip Boundary to Cursor does
>> >> nothing
>> >>      until called a second time.
>> >>
>> >> B) If I then use Selection Toolbar to place the cursor at 10.000
>> seconds,
>> >>      Select > Clip Boundaries > Cursor to Next Clip Boundary selects
>> from
>> >>      10s to the next boundary, called again it does nothing, called
>> again
>> >>      it selects to the end of the track.
>> >>
>> >> If I move this project to my Linux netbook, then A) reproduces the
>> >> same,
>> >> but in B), Cursor to Next Clip Boundary does nothing after selecting
>> from
>> >> 10s to the next boundary, however many times I call it.
>> >>
>> >> Then try the "linux clip" project. I created this on Ubuntu 14.04. It
>> >> shows
>> >> the same behaviour there as B) in the "clips1" project:  Select > Clip
>> >> Boundaries > Cursor to Next Clip Boundary refuses to do anything. But
>> >> on Windows 10, the command works first time.
>> >>
>> >>
>> >> Gale
>> >>
>> >>
>> >> > Could others test this please,
>> >> >
>> >> > thanks,
>> >> > David.
>> >> >>
>> >> >>
>> >> >>
>> >> >> Gale
>> >> >>
>> >> >>
>> >> >> >>> I am a little concerned at the menus ballooning again as we add
>> >> >> >>> more
>> >> >> >>> options, some of which are extremely useful to VI users but
>> >> >> >>> that
>> >> >> >>> may
>> >> >> >>> be
>> >> >> >>> overload for sighted users.
>> >> >> >>>
>> >> >> >>> The current ideas do seem to be pointing to a Track dialog for
>> >> >> >>> VI
>> >> >> >>> use.
>> >> >> >>> Just as we have a Labels editor dialog that was created for VI
>> use,
>> >> >> >>> but
>> >> >> >>> is useful to sighted users too, thinking in terms of a grid
>> >> >> >>> based
>> >> >> >>> track
>> >> >> >>> editor may be more fruitful than ballooning of the menus.
>> >> >> >>>
>> >> >> >>> --James.
>> >> >>
>> >> >>
>> >> >>
>> >> >> ------------------------------------------------------------
>> ------------------
>> >> >> Check out the vibrant tech community on one of the world's most
>> >> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> >> _______________________________________________
>> >> >> Audacity-quality mailing list
>> >> >> [hidden email]
>> >> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------
>> ------------------
>> >> > Check out the vibrant tech community on one of the world's most
>> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> > _______________________________________________
>> >> > Audacity-quality mailing list
>> >> > [hidden email]
>> >> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >
>> >>
>> >>
>> >> ------------------------------------------------------------
>> ------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>> >
>> >
>> > ------------------------------------------------------------
>> ------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
12
Loading...