v6.73+dev0117 - January 17 2023

[bolgwrad]

v6.73+dev0117 - January 17 2023
* Includes feature branch: mouse modifier small ID action binding fix
* Includes feature branch: fixed lane comping
* Includes feature branch: shortcut import/export improvements and multiple main keyboard sections
* Includes feature branch: improve samplerate change behavior when loading projects
* Includes feature branch: VST3 re-map of parameter IDs due to restartComponent
* Includes feature branch: AU parameter list change notification support
* Includes feature branch: MIDI editor screenset improvements
* Includes feature branch: routing matrix/track wiring input activity indicators
* Includes feature branch: preview item selection for grouped tracks
* Includes feature branch: VST3 per-channel silence reporting compatibility option
* Includes feature branch: better .RfxChain media explorer and clipboard integration
* Includes feature branch: ReaReaRea timestretch mode
* Includes feature branch: GR metering as embedded UI for third-party VSTs
* Includes feature branch: JSFX new features and EEL2 preprocessor
* Includes feature branch: render dialog statistics display improvements
* Includes feature branch: media item fixed lanes
+ Action list: add join/heal as default synonyms
+ Group manager: fix redundant refreshes
+ Media item lanes: add fixed lane button mouse modifiers to insert or delete lane
+ Media item lanes: allow creating a comp area in the comping lane
+ Media item lanes: allow creating a new comp area within the bounds of an existing comp area
+ Media item lanes: comp areas respect region editing
+ Media item lanes: display non-playing MIDI media items similar to muted items in the MIDI editor
+ ReaScript: support "C_LANEPLAYS" in GetSetMediaItemInfo(), read-only
+ macOS: improve compatibility of 'Open source file' mouse modifier dragging [p=2636376]
# Media item lanes: better handling when drag/dropping multiple files onto empty TCP area [p=2636364]
# Media item lanes: don't auto-promote new recording when recording into comping lane
# Media item lanes: don't move a comp area to a nonexistent lane due to track grouping [p=2636363]
# Media item lanes: fix creating comp areas when multiple razor edits exist [p=2636111]
# Media item lanes: fix drawing glitch during playback when razor edits and comp areas exist [p=2636115]
# Media item lanes: support healing adjacent comp areas by clicking the edge with the delete mouse modifier
# Media item lanes: undo improvements
# Media item lanes: when editing with mouse modifier to allow empty space between comp areas, or editing unsynced areas, restrict the edit to the edges of adjoining comp areas [p=2636114]
# Media item lanes: when initiating comping on a grouped track, ensure that other grouped tracks have a comping lane [p=2636225]

[Kenny Gioia]

+ Media item lanes: allow creating a new comp area within the bounds of an existing comp area

+ Media item lanes: allow creating a comp area in the comping lane

This was my idea and I assume it was a reversion of some previous conversations that I missed.

Please come at me for bringing this back and let's discuss why or why it shouldn't have.

Thanks.

[Vagelis]

Originally Posted by Kenny Gioia

This was my idea and I assume it was a reversion of some previous conversations that I missed.

Please come at me for bringing this back and let's discuss why or why it shouldn't have.

Thanks.

Yeah what is the benefit of this behavior? I liked also how clean it was previously, what i was missing a bit, was a left click modifier to create a split marker at mouse cursor, which then we could divide an area and swap fast a comp area from another lane.

Maybe it would be nice to have an option so we could switch behavior?

[FeedTheCat]

Originally Posted by Kenny Gioia

This was my idea and I assume it was a reversion of some previous conversations that I missed.

Please come at me for bringing this back and let's discuss why or why it shouldn't have.

Thanks.

I was previously against it. The only way to remove splits in that dev-version was dragging them out, which felt a lot like the classic take system...

I think it's fine now that we have easy ways to remove splits. At least it's consistent. I still would be interested to try if/how "drawing in" comp-areas would function (think of freehand draw envelope). Hard to tell with these things without trying.

Originally Posted by bolgwrad

# Media item lanes: support healing adjacent comp areas by clicking the edge with the delete mouse modifier

Made me wonder, wouldn't that also be great to have for the classic comp-system? E.g. a mouse modifier for alt+double click on media item edge? Would be very convenient to quickly remove unwanted splits after recording.



I briefly tried it, but apparently "heal splits in items" doesn't deal with empty takes at all. Anyhow, sorry for going off-topic.

P.S. Maybe I'm just confused at this point, but why is take 2 empty in the gif? Shouldn't it be take 1?

[Coachz]

Originally Posted by Kenny Gioia

This was my idea and I assume it was a reversion of some previous conversations that I missed.

Please come at me for bringing this back and let's discuss why or why it shouldn't have.

Thanks.

I thought the comp lane was just to display the composite of the other selected segments below it. What purpose does selecting in the top composite lane have?

[Kenny Gioia]

Originally Posted by Vagelis

Yeah what is the benefit of this behavior?

In the previous build(s), you could use the mouse modifier to create a new comp area. BUT only if that area was a non-chosen area. So if you were working thru your song and picked lane 1 as your choice, you couldn't drag on lane 1 to create the next area. It would only extend the previous one. Which you could already do just by grabbing and trimming the end of that area. So you'd have to draw it on lane 2, then switch it back to lane 1 to start hearing that lane. I think that's inconsistent. Using that mouse modifier should always perform the function of creating a new area. IMHO.

Originally Posted by Coachz

I thought the comp lane was just to display the composite of the other selected segments below it. What purpose does selecting in the top composite lane have?

At this point it might seem pointless but later on people are going to want to comp while only viewing one lane. So having the ability to create the area in the final comp lane would make that possible. You can create areas and use a keyboard shortcut to switch what lane you're hearing without having to see multiple lanes.

Originally Posted by FeedTheCat

I think it's fine now that we have easy ways to remove splits. At least it's consistent.

And that was my issue. The context mm is for creating new comp areas. It should do that whenever used. If you want to extend them, just use the trim tool. It's right threre.

[Vagelis]

Originally Posted by Kenny Gioia

In the previous build(s), you could use the mouse modifier to create a new comp area. BUT only if that area was a non-chosen area. So if you were working thru your song and picked lane 1 as your choice, you couldn't drag on lane 1 to create the next area. It would only extend the previous one. Which you could already do just by grabbing and trimming the end of that area. So you'd have to draw it on lane 2, then switch it back to lane 1 to start hearing that lane. I think that's inconsistent. Using that mouse modifier should always perform the function of creating a new area. IMHO.

I find both behaviors useful but didn't try them enough to decide hah, Maybe an option to have both? Also if we had another modifier to create a split marker under mouse could be useful for this.

Originally Posted by Kenny Gioia

At this point it might seem pointless but later on people are going to want to comp while only viewing one lane. So having the ability to create the area in the final comp lane would make that possible. You can create areas and use a keyboard shortcut to switch what lane you're hearing without having to see multiple lanes.

Makes perfect sense, but now I'm wondering if it would be better to create comp areas in comping lane if it's the only visible lane and not always?

If we don't try we'll never know

[Kenny Gioia]

Originally Posted by Vagelis

I find both behaviors useful but didn't try them enough to decide hah, Maybe an option to have both?

Not sure why you'd need both. Use this mm to create a new comp area. Grab the trim on the right or left side of the other areas to extend them. No?

Also if we had another modifier to create a split marker under mouse could be useful for this.

I'm not sure if these are split markers though. Not sure if you could create one but NOT create and area with a start and end.

Originally Posted by Vagelis

Makes perfect sense, but now I'm wondering if it would be better to create comp areas in comping lane if it's the only visible lane and not always?

You can use it always if you prefer.

[Vagelis]

Originally Posted by Kenny Gioia

You can create areas and use a keyboard shortcut to switch what lane you're hearing without having to see multiple lanes.

Or bring back those up/down arrows from earlier pres with razor comping, where they will be visible only in the comping lane in order to switch takes from there too instead from just the keyboard.

[Kenny Gioia]

Originally Posted by Vagelis

Or bring back those up/down arrows from earlier pres with razor comping, where they will be visible only in the comping lane in order to switch takes from there too instead from just the keyboard.

Some type of visual would be helpful (for the kids)

[Coachz]

Originally Posted by Kenny Gioia

At this point it might seem pointless but later on people are going to want to comp while only viewing one lane. So having the ability to create the area in the final comp lane would make that possible. You can create areas and use a keyboard shortcut to switch what lane you're hearing without having to see multiple lanes.

That makes total sense Kenny. But when you said come at me hard I was like all right let's get this guy. But I realized it was probably a trap and you had solid answers to back up your reasoning behind those outrageous spectacles so I decided to find the mature part of my brain and ask a reasonable question. Hahaha. Thanks again for the explanation.

[Kenny Gioia]

Originally Posted by Vagelis

You could do it like instead of creating a new area inside an existing one, to just split it in half for example. The left and right markers will be preserved, you just split to divide the area in 2 and then you can switch lanes from the splits. The more the splits the more areas will be created.

It's just another way of working I guess.

I understand the concept but I don't know the code. So I don't know if we can treat these as markers instead of areas.

Originally Posted by Coachz

That makes total sense Kenny. But when you said come at me hard I was like all right let's get this guy. But I realized it was probably a trap and you had solid answers to back up your reasoning behind those outrageous spectacles so I decided to find the mature part of my brain and ask a reasonable question. Hahaha. Thanks again for the explanation.

No. Honestly, I fell behind the discussion so when I asked schwa to change it, he mentioned that this was already discussed. So I wanted to take the abuse instead of him for reversing the decision.

[awelex]

Originally Posted by bolgwrad

v6.73+dev0117 - January 17 2023
+ macOS: improve compatibility of 'Open source file' mouse modifier dragging [p=2636376]

Can confirm that this is working swimmingly in macOS now! Thanks for adding.

[ferropop]

[ferropop]

This has been a thing forever, but especially fighting against it with Lanes.

Just want to place the track at the center of the screen!

When near the bottom, you cannot Hand Tool the track to the center of the screen.


Is there any way to "unlock" whatever is going in here? I only bring this up because of how frustrating this is going to be when trying to navigate many lanes.

[deeb]

Many of the zoom tcp and project are tedious to work. They move and behave in not friendly way (not smooth). Please keep things we are focused in place, so that we don’t get confused. This is huge workflow detail that reaper is missing hard. The tinny “random” moviments of the things that should stay exactly in the same place.

Examples (but there are more):
https://forum.cockos.com/showthread.php?p=2545296

[Embass]

[tonalstates]

Originally Posted by ferropop

Just want to place the track at the center of the screen!

+1

[sockmonkey72]

I think this is also unintuitive behavior:



Again, I am in the middle of a mouse gesture and it feels weird that "irreversible" things are happening as part of that. I would have no problem if the stickiness begins after I drop the comp item and drag it again (in that case, I have the option to press Cmd + left drag to get the non-sticky behavior). But activating stickiness (and deleting stuff) as I am in a continuous drag operation makes me feel like I have no control over what's happening. Particularly because I wouldn't expect that moving one item would push and pull the bounds of others with which I am not working.

If I think about it, I can press Cmd and drag will have no stickiness, and won't delete stuff (since it doesn't move over the edges of other comp lane items). So from that perspective, there's a workaround, but the default behavior is still pretty odd (IMO) and I question the overall approach to initiating these side effects during mouse gestures.

[Odys]

Originally Posted by ferropop

This has been a thing forever, but especially fighting against it with Lanes.

Just want to place the track at the center of the screen!

When near the bottom, you cannot Hand Tool the track to the center of the screen.


Is there any way to "unlock" whatever is going in here? I only bring this up because of how frustrating this is going to be when trying to navigate many lanes.

Always have extra empty tracks at the end of a project.

My starting project template has 40 empty tracks so I can scroll easily and have tracks that I'm working on near top or center.

[ferropop]

Originally Posted by Odys

Always have extra empty tracks at the end of a project.

My starting project template has 40 empty tracks so I can scroll easily and have tracks that I'm working on near top or center.

Yes I also have done this "fix".

[schwa]

Originally Posted by ferropop

right-drag screencap

I'm not able to reproduce that. Could you post a small project that's set up however it needs to be to reproduce?

[ferropop]

Originally Posted by schwa

I'm not able to reproduce that. Could you post a small project that's set up however it needs to be to reproduce?

You just need a screen full of tracks, and the desire to view the Bottom track near the Center of the screen. Not move the track itself, but the view upwards. It fights this, presumably there's some kind of logic that tries to minimize empty space at the bottom of the project.

Certain vertical zooms can sort of "nudge it upwards" but the moment you use the hand tool the entire screen launches itself downwards erratically.

As others have mentioned (there's a whole thread on this actually, lemme find...) the "fix" has been to pad the bottom of the project with like 20-30 tracks, so you have the freedom to Hand Tool upwards below the last actual track.

Finding this especially problematic with lanes - the view constantly jumping out of sight when moving around.

[schwa]

Originally Posted by ferropop

You just need a screen full of tracks

I was referring to this:
https://forum.cockos.com/showpost.ph...55&postcount=4

[vsgrt]

Originally Posted by awelex

Can confirm that this is working swimmingly in macOS now! Thanks for adding.

Yes, this is great great stuff.
I can drag from timeline directly into TAL Sampler in macOS now. Woohoo

[_Stevie_]

Hey devs,

there is an unexpected behavior introduced beginning with v6.73+dev0113 concerning splitting and trimming MIDI items (custom scripts using the API).

I suspect these guys here to be the culprit:
from 113

+ MIDI split: when trimming items, chase CC/pitch/etc

and from 114

# MIDI split: fix incorrect note added after split

I'm doing the following in the GIF:

1. Custom trim head script (revealing the area before, to show that it's gone)
2. Then splitting (also custom split script) at few bars later
= notes and a CC curve are appearing in the split item, although it shouldn't contain anything


Here's what happens with 113 and upwards:




And here's the expected behavior from 112:




If you need the custom scripts, let me now!

[Justin]

Originally Posted by _Stevie_

Hey devs,

there is an unexpected behavior introduced beginning with v6.73+dev0113 concerning splitting and trimming MIDI items (custom scripts using the API).

I suspect these guys here to be the culprit:
from 113

+ MIDI split: when trimming items, chase CC/pitch/etc

and from 114

# MIDI split: fix incorrect note added after split

I'm doing the following in the GIF:

1. Custom trim head script (revealing the area before, to show that it's gone)
2. Then splitting (also custom split script) at few bars later
= notes and a CC curve are appearing in the split item, although it shouldn't contain anything


Here's what happens with 113 and upwards:




And here's the expected behavior from 112:




If you need the custom scripts, let me now!

Thanks, fixing!

[AZpercussion]

+ Media item lanes: allow creating a comp area in the comping lane

Good stuff, thanks!


# Media item lanes: when editing with mouse modifier to allow empty space between comp areas, or editing unsynced areas, restrict the edit to the edges of adjoining comp areas

Can it be not restricted to the edges of adjoining comp areas?
That way we could have crossfades, that so useful with takes system.

[daxliniere]

Action list: add join/heal as default synonyms

Perhaps also unsplit, since split is the opposite action.

[sockmonkey72]

+ Media item lanes: display non-playing MIDI media items similar to muted items in the MIDI editor

I was prepared to go to the barricades about this one, but it's working exactly as I'd expect using my MIDI Editing prefs (and a few others that I tried).

[Embass]

[Vagelis]

There was a big change on this and previous pre regarding re-sync automatically an item on comp lane with a comp area, I preferred the behavior in dev016 much more.

In dev0116, when we were moving an item in comp lane and then back to the area to sync, it could sync while holding the mouse, which was very useful to know if a comp area and an item could sync.

In the last two pres this has changed and we can't see, we have to release the mouse and then the area and item will sync, which is not useful as a sync indicator. Can we have back the behavior of dev0116 please??

[musicbynumbers]

+ Media item lanes: comp areas respect region editing

If this what I think it is than thanks!

[Vagelis]

Originally Posted by musicbynumbers

+ Media item lanes: comp areas respect region editing

If this what I think it is than thanks!

It is!

[xpander]

Originally Posted by ovnis

It can be very painfull to do that each time you want to edit your MIDI item inside fixed lanes... Especially guys like me who use often fixed lanes track with lots of lanes and items.

I guess I just don't get the issue as presented earlier? I certainly got mixed responses where people got feature x working with some settings but are back at me about it not working?

You can have several MIDI items on lanes, click one of the items and open/see only that one in MIDI Editor with one editor per track mode. With that in mind, to me the issue of seeing too much in ME seems like a matter of user settings, not that it's not possible to restrict what you see/edit, correct?

But if user wants to see more than just the contents of one item/lane in ME, to differentiate between what lane/items are playing, what is currently editable in ME and what items/notes are muted, there are different colors. Wasn't this specifically asked for earlier, because some users want to see items of all lanes and be able to tell the differences between those different states?

Keep in mind, I was talking about this feature that was mentioned not working:

+ Media item lanes: display non-playing MIDI media items similar to muted items in the MIDI editor

And I was replying to this:

Originally Posted by Skorobagatko

Actually it doesn't work as expected. It displays MIDI items for more then one track, not for just a selected track (MIDI editor per track)
Muted notes should become visible only with one MIDI editor per project setting.

That is a bit different from deciding what all you want to see in ME, which goes back to making settings so that you don't see more than you need. And that selection/setting process must be done anyway, depending on what is needed.

I haven't seen any reasonable explanation yet why current feature of seeing muted notes in ME should be taken away. I for one could welcome more discussions about the new feature of non-playing item colors and possible feature requests of per-lane editor mode...even while this all brings back headaching memories of v4 MIDI chaos.

[sockmonkey72]

Originally Posted by xpander

I guess I just don't get the issue as presented earlier? I certainly got mixed responses where people got feature x working with some settings but are back at me about it not working?

You can have several MIDI items on lanes, click one of the items and open/see only that one in MIDI Editor with one editor per track mode. With that in mind, to me the issue of seeing too much in ME seems like a matter of user settings, not that it's not possible to restrict what you see/edit, correct?

But if user wants to see more than just the contents of one item/lane in ME, to differentiate between what lane/items are playing, what is currently editable in ME and what items/notes are muted, there are different colors. Wasn't this specifically asked for earlier, because some users want to see items of all lanes and be able to tell the differences between those different states?

Keep in mind, I was talking about this feature that was mentioned not working:


And I was replying to this:


That is a bit different from deciding what all you want to see in ME, which goes back to making settings so that you don't see more than you need. And that selection/setting process must be done anyway, depending on what is needed.

I haven't seen any reasonable explanation yet why current feature of seeing muted notes in ME should be taken away. I for one could welcome more discussions about the new feature of non-playing item colors and possible feature requests of per-lane editor mode...even while this all brings back headaching memories of v4 MIDI chaos.

For my part, I don't want anything taken away, I just want it to not be the default behavior, requiring me (or anyone) to have to discover/open the tracks sidebar and manually shut off lane visibility every time I use the ME.

Seeing muted notes in the same item is important and good.

What was being discussed was displaying the events in non-playing lanes as muted events when editing a playing item. Which I also don't need taken away, as long as it can also not work that way without any special intervention when opening the ME.

Which seems to be the case, so I'm happy.

[ovnis]

Originally Posted by xpander

I haven't seen any reasonable explanation yet why current feature of seeing muted notes in ME should be taken away. I for one could welcome more discussions about the new feature of non-playing item colors and possible feature requests of per-lane editor mode...even while this all brings back headaching memories of v4 MIDI chaos.

Why don't you agree with this?

Actually, I think it's not a great idea to display notes of items not clicked as muted because, in fact, when a lane is muted, it's not MIDI notes which are muted.

Plus, if we edit a MIDI item which is on a fixed lane mutes, notes of this item will be muted... It can be confusing.

Moreover, how to know which note is really muted or not?

Why not follow the type of poster there is with "One MIDI editor per project" with darker notes for exemple?

There would be more consistency with the rest.

-------------------------------

You said:

You can have several MIDI items on lanes, click one of the items and open/see only that one in MIDI Editor with one editor per track mode. With that in mind, to me the issue of seeing too much in ME seems like a matter of user settings, not that it's not possible to restrict what you see/edit, correct?

Because when you don't work with the tracks sidebar, you have to open it, click and close it. When you have to do this lots of time, it can be very boring...

Is it no more simple to add a new option like "One midi editor per track and per lane"? Like that, the display is always good for us (people who don't want "one midi editor per project" or more than one MIDI item displayed inside the MIDI editor)!

[xpander]

Originally Posted by ovnis

Why don't you agree with this?

Why I don't agree with taking away a feature that has been in Reaper for ages and been proven helpful? I don't think we are really talking about the same thing here? I was talking about seeing muted notes where there are some, like before. I gather jury is still out on the new possible feature of seeing non-playing items same as muted?

Originally Posted by ovnis

Because when you don't work with the tracks sidebar, you have to open it and click. When you have to do this lots of time, it can be very boring...

Choices, when having to do something. Of course one could also keep the selector open all the time. After that a click or even swipe(!) there is about the same effort than in arrange, but you can also stay within ME and actually get more control over what you see & edit. Personally I see that as a great benefit, not as a boring crutch. YMMV, of course.

Originally Posted by ovnis

Is it no more simple to add a new option like "One midi editor per track and per lane"? Like that, the display is always good for us (people who don't want "one midi editor per project" or more than one MIDI item displayed inside the MIDI editor)!

You can already set MIDI editor to only display one selected/clicked MIDI item and no track selector needed. That's why I currently don't see a reason for a new editor mode option, not without more data to support the request.

How well this is actually working with fixed lanes is yet another thing that I haven't tested fully yet...and my conclusions would still be just mine; there's a lot of us here, so what exact details are wrong, not working, need improvement?

---
For a baseline: