>> v4: Area selection and editing changes (media item, envelope points, and MIDI)

[Shan]

Originally Posted by run, megalodon

...I've been watching this with interest, wondering if Reaper is about to make a big misstep. I can only imagine area selection in the ways that ProTools does it...

If these 6 steps are done, we'll have PT style area selection.

It will even be non-contiguous in the vertical position(like PT), just not horizontal and free anywhere in the Edit/Arrange window like the proposed FR.

I say we take it to the next step, and evolve it from there. That said, if Cockos already has plans to do it free range style, then I'm sure we'll see it at some point throughout the R4 cycle prior to R5.

Shane

[AdamWathan]

Why are we even discussing this? The preference is already there there's just a mouse modifier bug when using time+marquee in certain contexts where it doesn't get obeyed.

IMO there's a couple preferences that could just be consolidated into "link edit cursor and time selection". In Pro Tools, the area selection IS the edit cursor. The edit cursor is just a selection where the start point and end point are the same. Think text editor. I would argue that that is the behavior most users are aiming for when enabling "move edit cursor on time selection change" and "clear time selection on click in arrange that moves edit cursor" or whatever it's called. This could then just be put inthe options menu for easy toggle on and off, just like link loop points and time. The "link edit and time selection" option wouldn't have to be 100% literal, you could still call it that and allow the user to move the edit cursor without clearing the time selection if they did it in the ruler and didn't have "clear loop selection on click" enabled.

Stuff like that needs to be streamlined and more accessible to the user than being in he preferences in different sections like they are currently.

[Shan]

Originally Posted by AdamWathan

The preference is already there there's just a mouse modifier bug when using time+marquee in certain contexts where it doesn't get obeyed.

...Stuff like that needs to be streamlined and more accessible to the user than being in he preferences in different sections like they are currently.

+1! Exactly. At this point, there are two pref settings that dont work when enabled, which should for ideal behavior.

Shane

[AdamWathan]

Originally Posted by schwa

So you want the edit cursor to move when clicking on an item to begin a marquee selection? I think that would be unexpected for most users, no?

Marquee TIME selection, and it already does this if you enable the preference that is already there, not really too unusual of a setup!

[Shan]

Putting the visual part aside, these two items need to function when enabled in prefs:

• When enabled in prefs, "Clear time selection when edit cursor moves on click in arrange view" does not work when clicking in an item. This would be expected behavior to have with any area selection
  
• "Move edit cursor when pasting/inserting media" will have to function in this mode when enabled in prefs.

The above is standard area selection behavior in most DAWs, and very much needed for quick and fluid editing.

Shane

[AdamWathan]

+1 to Shan!

Also important and still not sure why they were left out, "Smart Remove" and "Smart Split" please. The SWS ones work perfectly, but there's no sense going halfway natively. It is really confusing for a user to make an edit selection, hit backspace and have the whole item get deleted instead of the selected area by default. Needs to be smart!

[Shan]

Originally Posted by Shan

Putting the visual part aside, these two items need to function when enabled in prefs:

• When enabled in prefs, "Clear time selection when edit cursor moves on click in arrange view" does not work when clicking in an item. This would be expected behavior to have with any area selection
  
• "Move edit cursor when pasting/inserting media" will have to function in this mode when enabled in prefs.

The above is standard area selection behavior in most DAWs, and very much needed for quick and fluid editing.

Shane

These are now both working in Alpha 8.

Shane

[Shan]

"Mouse click/edit in track view changes track selection" io prefs doesnt work when using Marquee select items and time.

This is needed when enabled in prefs.

Shane

[musicbynumbers]

didn't know where to post this but this behaviour would complete Ripple editing for me

Just pretend I adjusted the right edge of the item here to shorten it's length (rather than just moving it)

Also it should work the same for left edge but this should be and option in ripple edit icon.

[AdamWathan]

Agreed, ripple editing should act in response to trimming/time stretching! That would be a Reaper-only editing feature that I could rave about on various forums and make you money.

*cough*"Move item contents ignoring selection/grouping"*cough*

[musicbynumbers]

Originally Posted by AdamWathan

Agreed, ripple editing should act in response to trimming/time stretching! That would be a Reaper-only editing feature that I could rave about on various forums and make you money.

*cough*"Move item contents ignoring selection/grouping"*cough*

THIS WOULD make reaper superior for certain types of editing and things like cd mastering where not even most two track editors can do such wonders!

also..

That's a nasty cough you got there!

I think only Schwa has the right medicine for you though! lol

[jas]

While we're at it, Ripple Edit On - One Track or All Tracks is a wank!
It should only affect selected tracks. Just make All Tracks a default option in track grouping.

ps - FR: Please map all actions and extensions to Eucon protocol.

[Shan]

Another Area/Edit Selection love bump.

3 more steps for a good solid foundation.

Shane

[IXix]

Originally Posted by AdamWathan

ripple editing should act in response to trimming/time stretching!

Been wanting this for a long time

Originally Posted by jas

While we're at it, Ripple Edit On - One Track or All Tracks is a wank!
It should only affect selected tracks. Just make All Tracks a default option in track grouping.

'One Track' could be more accurately described as 'Tracks with selected items' but real 'Selected Tracks' behaviour would be better.

[Shan]

We're getting close gents. Just a few more tidbits for a solid foundation to build upon.

Shane

[airon]

Hehehehe. Thanks for the mouse-click-down cursor placement in the marquee+ts context in alpha 10.

Hehehehhee. I feel like a mad scientist who got another missing part to his Frankenstein project.</rubs hands in circular fashion over and over>

[gembez]

Right now when "Clear Time Selection On Click in Arrange View" is checked, time selection is cleared on both left (Time Selection) and Right (Marquee) clicks. Could we have the option of time selection getting cleared only on left click?

[lawrs]

Has this issue been addressed in v4alpha11?

[img]http://img833.**************/img833/5074/shiftclick.gif[/img]

Where shift + left click (after time selection end point) = expand time selection end point to clicked position

but shift + left click (before time selection start point =
moves entire time selection

AdamWathan's video explains it the best.

http://www.adamwathan.com/reaper/pttimeshiftclick.swf

This unpredictable behavior gets me all the time. Please have a look at this. I've seen other users also bringing this issue up.

Originally Posted by Gazgoldstar

Hey Lawrs,

I am having the same frustrations you are having with the inconsistent shift + time selection. I have found a workaround using custom actions but otherwise I am completely at a loss to understand the current implementation. I think it is important for Reaper to improve on its predictable behaviour if it is to successfully encourage new users who like me grew sick of Logic/Cubase's inconsistencies.

Cool,

Gaz

Originally Posted by EvilDragon

Yes, IMHO if I click to the left of time selection with a Shift+click, I would also like the left edge of the time selection to be extended, and NOT change the whole time selection instead! It is the most logical thing there is. Same goes for Shift+selecting items as Adam pointed above, this is how an awful lot of applications behave with Shift selections, so why not Reaper as well?

Optional, please! (In fact I'd even say completely replace the old behavior because it's not really good. )



Well, yours get sound as well, which is even cooler and gets to the point faster as you can comment additionally as you show the issue. LICEcap can't record audio.

Originally Posted by EvilDragon

So basically, what we need for Shift+click selections (ALL of them), are two options as I see it:

1. Shift+click always adds to selection (no matter the direction)
2. Shift+click adds to selection around a center point (standard Explorer/Finder behavior).

And make these selections CONSISTENT throughout Reaper's UI. Currently only TCP and MCP (and FX chain window - though SWS Tracklist actually works like #1, gotta notify Tim about it) seem to have #2 working correctly as I see it.


Amirite?

Originally Posted by Kundalinguist

It's anarchy! The left side doesn't know what the right is doing.

Originally Posted by planetnine

I agree with AW that there is inconsistency and I would support that, but I would also ask that any change would be optional (as was suggested by J above). Optional and accessible by modifier...

>

Again, I know that there's workarounds to changing time selection start (shift + left click n drag), click on start time selection locator and drag.. action keys, etc.. These workarounds work very well, but the issue remains.. left vs right time selection expansion is different. I would really appreciate it if there's an additional option to not change end time selection point when changing left time selection point.

[Kundalinguist]

Originally Posted by lawrs

Has this issue been addressed in v4alpha11?

...

I was trying it out in XP and it seems to work as expected. Left side grows on shift. I don't think it was the mushrooms, peyote or the airplane glue. I know what I saw.

[Mercado_Negro]

Originally Posted by Kundalinguist

I was trying it out in XP and it seems to work as expected. Left side grows on shift. I don't think it was the mushrooms, peyote or the airplane glue. I know what I saw.

That's what they said about the chupacabras.

[Kundalinguist]

Chupacabra? I think that's in the next alpha.

[lawrs]

Originally Posted by Kundalinguist

I was trying it out in XP and it seems to work as expected. Left side grows on shift. I don't think it was the mushrooms, peyote or the airplane glue. I know what I saw.

Thanks! Can you provide a screenshot of your Edit Behavior Preference? Doesn't seem to be reflecting on my side. Or do I need to set something in Mouse Modifier Preference?

[silent]

1+ for true area selection and all related features.

[airon]

This stuff is getting a little complicated. It seems more time is required for the Cockos boys to put their plans in to action or figure this out.

The visual display of area-style selection is nowhere near as conclusive as the requested visual style, and there are problems upon problems as the current system is being molded in to performing area selection duties as well.

One problem that I have not been able to resolve yet, is that the marquee AND the marquee+ts change the edit cursor position when I invoke them with the right-mouse button.

I can understand this for the marquee+ts, but not for just the marquee.

I presume this happens because of the click-down placement of the edit cursor, but this behaviour was requested to only occur for marquee+ts, not the marquee by itself.

The upshot is that when I access the context menu of an item, the item selection is cancelled because the edit cursor moves along with it. This means that I can no longer perform context-operations on multiple items.

Oh dear, this is quite a mess indeed.

[Kundalinguist]

Originally Posted by lawrs

Thanks! Can you provide a screenshot of your Edit Behavior Preference? Doesn't seem to be reflecting on my side. Or do I need to set something in Mouse Modifier Preference?

I believe it's a mouse modifier thing. But it could be default too. Not sure. I'm not on my PC at the moment.

[AdamWathan]

Originally Posted by airon

This stuff is getting a little complicated. It seems more time is required for the Cockos boys to put their plans in to action or figure this out.

The visual display of area-style selection is nowhere near as conclusive as the requested visual style, and there are problems upon problems as the current system is being molded in to performing area selection duties as well.

One problem that I have not been able to resolve yet, is that the marquee AND the marquee+ts change the edit cursor position when I invoke them with the right-mouse button.

I can understand this for the marquee+ts, but not for just the marquee.

I presume this happens because of the click-down placement of the edit cursor, but this behaviour was requested to only occur for marquee+ts, not the marquee by itself.

The upshot is that when I access the context menu of an item, the item selection is cancelled because the edit cursor moves along with it. This means that I can no longer perform context-operations on multiple items.

Oh dear, this is quite a mess indeed.

airon, the edit cursor moving when starting a marquee is a new thing in alpha10. I don't agree with it either, but it is actually a preference that can be disabled without affecting anything else:



Oddly enough the preference is broken if you use something like alt+click for "Marquee select items". It never moves the edit cursor in that case, even if the preference is enabled.

Honestly this preference doesn't even need to exist in my opinion, it can be safely removed. I feel like the only reason it was added was because of a misunderstanding earlier in this thread:

http://forum.cockos.com/showpost.php...2&postcount=71

and

http://forum.cockos.com/showpost.php...3&postcount=72

I think it was mistakenly interpreted as being about the marquee selection when it was ONLY about the marquee time selection, and with the marquee time selection the edit cursor movement is handled by the pre-existing preference "Move edit cursor to start of time selection on time selection change".

Still pushing for just "Link edit cursor and time selection" personally, makes more sense and is easier for your average user to understand and know how to use.

[schwa]

Originally Posted by AdamWathan

airon, the edit cursor moving when starting a marquee is a new thing in alpha10. ... Honestly this preference doesn't even need to exist in my opinion, it can be safely removed. I feel like the only reason it was added was because of a misunderstanding earlier in this thread:

If this is a correct interpretation, we would be glad to remove this preference. The new preference does only apply when starting a marquee selection *without* starting a time selection.

Note, it is clearly not correct for the cursor to ever move on right-mouse-down, because this action could end with a context menu being opened. Therefore, the cursor cannot move at the start of a right-click marquee action, or at the start of a right-click marquee+time selection action.

[AdamWathan]

Originally Posted by schwa

If this is a correct interpretation, we would be glad to remove this preference. The new preference does only apply when starting a marquee selection *without* starting a time selection.

Cool, yeah I think it's safe to ditch it personally if the only motivation for it was the brief discussion in this thread

Note, it is clearly not correct for the cursor to ever move on right-mouse-down, because this action could end with a context menu being opened. Therefore, the cursor cannot move at the start of a right-click marquee action, or at the start of a right-click marquee+time selection action.

Yeah agreed, it shouldn't ever place the edit cursor until you start dragging and it has become clear that you are not just performing a simple right click. Currently this isn't the case in alpha11 though...

http://www.adamwathan.com/reaper/r4r...ursorplace.swf

It works properly in v3 though (that is, it places the edit cursor when right click marquee+TS if the preference is enabled but only once you start dragging, not instantly on mouse down)

[yerbouti]

" If the drag begins within the time selection, only the selected area of the item is moved or copied. If the drag begins outside the time selection, the entire item is moved or copied. These behaviors can be changed using the mouse modifier preferences."

Sorry to jump in but how do I disable this function? I want the time selection to be ignore, as it was before.

[AdamWathan]

Here you go buddy!

http://forum.cockos.com/showthread.php?t=69773

[yerbouti]

Originally Posted by AdamWathan

Here you go buddy!

http://forum.cockos.com/showthread.php?t=69773

Thanks!

I had to set it on "ignore time selection" on all three: default/ctrl/shift to get it back the way it use to be.

I think this should be set by default. It is a more usual editing behaviour in my opinion.

Maybe an option to enable/disable the whole "time selection editing mode"?
It could be put in the prefs/editing behaviour menu.

[schwa]

Originally Posted by yerbouti

I had to set it on "ignore time selection" on all three: default/ctrl/shift to get it back the way it use to be.

It has been mentioned before, but this sentence is not correct. In v3, control+drag copy respects the time selection, but regular item moving does not respect the time selection.

It's not yet decided whether the default mappings for moving and copying should respect time selection, or not (or if copying should respect time selection but moving not respect time selection, as in v3).

Or maybe there should be a one-time popup dialog asking the user which default they want to set, or something.

[Bevosss]

Originally Posted by schwa

If this is a correct interpretation, we would be glad to remove this preference.

+1, I can't see the value in it personally...and definitely not on by default if it remains. I trust you saw this bug report yesterday:

http://forum.cockos.com/showpost.php...&postcount=412

** Maybe we should start calling Time + Marquee - Area Selection instead to differentiate it from straight marquee, since so many people mix those terms up and confuse the issue (not just here either, on this and other forums ever since Reaper has been around). There's been some confusing exchanges in this very thread, so I can see how mistakes are made.

[airon]

Make that half an area selection. It is not finished, and it is not capable enough to be called that, yet.

Thanks for the tip on the option. On we go.

[airon]

After disabling that option, I've now lost the click-down placement of the edit cursor in the marquee+ts context, that I had placed in the upper half of the media item context.

Curiously, I can no longer get track selections to change when clicking in to a track with the marquee+ts context either, which I have enabled across empty track space as well.

Only using the move item context(standard item behaviour) seems to cause track selection changes as well, if the accompanying preference setting is active of course.

Has anyone found a way to use the Apply FX, Render as new take or Glue methods to generate a new item that uses the time and track selection as the target area ? This was one of the intentions of Area Selection as well. Being able to render not only an area with items on it, but also areas where there are only send fx present. Applying standard functions to areas.

Is a change in the visualization of the current modification of traditional selection methods a possibility ? I must stress that I had not intended for that to happen with the request. I had hoped the selection the user makes would be clearly indicated, which I believe it is not so far. Area Selection could have had its own selection context with its own rules, limitations and benefits attached to it. I do hope the complications I have seen so far won't jeopardize standard functionality this much in the future.

[AdamWathan]

Originally Posted by yerbouti

Thanks!

I had to set it on "ignore time selection" on all three: default/ctrl/shift to get it back the way it use to be.

I think this should be set by default. It is a more usual editing behaviour in my opinion.

Maybe an option to enable/disable the whole "time selection editing mode"?
It could be put in the prefs/editing behaviour menu.

I like it the way it is now TBH, assignable in the mouse modifiers section.

I liked the V3 way, maybe just because I'm used to it, not sure. Cutting a selected chunk of an item out by default seems like something that should be done very deliberately, too deliberate to be the default action if that makes sense. But it might just be a matter of getting used to it, it does make for awfully quick editing.

[AdamWathan]

Originally Posted by airon

After disabling that option, I've now lost the click-down placement of the edit cursor in the marquee+ts context, that I had placed in the upper half of the media item context.

Reported this just minutes ago in the bug thread myself!

[Bevosss]

Originally Posted by airon

Make that half an area selection. It is not finished, and it is not capable enough to be called that, yet.

Sure Airon! And you make sure you call Time+Marquee what it is, instead of confusing Schwa and wrecking our leftclick time selection.

J/K! But I believe that's where the communication broke down over marquee and edit cursor moving.

[airon]

I am curious to see where this goes, and will report any misbehaviours of course. It's still only a marquee plus time selection, both visually and functionally, despite some additions.

[Shan]

Some good improvements with aplha12b. Using "Marquee selects items and time", a single click will now also select the track(if enabled). Other than the visual, we pretty much have full area selection abilities(minus the free non-contig selections).

Shane