jcsteh / osara

OSARA: Open Source Accessibility for the REAPER Application
GNU General Public License v2.0
127 stars 46 forks source link

move and snap individual stretch markers to grid #19

Closed GianlucaApollaro closed 8 years ago

GianlucaApollaro commented 9 years ago

I would like to be able to move a single stretch marker that I create or that gets created when using the split dynamic item dialog and sbnap it to the previous or next grid position. For now we can snap markers in a time selection to grid, but we can't decide where each of them is going, and reaper doesn't always do it right, especially when we're working with drums and 16th notes

jcsteh commented 9 years ago

You're going to need to provide much more detail than this. Sorry, but I don't really understand your workflow with stretch markers. Please explain what REAPER's actions currently do and what you want to do instead. It'd probably be best if you walk through an example scenario, explaining every action you would take (including the new actions you want).

GianlucaApollaro commented 9 years ago

Hi, Let me try to explain what I can do and what I need. I'll put (doable) and (needed) in parens Consider this example: you have a live recording of a multimiked drum kit and you want to put it to click. First we select all items and group them all (doable); we go to dynamic split items and instead of splitting we choose to add stretch markers to all grouped items (doable); We set the grid to what we want e.g. 16th notes (doable); We use the action snap stretch marker to grid and we listen to the result (doable); If the drummer played too far from the click, reaper can snap a part of his drum to the wrong 16 note, so I would like to take that particular stretch marker and move it to the previous or next 16th note. (needed) So the new actions would be move and snap stretch marker to next grid value and move and snap stretch marker to previous grid value. Below I'll provide a YouTube link to show you how a sighted user does it: https://www.youtube.com/watch?v=N24juufOOG8 Hope I provided enough detail Il 25/03/2015 13:50, jcsteh ha scritto:

You're going to need to provide much more detail than this. Sorry, but I don't really understand your workflow with stretch markers. Please explain what REAPER's actions currently do and what you want to do instead. It'd probably be best if you walk through an example scenario, explaining every action you would take (including the new actions you want).

— Reply to this email directly or view it on GitHub https://github.com/jcsteh/osara/issues/19#issuecomment-86011476.

jcsteh commented 9 years ago

From what I can see, except for snapping them to the grid, there's no way a screen reader user can move stretch markers at all once they're created. In contrast, a sighted user can just drag them. Is that correct?

Having done a bit of playing with this, I can certainly see why you'd want these actions you propose. However, I also think there are cases where you might not want to move them on the grid, but rather, to an arbitrary time; e.g. when not using click. The question is how to achieve this.

The problem is that there's no way to actually select stretch markers, so as soon as you move the cursor, we wouldn't know which stretch marker you wanted to move. One option is to have the user select the stretch marker using time selection. Then, the user would move to the desired new point and use an action to move stretch markers in time selection to cursor. Unfortunately, while this is flexible, it's also quite tedious, especially the time selection bit, although I guess that's easy enough with one press of shift+rightArrow.

Thoughts?

jcsteh commented 9 years ago

To explain further, with this workflow I'm proposing, moving a stretch marker to the left on the grid would go as follows:

  1. Move to stretch marker.
  2. Shift+rightArrow to select it.
  3. Control+shift+leftArrow to move back on the grid.
  4. Activate new action to move stretch markers in time selection to cursor.

Of course, moving stretch markers on the grid is probably fairly common, so we might want to still have shortcut actions for this. However, this should illustrate what I'm proposing with regard to manual movement.

ScottChesworth commented 9 years ago

Sorry, I'm confused. The workflow sounds fine to me other than CTRL+Shift+Left arrow. Is that your proposed shortcut for snapping to the nearest grid division to the left of the stretch marker? If so, it'll clash with what seems to be the most logical keystroke to assign to extending item selection to include the previous item.

jcsteh commented 9 years ago

Ug. No. I should know better than to talk using keys. Control+shift+leftArrow is REAPER's default binding for View: Move cursor left to grid division. (I'm not sure what key we'll use for that; I agree extending item selection makes sense for this key.) The new action comes after you've done that.

So, to give another example, you could just as well do this:

  1. Move to stretch marker.
  2. Shift+rightArrow to select it.
  3. Control+j to jump to time, then enter the desired time.
  4. Activate new action to move stretch markers in time selection to cursor.
ScottChesworth commented 9 years ago

Yup, makes sense, just thought it was worth checking. The workflow sounds no more tedious than expected here. Individual timing corrections are a pain from the keyboard it seems, whichever DAW I'm in.

GianlucaApollaro commented 9 years ago

I like it, seems very interesting and has a lot of potential Il 17/04/2015 11:59, ScottChesworth ha scritto:

Yup, makes sense, just thought it was worth checking. The workflow sounds no more tedious than expected here. Individual timing corrections are a pain from the keyboard it seems, whichever DAW I'm in.

— Reply to this email directly or view it on GitHub https://github.com/nvaccess/osara/issues/19#issuecomment-93956417.

jcsteh commented 9 years ago

Individual timing corrections are a pain from the keyboard it seems, whichever DAW I'm in.

Can you conceive of a way we could do better? As Gianluca originally suggested, convenience actions to snap the current stretch marker to the left or right on the grid might still be useful; it narrows 4 steps down to 2. However, I suggested the longer approach to cover cases where you don't want to use the grid; e.g. no click. I certainly don't think we can do any better for that case.

Sidenote: I'm not yet sure how much of this i can actually do from the API. There does seem to be support for stretch markers, but it's unclear as to whether modifying them just repositions them or actually takes stretch action like it would if you drag them with the mouse. I hope the former, but as usual, the documentation is non-existent. There also doesn't seem to be a way to get grid positions, only to snap a specified position to the nearest point on the grid, which is precisely what we don't want. I think I'm going to have to move the edit cursor by calling those grid actions and then move the stretch marker to that position. It's all very ugly, but hopefully, it's possible.

ScottChesworth commented 9 years ago

Nope, I haven't seen anything better anywhere else, this is definitely the best way to move forward IMO. Sorry if my original comment came over as negative.

jcsteh commented 8 years ago

You can now manually move stretch markers by moving to the desired stretch marker, moving to the desired new position and then running the "OSARA: Move last focused stretch marker to current edit cursor position" action. The time selection isn't needed; it's just based on the move to stretch marker actions. This doesn't take care of snapping, but I think it can be used more generally; you should be able to chain it as required.

After coming back to this issue to look at the comments, I just realised that this only moves a single stretch marker. I'm concerned that this won't work for all stretch markers across grouped items. Gianluca, it'd be great if you can test this and report on your findings. If this doesn't work for you, I'll need to try to come up with something else, but I really don't know what. I guess I'll have to track the position of the last stretch marker (not the marker itself) and then fetch the markers across all selected items, but that's pretty error prone.

GianlucaApollaro commented 8 years ago

Hi, I'll certainly test and let you know. Thanks a lot

Il 20/11/2015 07:57, James Teh ha scritto:

You can now manually move stretch markers by moving to the desired stretch marker, moving to the desired new position and then running the "OSARA: Move last focused stretch marker to current edit cursor position" action. The time selection isn't needed; it's just based on the move to stretch marker actions. This doesn't take care of snapping, but I think it can be used more generally; you should be able to chain it as required.

After coming back to this issue to look at the comments, I just realised that this only moves a /single/ stretch marker. I'm concerned that this won't work for all stretch markers across grouped items. Gianluca, it'd be great if you can test this and report on your findings. If this doesn't work for you, I'll need to try to come up with something else, but I really don't know what. I guess I'll have to track the position of the last stretch marker (not the marker itself) and then fetch the markers across all selected items, but that's pretty error prone.

— Reply to this email directly or view it on GitHub https://github.com/nvaccess/osara/issues/19#issuecomment-158299207.

GianlucaApollaro commented 8 years ago

Hi, it is exactly like you said. it works only on one item and not on the whole group. Another thing. Could it be possible to add some actions to select more than one stretch marker and move them all at once? Thanks a lot for your job

Il 20/11/2015 07:57, James Teh ha scritto:

You can now manually move stretch markers by moving to the desired stretch marker, moving to the desired new position and then running the "OSARA: Move last focused stretch marker to current edit cursor position" action. The time selection isn't needed; it's just based on the move to stretch marker actions. This doesn't take care of snapping, but I think it can be used more generally; you should be able to chain it as required.

After coming back to this issue to look at the comments, I just realised that this only moves a /single/ stretch marker. I'm concerned that this won't work for all stretch markers across grouped items. Gianluca, it'd be great if you can test this and report on your findings. If this doesn't work for you, I'll need to try to come up with something else, but I really don't know what. I guess I'll have to track the position of the last stretch marker (not the marker itself) and then fetch the markers across all selected items, but that's pretty error prone.

— Reply to this email directly or view it on GitHub https://github.com/nvaccess/osara/issues/19#issuecomment-158299207.

jcsteh commented 8 years ago

That's unfortunate. The real problem is that if multiple items are selected, it doesn't necessarily mean the stretch markers are in the same positions. It also means the way OSARA currently reports stretch markers is going to be weird in this case, since stretch marker numbers only have meaning for a single item.

I guess I should just remove the marker number altogether. The problem then is that you don't know whether you're on an actual stretch marker or not, since those commands also take you to the start and end of items, which are virtual stretch markers i guess.

I don't really know how selecting more than one stretch marker and moving them would be useful unless you are talking about the grouped items case (but I assume you're not, since you mention it separately). You could only move them all to the same position, not different positions. Can a sighted user even do this for non-grouped items/markers?

GianlucaApollaro commented 8 years ago

Yay! It works flawlessly! Thanks a lot Il 20/11/2015 13:07, James Teh ha scritto:

That's unfortunate. The real problem is that if multiple items are selected, it doesn't necessarily mean the stretch markers are in the same positions. It also means the way OSARA currently reports stretch markers is going to be weird in this case, since stretch marker numbers only have meaning for a single item.

I guess I should just remove the marker number altogether. The problem then is that you don't know whether you're on an actual stretch marker or not, since those commands also take you to the start and end of items, which are virtual stretch markers i guess.

I don't really know how selecting more than one stretch marker and moving them would be useful unless you are talking about the grouped items case (but I assume you're not, since you mention it separately). You could only move them all to the same position, not different positions. Can a sighted user even do this for non-grouped items/markers?

— Reply to this email directly or view it on GitHub https://github.com/nvaccess/osara/issues/19#issuecomment-158377921.

jcsteh commented 8 years ago

So are you still requesting some further ability regarding selecting multiple markers or does this cover it? If you do want something more, please provide an example scenario.

jcsteh commented 8 years ago

I'm wondering whether I should make this work using the cut and paste actions. First, it avoids the need for a separate action just to move stretch markers. Second, when I was playing with this, I was wondering whether it's useful to be able to move to other nearby stretch markers first before you move the desired one, using the others as a reference. Does this make sense to anyone but me? The disadvantage is that there'd be one extra action (cut) required.

GianlucaApollaro commented 8 years ago

Hi, I like it the way it is right now. The way I do is. Navigate to desired stretch marker, move the cursor by grid to where I want the stretch marker to go and snap it with your action. That is amazing, I don't like the idea of cutting and pasting very much actually Let's see what others think Il 21/11/2015 03:36, James Teh ha scritto:

I'm wondering whether I should make this work using the cut and paste actions. First, it avoids the need for a separate action just to move stretch markers. Second, when I was playing with this, I was wondering whether it's useful to be able to move to other nearby stretch markers first before you move the desired one, using the others as a reference. Does this make sense to anyone but me? The disadvantage is that there'd be one extra action (cut) required.

— Reply to this email directly or view it on GitHub https://github.com/nvaccess/osara/issues/19#issuecomment-158578308.

jcsteh commented 8 years ago

Okay. If this works for you, I'll close this for now.