v6.11+dev0527a - May 27 2020

[Sexan]

edit:

[_Stevie_]

Originally Posted by Sexan

this would be extremely nice!!

+2 from me!

And also this:

Originally Posted by Vagelis

Thought:

Wouldn't it be nice if we were able to move the whole selections too, instead just only parts? In the following gif i create 2 selections.Then i want to move them individually and not only the parts per track. Am i missing something?

[Mercado_Negro]

Thanks for fixing this one!

https://forum.cockos.com/showpost.ph...6&postcount=22

[Vagelis]

When i select an envelope lane together with an item lane and then i move the selection a bit fast vertically across tracks, there's some delay to the movement of the selection relative to the mouse.

[ferropop]

Originally Posted by Vagelis

When i select an envelope lane together with an item lane and then i move the selection a bit fast vertically across tracks, there's some delay to the movement of the selection relative to the mouse.

Sexan's seemed so smooth, but I suspect it's because it was simply drawing a graphical clone of the area and then committing it upon mouse release. This feels like its pre-committing the data before mouse-release, and therefore lagging -- also because of the fact that if you drag an area that contains envelope data to a track that doesn't, it's (in realtime) adding that envelope lane to the target as you hover.

Not sure what's best...

[vitalker]

Is it intentional behaviour? Adding area selection unselects all the selected items.

[vitalker]

Adding automation lines to area selection creates small peaces, which are independent until creating a new area selection, which includes also track lane. Feature or bug?

[Klangfarben]

Originally Posted by schwa

But you can't do this (move areas between different kinds of envelopes, multiple at a time):




Because if we support that, we would not be able to support this (move areas between envelopes of the same type, automatically creating envelopes as needed):




.. which is existing REAPER functionality.


It's fine to feel like you'd rather have the 3rd behavior than the 4th, but given that you can accomplish the same result using the 1st behavior, we don't feel like the benefit of enabling the 3rd behavior is worth the cost of losing the 4th behavior.

There's a couple issues here, one of which is not being talked about but should be. And that is that regardless of #3, it should still work within the SAME track. The user should be able to area select two envelopes in one track and move them to another two envelope lanes in the same track. It has nothing to do with #4 and does not affect any existing behavior to do with auto-creating lanes.

The second issue is I disagree that #3 breaks #4. Say that for whatever reason, you always want to match multiple lanes. Even if that's the case, it still does not break the existing behavior of #4. Here is why. If a user is doing #3 and wants multiple lanes from one track to be moved to different lanes in another track, the user would not assume that Reaper could possibly know which of those different lanes the user wanted to move to. How could it? Which means that the user would already have created those lanes.

That being the case, it does not break existing behavior. Let's say you are moving two filter envelopes from one to another track, filter #1 and filter #2. In the second track, you want to move to lanes filter #3 and filter #4. The user drags the AS from track 1 to track 2, Reaper then auto-creates lanes for filter #1 and filter #2 in track 2 and the user then continues moving the AS to filter lanes #3 and #4 which already exist. The end result being, the envelopes have been copied/moved to the user desired envelopes in the new track and a couple envelope lanes have been added. The user can then hide those newly created lanes that aren't used or leave them. But no existing behavior is broken. It would still auto-create lanes.

Obviously the preferred way would be to have an option for multi-lanes to not check/match similar to single lanes. But even without this, the above would still be a much preferred behavior than simply not having option #3 at all. I think most everyone who does this would be fine with a couple extra lanes being auto-created if it meant the AS ends up where it should. But it certainly in no way breaks existing behavior. User selects multiple lanes, lanes are auto-created when moving to the new track if they do not exist, user continues moving AS to the desired lanes, which they would have already created as otherwise, it would have been pointless to move the multiple lane area selection to begin with.

Also consider this. You can move a single lane from one track to a different lane in another track with AS yet it doesn't auto-create a lane if it doesn't already exist, which would be the expectation of #4 - there shouldn't be a distinction between auto-create for single lanes vs multiple lanes. Either auto-create creates a lane or it doesn't. That means that with multiple lanes you are arbitrarily doing a match/check that you aren't doing with single lanes, otherwise the functionality would not work for single lanes. Which means that an option to treat multiple lanes the same as single lanes when moving from one track to another would be equally valid.

So just to sum up, the behavior at the very least should work within multiple lanes on the SAME track. And on different tracks, it can certainly work similar to single lanes because single lanes could auto-create envelopes as well and in this scenario they do not. Which means multiple lanes could work the same way (you could also make the argument that single lanes should be auto-creating lanes if no lanes exist in the destination track). But even with that aside, the worst case scenario is Reaper auto-creates a few extra lanes that can be hidden. But no existing behavior would be broken in any of those scenarios.

[Mercado_Negro]

REAPER hangs or crashes when I try to trim the envelope on volume tracks (I haven't checked on other envelopes yet). You can see how the envelope knob gets stuck at some point (you see me dragging up several times and it doesn't move: min 0:18 to the end), doesn't move anymore and then REAPER hangs:

[Mercado_Negro]

I can make it hang with ReaPlugs as well:



It's weird... the beachball is not shown in the GIF but just to make it clear: it hangs from the very moment I try to drag the knob a third time).

[schwa]

Originally Posted by Mercado_Negro

REAPER hangs

Fixing, thanks for the report!

[Mosaic Music]

It is wonderful to see area selection finally implemented into Reaper, thank you devs! That's one of those golden features from other DAWs that I was dearly hoping would come to Reaper eventually- I had a similar workflow hacked together with time selection and some scripts, but this will be far better.

Three big questions:
1. Area selection context-aware actions: One really important addition to area selection, from my experience with it in other DAWs, is an area-selection-aware set of tools. In other words, "Split selected items at edit cursor or area selection (if area selection present)" or "Delete selected items or selected area of selected items (if area selection is present)", or even a big comprehensive split action that could be something like "Split items at edit cursor or area selection / Add automation point at edit cursor or 4 automation points at area selection (depending on selection)", or, well you get the picture- Context aware actions that take into account whether an area selection is or isn't present. That way, we can keep the same keybind for split, delete, cut, copy, etc, and have it all behave in an intuitive manner to whether an area selection is or is not present.
At the moment, I had to create my own "smart split" script to accomplish this with time selections, so it'd be certainly nice if it was natively available.

Are these sorts of actions planned in addition to the area selection mouse tools?

2. Accidental drawing of tiny area selections with snap off: Let's say you have "Media item top half Left Click" set to "Move edit cursor to mouse cursor" and "Media item top half Left Drag" set to "Draw area selection". With snap turned off, one might try to click but accidentally drag a tiny distance, creating a very small area selection rather than simply moving the edit cursor to the intended location. I've run into this issue many times, since that is currently how I have my Reaper config set, except with time selections rather than area selections. Samplitude remedies this by having a "Minimum area selection size" to prevent accidental tiny area selections while clicking. I believe it is set as a certain number of pixels. Is such a feature planned, to prevent accidentally creating tiny area selections when clicking around?

3. Mouse modifiers for the new area selection feature: Will there be 'move selected item' mouse modifiers that ignore area selection, as there currently is for ignoring time selection?

[dangguidan]

If the MIDI data selected by area overlaps with the original data after moving, the current setting is replacement. Can you change it to overlay or provide options?

[deeb]

bug: when undoing an area selection operation (duplicate or drag) including send envelopes the areas with send envelopes get unselected

[deeb]

i'd like to ask you to consider a different behaviour when dragging to different Y position or copy by drag and drop. Other DAWS (Cubase , S1) implementation looks
much more cleaner and helpful IMO then current reaper implementation.

1) when dragging to a different Y position or drag/drop copying, first make a ghost with transperant content with just the ouline border of the selected area and keep the Area selection in it's original position until we drop, so it let's us see what we are replacing while dragging and still able to see what we dragged in it's original position. And then after drop it, then yes, move the area selection to the new place.

This allows us to focus while dragging on what we will be replacing and still be able to see what we have selected in AS in it's original position.

2) in this ghost transperant area content which appears while dragging gives us a sign if the place we are dragging over will be able to hold the content or not (if droppable)

Simple is beautiful

[Sexan]

Source envelope track should never clear on move.ATM if no data is on lane move results clearing/deleting the track.



We are moving area not track. Media track is not deleted when moving empty space if there are no items on track so why should envelope?

[deeb]

Another suggestion I just realized by looking In latest sexan post.

I'd suggest area selection rows height adapt to existing tcp row height and not the opposite. Messing with TCP tracks height is very clumsy for eyes and brain.

[Sexan]

Since its in live mode that is not possible in some scenarios even I agree because its making me little dizzy, if envelope height is minimal that is not possible

[Embass]

1.unnecessarily selects automation item (few cases in 1 gif)
https://drive.google.com/file/d/1E2X...ew?usp=sharing

2.stretch automation when project has tempo changes
https://drive.google.com/file/d/1d1I...ew?usp=sharing

3.strech when area selection over multiple automation lanes
https://drive.google.com/file/d/1Yzf...ew?usp=sharing

4.could better handle this case
https://drive.google.com/file/d/1TLq...ew?usp=sharing

5.area selection drawing bug
https://drive.google.com/file/d/1lmN...ew?usp=sharing

6. Area selection doesnt work on master track envelopes

[BirdBird]

I agree with deeb here.
Since with the current implemention everything happens realtime, area selection should never remove or create envelopes.

The benefit of area selection is that what you see is what you get, and since the current implementation works realtime it should only work with what is visible and not decide that I want to create or remove envelope lanes. This is not smart behaviour that helps the user, it is frustrating behaviour that gets in the way of the user. I am not trying to create or remove lanes, I am trying to move data from one lane to another. Especially since the current implementation doesn't use ghosts and updates the area update live, modifying the number of envelope lanes at the same time makes the entire user experience wrong and frustrating on so many levels.

This shouldn't happen:


It is:
* A mess to follow visually
* Creates new data where I didn't want it
* Makes the area movement laggy as the project gets updated on the fly




So either:
Use ghosts approach and don't update areas live, then "smart" behaviour would be usable without being frustrating to use.
OR
If still going to use realtime approach do NOT create or remove envelope lanes. Work with what is visible rather than using magic edge cases, this is how the realtime approach would be predictable and not frustrating to use.

[Sexan]

Not sure why one is possible other is not (drag copy also)

[deeb]

Originally Posted by Sexan

Since its in live mode that is not possible in some scenarios even I agree because its making me little dizzy, if envelope height is minimal that is not possible

There's a minimum track height for envelopes , also if it's too minimum make the area equal , and actually if they consider my suggestion some posts before, it will make their life easier in this too, because while dragging/copying the envelopes and content is not floating around and have to be resized ,- just the ghost box is resized

[Embass]

FR:

Action: Restore last active area selection
or actions to store area selection to slot 1,2,3.. and restore area selection slot 1,2,3..


when i move automation point etc it clears area selection. so action to restore area selection would be useful..

[planetnine]

Originally Posted by Sexan

Not sure why one is possible other is not (drag copy also)

Sexan, wouldn’t it be tidier to use a modifier if moving or copying envelopes within a track or between different envelopes across tracks?

If I was moving a chunk of one or two envelopes across tracks, I would like to be sure they were landing on the same envelope types. Maybe turn that around and allow a modifier to “constrain to like envelopes” if you prefer the free-er default.


>

[Sexan]

There are different use cases mainly for sound designing and other advanced stuff (but it does not need to be). Im using Vol & Pan just because they are fast to open. It does not mean anything.

People will always copy/move pan to pan, vol to vol, "X to X" generally. But you have VST with its parameters. Multiple same plugins on same track. Do not mind envelope name, but ability to copy something somewhere "X to Y".

I need to use A51 as an example to show whats happening:
1.You have match mode which will copy X to X
2. You have Override mode which copy X - Y

Its dependant on where your mouse is:
- Parent track = MATCH MODE
- Envelope track = OVERRIDE mode



ATM you cannot paste stuff to destination of your choice only matching ones.
Since all of that share same internal logic, I just open VOL and PAN as an track example not the real use case.

Anyway I will stop with this subject, implementation approach is different and this is impossible to do in native since its in live mode.


BTW there is one bug but I cannot reproduce always, AREAS disappears here and there when moving

[deeb]

Originally Posted by BirdBird

I agree with deeb here.
Since with the current implemention everything happens realtime, area selection should never remove or create envelopes.

The benefit of area selection is that what you see is what you get, and since the current implementation works realtime it should only work with what is visible and not decide that I want to create or remove envelope lanes. This is not smart behaviour that helps the user, it is frustrating behaviour that gets in the way of the user. I am not trying to create or remove lanes, I am trying to move data from one lane to another. Especially since the current implementation doesn't use ghosts and updates the area update live, modifying the number of envelope lanes at the same time makes the entire user experience wrong and frustrating on so many levels.

This shouldn't happen:
...

It is:
* A mess to follow visually
* Creates new data where I didn't want it
* Makes the area movement laggy as the project gets updated on the fly




So either:
Use ghosts approach and don't update areas live, then "smart" behaviour would be usable without being frustrating to use.
OR
If still going to use realtime approach do NOT create or remove envelope lanes. Work with what is visible rather than using magic edge cases, this is how the realtime approach would be predictable and not frustrating to use.

specially since the benefit of creating the lanes only happens the first time some different envelope is dropped on that track (i guess Devs point of view and attraction is basically Vol and Pan). It's a "turn visible envelopes" action which the user could/should do by him self. And creating all this clumsy TCP changes and magic complexity and if then else conditionals it's not worth the tiny benefit.

[_Stevie_]

Originally Posted by Sexan

Source envelope track should never clear on move.ATM if no data is on lane move results clearing/deleting the track.



We are moving area not track. Media track is not deleted when moving empty space if there are no items on track so why should envelope?

I completely agree, this behavior is irritating and distracting. Too many moving things on the screen.

[_Stevie_]

I want to add, I'm completely with Klangfarben, Birdy, Sexan and deeb.

Originally Posted by Sexan

There are different use cases mainly for sound designing and other advanced stuff (but it does not need to be). Im using Vol & Pan just because they are fast to open. It does not mean anything.

The huge advatange of AS51 is, that it combined the valuable user feedback of 2 years in a nutshell, because people were constantly adding new use cases.

[mccrabney]

^ the adding/subtracting of envelopes being discussed above works, looks, and feels sooo much better when they're all displayed on the media lanes. i rarely get to say that

[Klangfarben]

Originally Posted by deeb

1) when dragging to a different X position or drag/drop copying, first make a ghost with transperant content with just the ouline border of the selected area and keep the Area selection in it's original position until we drop, so it let's us see what we are replacing while dragging and still able to see what we dragged in it's original position. And then after drop it, then yes, move the area selection to the new place.

This allows us to focus while dragging on what we will be replacing and still be able to see what we have selected in AS in it's original position.

2) in this ghost transperant area content which appears while dragging gives us a sign if the place we are dragging over will be able to hold the content or not (if droppable)

I 100% agree with this. This would be a much cleaner implementation and solves so many issues created by the existing "live" mode. It's almost like you are playing whack-a-mole doing all the move/copy stuff in real time trying to fix issues created by doing that - losing the AS selection, order of events issues like whether to copy before move or after, etc.

And regarding point #2 above, doing it this way makes it very clear exactly where you are dragging/moving the content which is incredibly important and unfortunately lacking in the current implementation. It's almost like "blind" area move/drag right now.

Originally Posted by BirdBird

The benefit of area selection is that what you see is what you get, and since the current implementation works realtime it should only work with what is visible and not decide that I want to create or remove envelope lanes. This is not smart behaviour that helps the user, it is frustrating behaviour that gets in the way of the user. I am not trying to create or remove lanes, I am trying to move data from one lane to another. Especially since the current implementation doesn't use ghosts and updates the area update live, modifying the number of envelope lanes at the same time makes the entire user experience wrong and frustrating on so many levels.

Also fully agree with this. While I realize that AS is being fit into an existing paradigm, at some point you have to ask yourself if you are going to continue sticking the square peg into the round hole or if you are going to try and reshape things so they fit better The above is a perfect example of this. We still have issues in large templates with lags in the GUI, so now that means those same lags are going to occur using AS dragging things around the arrange page. This sort of defeats the purpose and will make for an incredibly frustrating user experience. It also highlights the disadvantages "live" mode has versus a ghost mode where those same issues would not come into play.

[mccrabney]

agree with live vs ghost discussion, and that goes for the simple act of moving classicly selected audio items, too - these should not be playing while "in hand" being dragged under the play cursor

big change. hope it's possible. refer to my first request for this here, at the bottom of my first post on a [fixed circa sept 2019] bug that surfaced as a result of REAPER doing things "live" instead of "ghost" https://forum.cockos.com/showthread.php?t=224925

EDIT: actual FR here, the above links to the related BR.
https://forum.cockos.com/showthread.php?t=218075

[ArKaDaTa]

Originally Posted by _Stevie_

I want to add, I'm completely with Klangfarben, Birdy, Sexan and deeb.



The huge advantage of AS51 is, that it combined the valuable user feedback of 2 years in a nutshell, because people were constantly adding new use cases.

To add to that, what's really enjoyable with Reaper are all of the different options and workflows available to the user.

It's great to have a choice, and if it's possible it'd be nice to have a toggle/modifier for moving selected envelopes to similar envelopes (Volume/Pan to Volume/Pan) or to any envelopes.

Hopefully, both behavior can coexist!

[ferropop]

AS Copy/Paste behaviour vs Drag-Duplicate between different types of envelope lanes:



Doesn't work with Ctrl-C/V, works with Drag-Duplicate.

[Vagelis]

Are we going to have AS for midi editor notes and CC envelopes in the future?

I think it could replace Time Selection nicely

[Reno.thestraws]

This is a big one (trim content behind item is DISABLE)




Edit : Expect behavior (reproduce with mouse modifier -> move item and alo move time selection)

[Sexan]

Its supposed to do that Reno, you are moving whole area with empty space, it does not mix items it overrides them (nature of any AS).

But you have not visual feedback whats going to happen, since it mixes with destination.

How you make source it is how its going to look like on destination when moving/copying

[Reno.thestraws]

Originally Posted by Sexan

Its supposed to do that Reno, you are moving whole area with empty space, it does not mix items it overrides them (nature of any AS).

But you have not visual feedback whats going to happen, since it mixes with destination.

How you make source it is how its going to look like on destination when moving/copying

I edit my post, with time selection, it works as expect

[Sexan]

Originally Posted by Reno.thestraws

I edit my post, with time selection, it works as expect

Area is something different its not a bug, its designed behavior (area and time selection are different things)

[Reno.thestraws]

Originally Posted by Sexan

Area is something different its not a bug, its designed behavior (area and time selection are different things)

Yes but with options : trim content Behind item DISABLE I can't see any good reason to behave like that...

Area just have to be some kind of "multiple time selection" and work like normal time selection.

[Sexan]

Originally Posted by Reno.thestraws

Yes but with options : trim content Behind item DISABLE I can't see any good reason to behave like that...

Area just have to be some kind of "multiple time selection" and work like normal time selection.

Oh, yeah probably could work with that