Move the edit cursor to the play cursor first for time movement commands

[jcsteh]

Most (maybe all?) time movement commands move relative to the edit cursor even during playback. So, for example, if you start playing at bar 1 and you wait so that you're now playing bar 5, moving to the next bar will take you to bar 2. I find this pretty annoying and unintuitive, and I believe Snowman ended up optionally hacking around this in his JAWS scripts. I'm considering doing this directly in OSARA.

The question is: is there any occasion where the default behaviour is actually more desirable? Do we need to make this optional, and if so, should it be default on or off?

I'm thinking this would also apply to moving by item.

@scottchesworth, I'd be grateful for your thoughts.

[LeonarddeR]

I think it should be optional and initially off. In some cases, it is very helpful if the movement commands apply to the edit cursor, for example if you're trying to find the right place to split/cut. I tend to play/stop a lot when finding the right split point, so I'm accustomed to this behaviour.

I will also ask my brother who is a pretty intensive REAPER user.

I'm thinking this would also play to moving by item.

Indeed, and how about splitting? I often find myself in a situation where I'm at item one and move out of the item's bounds with the time movement commands to item two. However, as soon as I left item one, splitting doesn't do anything. It requires me first to select item two and then find that particular position again.

[jcsteh]

I think it should be optional and initially off. In some cases, it is very helpful if the movement commands apply to the edit cursor, for example if you're trying to find the right place to split/cut. I tend to play/stop a lot when finding the right split point, so I'm accustomed to this behaviour.

I neglected to mention that of course there's always the possibility that this is a terrible idea, that everyone else is happy with this as-is and I should just leave it alone. :)

how about splitting? I often find myself in a situation where I'm at item one and move out of the item's bounds with the time movement commands to item two. However, as soon as I left item one, splitting doesn't do anything. It requires me first to select item two and then find that particular position again.

I think automatically selecting items is potentially dangerous. However, there's a custom action in the OSARA key map bound to the letter "a" which will split the item under the play or edit cursor; i.e. it first selects the item under the cursor (requires SWS) and then splits that. So this functionality is already covered.

[RDMurray]

It should definitely be optional if it happens at all. With this change, moving by bar through a song during playback would always leave the edit cursor at a random point in a bar rather than at the start of the bar.

On Sat, 14 Nov 2020 at 07:26, James Teh notifications@github.com wrote:

Most (maybe all?) time movement commands move relative to the edit cursor even during playback. So, for example, if you start playing at bar 1 and you wait so that you're now playing bar 5, moving to the next bar will take you to bar 2. I find this pretty annoying and unintuitive, and I believe Snowman ended up optionally hacking around this in his JAWS scripts. I'm considering doing this directly in OSARA.

The question is: is there any occasion where the default behaviour is actually more desirable? Do we need to make this optional, and if so, should it be default on or off?

I'm thinking this would also play to moving by item.

@ScottChesworth https://github.com/ScottChesworth, I'd be grateful for your thoughts.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/367, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFSLVM6LGCJ7ZBOQRPEGHYLSPYWKNANCNFSM4TVMPTVA .

[ScottChesworth]

I'm totally onboard with the new behaviour you're proposing @jcsteh, so long as it's optional and we can gauge how the strengths of it by observing how it gets used int the wild before deciding which behaviour is the default. I can see it being super productive in some contexts (long-form dialog editing for example), but equally, it could be a killer in others (grid-based music is the first example springing to mind where to me, the current behaviour would be preferable by a significant margin).

[jcsteh]

Thanks for the feedback. It seems this is potentially less of a good thing than I imagined and it's likely to be tricky to implement, so I may de-prioritise or abandon it.

One further question though: is this what the new (now abandoned) scrubbing custom actions were supposed to do; i.e. scrub from the play cursor? Those wouldn't have been optional. Is there a reason those are a different case?

[ScottChesworth]

Possibly not a reason that was fleshed out enough to please you, no. It was a popular request from podcast editors in particular that they wanted to be able to drop into scrub from the current position (IE, as soon as they here a reason to scrub). So far as I could tell, modifying the behaviour of scrub didn't seem to have any negative impact on the workflows of folks who are more grid-based, because they still had the option of moving by measure/beat maintaining position when they needed to, and the same convenience of "hear an issue, scrub from right near the issue to fix it" would've held up when they needed that.

TBH the existing relationship between edit cursor and playhead location is a rub for some users, particularly those who are switching from software that only has one cursor, and I've seen the current behaviour play havoc with users who don't find it easy to visualize the layout of their projects for whatever reason. I think there'd definitely be value in modifying that behaviour if you can implement it man, particularly if it aligns us more closely with the mainstream UX. Worst case, I'm pretty sure I could whip up a set of custom actions to replicate the current behaviour when moving by measure/beat for people who want that preserved. They'd depend on SWS, but a bunch of stuff already does that.

[jcsteh]

I know I'm the one who raised this idea, but now I'm wondering: why is this any different for blind users as compared to sighted users? Do sighted users get some advantage which makes this more intuitive? I guess they would do a lot of movement with the mouse and they can see the play cursor, so they could just click relative to the position of the play cursor maybe?

Do any other DAWs (as opposed to single track audio editors) have only a single cursor (or at least keep the two in sync by default)? I know Sonar had separate cursors. I worry we might be doing something too different from other comparable DAWs here.

[dgl1984]

It would great to see this toggle in reaper itself, but having a toggle... somewhere, anywhere... would be amazing.The custom scrub actions made dialog editing much faster, but broke more than they fixed for others.----- Original Message -----From: James Teh To: jcsteh/osara Date: Saturday, November 14, 2020 05:45 PMSubject: Re: [jcsteh/osara] Move the edit cursor to the play cursor first for time movement commands (#367)I know I'm the one who raised this idea, but now I'm wondering: why is thisany different for blind users as compared to sighted users? Do sightedusers get some advantage which makes this more intuitive? I guess theywould do a lot of movement with the mouse and they can see the play cursor,so they could just click relative to the position of the play cursor maybe?Do any other DAWs (as opposed to single track audio editors) have only asingle cursor (or at least keep the two in sync by default)? I know Sonarhad separate cursors. I worry we might be doing something too differentfrom other comparable DAWs here.—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[tbdalgaard]

@jcsteh I agree with your first comment. This behaviour will be very nice for people like me who almost anytime use Reaper for dialog and non music related productions. If the idea is that the playback cursor and edit cursor will follow each other while playback is active and therefor move by bars or beats will work relative to the playback cursor this could be quite huge. Then it would be an interesting concept. I do not think that move to next or previous marker, item, region or take marker should be a part of this, but I may be interested to test this. Can I update OSARA without loosing my Reapack scripts again?