v6.12+dev0619 - June 19 2020

[daxliniere]

v6.12+dev0619 - June 19 2020

• + Render: update $samplerate wildcard properly when changing render setting
• + VST3: fix default extension for vst3 preset export on Windows [t=238210]
• # Area selection: fix vertical moves across hidden tracks
• # Area selection: trim behind areas after cut/copy/paste
• # Area selection: trim behind areas after duplicate action

This thread is for pre-release features discussion. Use the Feature Requests forum for other requests.

Changelog - Pre-Releases

Generated by X-Raym's REAPER ChangeLog to BBCode

[daxliniere]

Originally Posted by daxliniere

+ Render: update $samplerate wildcard properly when changing render setting

Can we get update when ".." is used in Directory path, please?

(example: ..\!OUTPUT)

[xpander]

Originally Posted by daxliniere

# Area selection: fix vertical moves across hidden tracks

Works at least here now, thanks.

[Sexan]

Pasting under last project track is fixed now (not sluggish any more.


do not know how to reproduce but its easy just select random stuff around. It even appears on copy/paste and duplicate.

Locked items can still be splitted (split at edit cursor)

Whats with this?


Should this create new envelope if track has non (at least I expect that)?

[Vagelis]

Hi devs, I'm trying to move a selected track and envelope to another track with a non matched envelope and at the moment it's not possible, which is kind of limiting.

In a more logical scenario, i 'd expect either to create a new envelope to the destination track similar to the one of the target track, or match the number of lanes.

For example: if i want to move the second lane of the target track, it should move the envelope to the second lane of the destination track, no matter if the envelopes match. (assuming that there's no visible matching envelope to the destination track)

[Vagelis]

And another thing that would be very welcome, is to have another modifier to move the whole selections individually and not per track only.

So when i create 2 selections, as shown in the gif, i can't move them individually but only the divisions per track.

[_Stevie_]

Speaking of locked items, thanks for adding this feature (respect locked items) to area selection!
This is pure gold! And yes, I agree with Sexan, implementation for all the other areas would be amazing (cut selected area of items, splitting, etc...).

[deeb]

Originally Posted by _Stevie_

Speaking of locked items, thanks for adding this feature (respect locked items) to area selection!
This is pure gold! And yes, I agree with Sexan, implementation for all the other areas would be amazing (cut selected area of items, splitting, etc...).

I am not sure about this! Something must be thought as there are some constrains that might arise like freezed items get locked by default and also coherence or a concept of what is locked is missing .

From the manual: A locked item cannot be moved or deleted,but its properties can be modified.

but also seems not able to copy with Area Selection while possible by drag copy and Copy / Paste

why should be AS the bad boy and not allow it to copy?

[Klangfarben]

A locked item is locked. You should not be able to do anything to it. Not move it, not split it, not anything. The manual is also incorrect. Locked items can definitely be moved. Adjust the project start time - boom. Locked item is moved from its current location (timestamp) and is only in the same location relatively.

So I completely agree with AS respecting locked items. And also agree the same should apply everywhere else. If people really are concerned about not being able to modify locked items, then we should just have a checkbox for locked items and the user checks the things they want locked - position / editing (split, etc.) / mute-solo. That way those of us who want actual locked items could edit without fear of also editing locked items (or have to use a different set of commands for locked items) and those that simply want the item to be locked to the same relative location could have that.

AS obviously highlighted a need for this, or it wouldn't have been implemented, so we should just take it the rest of the way there.

[deeb]

Originally Posted by Klangfarben

A locked item is locked. You should not be able to do anything to it. Not move it, not split it, not anything. The manual is also incorrect. Locked items can definitely be moved. Adjust the project start time - boom. Locked item is moved from its current location (timestamp) and is only in the same location relatively.

So I completely agree with AS respecting locked items. And also agree the same should apply everywhere else. If people really are concerned about not being able to modify locked items, then we should just have a checkbox for locked items and the user checks the things they want locked - position / editing (split, etc.) / mute-solo. That way those of us who want actual locked items could edit without fear of also editing locked items (or have to use a different set of commands for locked items) and those that simply want the item to be locked to the same relative location could have that.

AS obviously highlighted a need for this, or it wouldn't have been implemented, so we should just take it the rest of the way there.

The term locked should be defined has it can be quite vague. For me locked could mean it can't be modified, but moved and definetly copiable.
If locked is what is in the manual then there are bugs . Also I wouldn't like a freezed item being locked by default if I am not allowed to do operations with it. So there are Manny concerns.

[Klangfarben]

Originally Posted by deeb

The term locked should be defined has it can be quite vague. For me locked could mean it can't be modified, but moved..
If locked is what is in the manual then there are bugs . Also I wouldn't like a freezed item being locked by default if I am not allowed to do operations with it. So there are Manny concerns.

Agreed. And now that AS has brought it to the forefront, I think now is a good time for people to chime in so we can sort it.

My vote is we have a default lock state in the prefs, and then for each item (maybe in item properties) we can check/uncheck options to modify an individual item's lock state - position, editing, mute/solo. So each user can select how they want lock to function by default, and then also modify an individual item if need be (for example setting dialogue/sfx items to a different lock state than others).

Right now it makes no sense if you can can do something similar to AS like duplicate a region and one respects locked items and one doesn't. The above would sort that.

EDIT: Position would also need two options: absolute (timestamp) and relative

[_Stevie_]

It's always a good thing to be able to fully lock an item, because that way you can exlude it from your editing and that particular item is safe.

[deeb]

I understand that this might be a big issue for someone that uses lock. while not clear and coherent maybe it's not a good move making baby Area Selection the only bad boy!

[Klangfarben]

Originally Posted by _Stevie_

It's always a good thing to be able to fully lock an item, because that way you can exlude it from your editing and that particular item is safe.

Also so every time you change the project start time you don't have to re-spot all your dialogue, efx and temp tracks

[deeb]

Originally Posted by _Stevie_

It's always a good thing to be able to fully lock an item, because that way you can exlude it from your editing and that particular item is safe.

But then with area selection don't select that content (excluding it). I could understand this concern with region copy but area selection let's use define the X.
Anyway I can't see the picture of your use , but for my use your benefit becomes an issue.

[Klangfarben]

Originally Posted by deeb

I understand that this might be a big issue for someone that uses lock. while not clear and coherent maybe it's not a good move making baby Area Selection the only bad boy!

If the user can set the default lock options for the way they want to work, and then be able to also modify the lock options per item (video/dialogue tracks, freeze tracks, etc.) that would be pretty clear and coherent to me. Then AS respecting locked items which I think most of us consider the correct implementation would be consistent with everything else.

[Thonex]

Please please please....

Let's have proper preferences for Locked Items with checkboxes for things like:

• Edit (although this may also be construed as size)
• Position
• Size
• Rate
• Selectable
• Delete
• Mute
• Solo

Thanks devs!!

Cheers,

Andrew K

[deeb]

Originally Posted by Klangfarben

If the user can set the default lock options for the way they want to work, and then be able to also modify the lock options per item (video/dialogue tracks, freeze tracks, etc.) that would be pretty clear and coherent to me. Then AS respecting locked items which I think most of us consider the correct implementation would be consistent with everything else.

Yes for sure and that would be ideal, specially if they could achieve it in a few hours. But I don't think so, and there are so Manny fronts .. is this really priority? I just came up because they are limiting baby AS and freezed items are locked by default. You guys are trying to do item selections with AS? If so , maybe you could request borders around the blocks of selected items, since it would be graffilly the same has AS and easier to manage big amount of data selection.
Sorry if I am saying something stupid!

Edit: yes I am .. because the envelopes is a big concern with item selection

Edit 2: maybe an action to turn visible/invisible specific names of tracks or p_ext could help here too. So when copying you would toggle invisible the tracks you dont want to touch and toggle on when you need. Per example: toggle visible on/off tracks with name static.

[Meo-Ada Mespotine]

Originally Posted by Thonex

Please please please....

Let's have proper preferences for Locked Items with checkboxes for things like:

• Edit (although this may also be construed as size)
• Position
• Size
• Rate
• Selectable
• Delete
• Mute
• Solo

Thanks devs!!

Cheers,

Andrew K

Is this related to the current dev-releases? Haven't checked all current dev-changelogs yet.

[heda]

I would prefer locked items to always be unaffected. Locked is locked.
If we want to copy locked items or something... I don't mind manually having to do something like "Save locking state of all items and unlock all" action. Then copy or split or whatever. and then a "Restore locked saved state" of items. If you copied items that were locked, the new ones should inherit the locked state also. Maybe this could be done automatically in the case of copying an Area Selection with an option for those who don't mind locked items to be copied automatically.

[pepe44]

i have to agree with heda. Locked item should not be affected.

[Klangfarben]

Originally Posted by Meo-Ada Mespotine

Is this related to the current dev-releases? Haven't checked all current dev-changelogs yet.

AS was changed to respect locked items. Several of us were discussing the desire to carry this over to other areas of Reaper so that everything can be consistent and how to best do that, rather than removing the ability for AS to respect locked items or have AS be the only thing respecting locked items.