Include information about project markers in our feedback for REAPER actions that navigate by measure and beat

[ScottChesworth]

Can project markers be included in reports when navigating with Page and Control+Page keys (by measure or beat)? I'm imagining two additional reports, one that prepends a short word like "at" when the edit cursor lands on the same position as a project marker, another that prepends the word "passed" then name of project marker. Example reports: Bar 3, bar 4, at marker Verse bar 5, bar 6. Bar 3 beat 2 50%, bar 4, passed marker verse bar 5. Could also be name of marker then the word marker like this: Bar 3, bar 4, at Verse marker bar 5, bar 6. The marker information could be prepended or appended, but I reckon there's a justification for prepending in this case because I've observed many users making these movements in rapid succession, ergo listening for the extra info would slow them down if it was appended.

[jcsteh]

Can you clarify what is being reported in your examples? I don't understand why there are multiple positions reported before the marker. Normally, if I move with the page down key, I would only expect to hear, for example, "bar 3", so I would've thought you might get "bar 3, at marker verse".

[ScottChesworth]

Sorry, could've been clearer. The feedback examples above describe what would be heard as we land at the same position as/pass by a project marker called Verse that's located at bar 5 beat 1 0%, starting from a couple bars before it and navigating forward by pressing PageDown (action Move edit cursor forward one measure).

[jcsteh]

Prepending is a slipperry slope. We've pushed back on prepending marker info for item navigation precisely because it breaks the rule that we shouldn't assume that the user cares about something else more than they care about the action they just executed. When moving by bar or beat, the action is moving by bar or beat, not marker. So how do we objectively justify breaking the rule, other than "some users want to move fast but still get marker info", which feels pretty subjective?

To put this another way, why is it okay to prepend for bar/beat navigation but not item navigation?

[ScottChesworth]

why is it okay to prepend for bar/beat navigation but not item navigation?

These pieces of information are both relevant to the ruler, it's a stronger contextual link. I can see why you'd prefer appending it though. It'll be useful either way.

[jcsteh]

I'll be really honest: I'd prefer prepending it, but I'd also prefer prepending it for item navigation, and yet I can't justify the latter objectively (but can see why it's potentially problematic). So I'm kinda torn on this one. Prepending for ruler navigation but not for anything else creates its own kind of inconsistency.

[ScottChesworth]

Prepending for ruler navigation but not for anything else creates its own kind of inconsistency.

My thinking is that navigation using these actions is consistent amounts of movement each time, so even if we prepend, users can still infer position reliably from the prior or next movement. I wouldn't suggest prepending for anything that didn't have a strong contextual relevance, in this case the ruler.

[ScottChesworth]

Re including marker info in item navigation, I still don't get why it's a good idea to report project markers by default for anything other than ruler and maybe regions. It's only one keystroke after navigating through project markers to switch context back to items, Shift+A. If we do include markers in feedback for item navigation, do we also do it for moving through envelope points? How about feedback on exiting the jump dialog? Moving to tempo/stretch/take markers?

[ptorpey]

I haven’t been following this discussion in a lot of detail and am not 100% sure what the originator is asking for in terms of functionality, but just as a thought provoker, I wonder if it is worth considering having different audible sounds play when navigating past certain elements. Jim has taken this approach with the JAWS scripts. For example, when navigating with pageup/pagedown, different sounds are heard when the user moves past a region marker or from one item to another. There is a setting for turning these sounds on or off.

Anyway, just thought I would throw that in here. Sometimes an audible queue can be a more effective and less disruptive way of conveying information to the user than speaking a string of text. I also don’t know if Osara can use sounds in such a way.

P.S. I did suggest that the originator of these thoughts approach Jim about the functionality they are looking for.

--Pete

[ScottChesworth]

I also don’t know if Osara can use sounds in such a way.

It can't yet. If audio cues do become a thing in future, they'll be optional, we'll still need robust patterns that hold up with and without them.

[jcsteh]

Re including marker info in item navigation, I still don't get why it's a good idea to report project markers by default for anything other than ruler and maybe regions. ... If we do include markers in feedback for item navigation, do we also do it for moving through envelope points? How about feedback on exiting the jump dialog? Moving to tempo/stretch/take markers?

That's fair; it's another slippery slope. For what it's worth, my justification is that when you move by item, envelope point, tempo marker, etc., you are also moving along the ruler. It's not the primary context, but it's still a relevant piece of information, which is why we report the position when you navigate by any of those things. If the ruler weren't relevant at all when navigating these things, we wouldn't report the position. As I understand it, markers are just another part of the ruler for sighted users. They can quickly see what position they're at in their preferred units, but they can also easily see where other things are relative to their markers. My thinking is that when you're in certain mindsets, the position numbers become less relevant than where they are relative to key points (AKA markers) in your project. It might be easier for someone to think "this is past chorus 3" rather than "this is past bar 150".

All of that said, I agree this is very slippery and I don't know that we're going to be able to come up with something that makes everyone happy, so it may be best to just let it go for now.

I'm not convinced audio cues would help here, even if we could support them. Sure, an audio cue might indicate that you've passed a marker, but it doesn't tell you what marker, and now you have to go find out anyway.

[ScottChesworth]

an audio cue might indicate that you've passed a marker, but it doesn't tell you what marker, and now you have to go find out anyway.

Also, good luck finding unobtrusive sounds that'll be audible among the racket of assorted thunks clunks clicks and clacks that the JAWS scripts already make. I can't see how additional audio cues would bring clarity for anyone at this point without redesigning a unified sound scheme from the ground up.