v7.0rc8 - October 6 2023

[dom64]

v7.0rc8 - October 6 2023

• * Includes feature branch: support up to 32 main toolbars, 16 MIDI toolbars
• * Includes feature branch: MIDI CC vertical zoom/scroll
• * Includes feature branch: optionally hide collapsed tracks within a folder
• * Includes feature branch: export mouse modifiers as a script
• * Includes feature branch: target individual fixed lanes when pasting media items
• * Includes feature branch: support rendering raw PCM data
• * Includes feature branch: Development_Theme theme
• * Includes feature branch: JSFX plug-in defined compile-time configuration parameters
• * Includes feature branch: video YUV gamut selection
• * Includes feature branch: visual track spacers
• * Includes feature branch: 128 channels per track
• * Includes feature branch: updated Windows manifest for newer OS features
• * Includes feature branch: always running non-bypassed FX when the UI is visible
• * Includes feature branch: crossfade new recording with existing media items if configured
• * Includes feature branch: video from background projects
• * Includes feature branch: FX containers
• * Includes feature branch: improvements to aligning takes after recording
• * Includes feature branch: arrange view override mouse modifier sections
• * Includes feature branch: toolbar armed/special animations
• * Includes feature branch: pooled and unpooled ARA edits
• * Includes feature branch: shortcut import/export improvements and multiple main keyboard sections
• * Includes feature branch: GR metering as embedded UI for third-party VSTs
• * Includes feature branch: media item fixed lanes
• + MIDI editor: add option to set the channel for new events when selecting a single note or CC event
• + Media item lanes: add checkbox in mouse modifiers dialog to limit comp area edits to media item edges
• + Razor edits: copy fade-in/fade-out if any part of the fade is included in the razor edit
• + lv2: fix support for patches defined in manifest
• # Actions: add action to toggle preference for time selection auto-punch to add the whole recording when recording into a new fixed lane
• # Actions: add actions to toggle preferences to prevent changing comp area source lane on clicking empty space, avoid including empty space in comp areas
• # Media item lanes: add action to remove all lanes from fixed lane track
• # Media item lanes: automatically name lanes when duplicating
• # Media item lanes: fix lane-collapse button behavior when lanes are very small [p=2718257]
• # Media item lanes: if moving/copying from collapsed fixed lane track with 'razor edits affect all lanes' enabled, convert the receiving track to fixed lanes if needed [p=2718356]
• # Media item lanes: remove mouse modifiers to limit comp area edits to media item edges (if you previously assigned these mouse modifiers, you will need to reset mouse modifiers)
• # TCP/MCP parameters: fix automatic multiline threshold with hidpi [p=2718099]

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

Changelog - Pre-Releases

Generated by [url=https://codepen.io/X-Raym/details/ggPogG/]X-Raym's REAPER ChangeLog to BBCode[/

[Edgemeal]

+ Razor edits: copy fade-in/fade-out if any part of the fade is included in the razor edit

Fade-in/out still disappear on comp lane when copied/moved on same track using Razor Edit, but the cross-fades seem OK.


Fades-in/out disappear on comp lane when moved to the left using Region, , but the cross-fades seem OK.


Win10_x64

[Vagelis]

Originally Posted by dom64

v7.0rc8 - October 6 2023
[*]+ Media item lanes: add checkbox in mouse modifiers dialog to limit comp area edits to media item edges

Thanks a lot! But now I can't move comps horizontally with the modifier move comp area and media item. I would prefer to limit comp area edits to items edges when dragging to create a new comp area, but not when moving it.

[thommazk]

+ MIDI editor: add option to set the channel for new events when selecting a single note or CC event

Thanks!

[Coachz]

Originally Posted by Vagelis

Thanks a lot! But now I can't move comps horizontally with the modifier move comp area and media item. I would prefer to limit comp area edits to items edges when dragging to create a new comp area, but not when moving it.

You're ahead of me, I can't even find the option in MM

[Vagelis]

Double click modifiers are not working at small track height for lane header.

[Vagelis]

Originally Posted by Coachz

You're ahead of me, I can't even find the option in MM

Check fixed lane comp area-left drag context, at the bottom of the window check avoid including empty track space in comp areas.

[Coachz]

Originally Posted by Vagelis

Check fixed lane comp area-left drag context, at the bottom of the window check avoid including empty track space in comp areas.

YAY !

[schwa]

Originally Posted by Vagelis

Check fixed lane comp area-left drag context, at the bottom of the window check avoid including empty track space in comp areas.

Soliciting opinions on whether this should be the default behavior (avoid including empty space in comp areas).

[Thonex]

Originally Posted by schwa

Soliciting opinions on whether this should be the default behavior (avoid including empty space in comp areas).

I can't test until the holidays (I am too crazy busy with projects), but my guess is that the Comping Prefs you had until recently should probably be the default. I didn't notice any odd behavior with left-edge comp areas. I would avoid making edge case solutions defaults in Comp mode... especially when users are already used to working a certain way?

Of course, I may be way off base... in which case ignore me

Cheers,

Andrew K

[Xorro]

Originally Posted by schwa

Soliciting opinions on whether this should be the default behavior (avoid including empty space in comp areas).

Yes I think it should be on by default.
Just found a few bugs, i can still comp empty space even with these two options turned on:
# Actions: add actions to toggle preferences to prevent changing comp area source lane on clicking empty space, avoid including empty space in comp areas

[Vagelis]

Originally Posted by schwa

Soliciting opinions on whether this should be the default behavior (avoid including empty space in comp areas).

Personally I find this better, so I vote for default. But hopefully with a fix to move freely comp areas and items at any position for better arrangement.

[FeedTheCat]

Originally Posted by schwa

Soliciting opinions on whether this should be the default behavior (avoid including empty space in comp areas).

Hmm, not sure if this option should be tied to "left drag", it would be nice if it can also affect left click area creation.

In this case left click adds empty track space, which then behaves a bit weird with "Avoid including empty track space":



If v7 is to be released in a week or two, I wouldn't make this the default. Lots of potential for funky edge cases imo...

[smandrap]

I vote for new behaviour as default too. Much more intuitive.

I'd also like to see some "intelligent" behaviour for left click on items while comping.

This is the current state:



And this is what i'd expect the end result would be after left clicking the item while comping:




But maybe i'm missing some modifiers/preferences to do this.

Also: zoom to item still needs to be fixed, it zooms to the topmost lane no matter what.



And please, make this action respect the new vertical zoom limits

[Coachz]

Originally Posted by FeedTheCat

Hmm, not sure if this option should be tied to "left drag", it would be nice if it can also affect left click area creation.

In this case left click adds empty track space, which then behaves a bit weird with "Avoid including empty track space":



If v7 is released to be release in a week or two, I wouldn't make this the default. Lots of potential for funky edge cases imo...

The edge cases can unclick the option.

[PhelixK]

Regarding FL big/small/one toggle button, it feels like it could have a little less margin at the bottom, and function in the same way if the track height is very low as in the example here.

It now looks like the element and target area are set to be hidden when the track height is 20px or less.

If it doesn't affect other things, it would be nice if the bottom margin was even smaller and allows the element to be displayed even at particularly small track heights. As can be seen, both the lane header and the miniature buttons are visible and interactive, all the way down to 15px height:



– edit, the above also concerns the new hidden indicator:



Btw. Together, the different view options are super-cool to have, and really well thought out!!

.

[Vagelis]

Originally Posted by smandrap

And this is what i'd expect the end result would be after left clicking the item while comping:

Agreed, this is exactly how it works in Cubase as well, which imo makes a lot of sense to comp items and not empty space.

[deeb]

dropping RE (or item selection) to fixed lane "holder" behaves different when source track have comp or no comp. The behaviour with no comping seems the desirable one for comping too.

[deeb]

moving / copying to fixed lanes holder reaper could keep the playability like the original since it won't have any conflict with existing lanes playbility on the target since new lanes are being created. Original was playing 2, 3, 4 and after the process 1, 2, 3, 4, 5 were playing.

[deeb]

schwa: is this a new feature?
edit: because if it is i would like to know where i get more information how to control this.
divided bottom docker:

[schwa]

Originally Posted by Vagelis

Double click modifiers are not working at small track height for lane header.

That's intentional, thinking that comping with tiny lanes is probably not what the user wants, but we could enable double-click for tiny lanes and see how it goes.

[deeb]

Originally Posted by schwa

Soliciting opinions on whether this should be the default behavior (avoid including empty space in comp areas).

i think to "NOT avoid including empty space in comp areas" is better as default because "comp area" implies an area, and empty space is still an area.

[deeb]

Originally Posted by schwa

That's intentional, thinking that comping with tiny lanes is probably not what the user wants, but we could enable double-click for tiny lanes and see how it goes.

it's better i think, because it is less confusing and might be handy to work in tinny view if lanes are still fully functional.

ps: between i would like to have option so that botton could be always small (or something in between - not sure if theme adjuster will allows this)

[schwa]

Originally Posted by smandrap

I'd also like to see some "intelligent" behaviour for left click on items while comping.

I would disagree on this. If you have say one lane with a drum take and another lane with a split/replaced/corrected drum take, you want to be able to comp whole phrases, and only comp individual hits if you specifically choose to make a tiny comp area. Basically we would rather leave the intelligence to the user rather than having REAPER guess at the intention.

[Vagelis]

Originally Posted by schwa

That's intentional, thinking that comping with tiny lanes is probably not what the user wants, but we could enable double-click for tiny lanes and see how it goes.

Yes I agree, though I wanted to turn comping off while small which is useful, but I couldn't.

[smandrap]

Originally Posted by schwa

I would disagree on this. If you have say one lane with a drum take and another lane with a split/replaced/corrected drum take, you want to be able to comp whole phrases, and only comp individual hits if you specifically choose to make a tiny comp area. Basically we would rather leave the intelligence to the user rather than having REAPER guess at the intention.

I understand and it totally makes sense. So at this point a mouse action like “set comp area to item” (if not existing already, can’t check rn) would leave the choice to the user to use the behaviour I described or the current one

[benmiller]

Originally Posted by schwa

Soliciting opinions on whether this should be the default behavior (avoid including empty space in comp areas).

i would say not default, but as long as you can change the setting the other way is fine.

[ferropop]

Thank you for + MIDI editor: add option to set the channel for new events when selecting a single note or CC event!

It doesn't seem to be working correctly :



Notes colored by channel, action enabled.

The first 4 are correctly switching to the appropriate channel based on note selection. When I go back however and select the Orange (Channel 2) note it is still drawing Green (Channel 4). Same with Red (Channel 1).

[schwa]

Originally Posted by ferropop

The first 4 are correctly switching to the appropriate channel based on note selection. When I go back however and select the Orange (Channel 2) note it is still drawing Green (Channel 4). Same with Red (Channel 1).

Hmm, I can't reproduce that. The channel setting happens whenever there is an undo point that results in exactly one event being selected. If you look at the undo history while selecting the notes, is an undo point created every time you change the selection? If so, is there any way some other event might be selected as well?

[gofer]

re: + MIDI editor: add option to set the channel for new events when selecting a single note or CC event

This feature breaks here as soon as CC are written or recorded and I select a single note (which shares channel with some CC events) expecting the active channel to be changed. I first thought it's not working at all, because recording MPE will obviously create CC on all the involved channels.

I can easily create the situation with these steps:
- create new MIDI item
- create two notes
- change channel of one of the notes
(at this point channel change works)
- create CC events on one of the involved channels
- click the other note - channel will change as expected
- click on the note that shares channel with the CC
-> channel will not change

Selecting a single CC event will still change the active channel as expected, selecting a note won't.

Deleting the CC will fix. Doing this receipt with three notes on three separate channels shows that notes without corresponding CC are still able to change the active channel.


The feature also has some dependency with the event filter which are unfortunate: When editing CC I most often have the filter set to a specific channel plus "Show only events that pass filter" disabled. This allows to marquee select only CC on that channel I am currently working on while still seeing events of all channels. With MPE it's a normal case to have a chord, each note with its own CC data on the same lane but different channels. When you want to make sure you edit only a section of a CC gesture of a specific note, then this setting is what you need.

Alas, the new feature stops working in this case.


EDIT:
The CC situation is depending on „CC selection follows note selection“ being enabled. Sounds logical now, knowing that the algorithm only switches channel when a single event was selected. Hopefully this can be refined.

[deeb]

in this scenario, new lanes should be created so that previous lanes playability don't get affected. no?



initially lane 2 was playing and then just lane 4 and then just lane 6.

[gofer]

Ah got it!, It's "CC selection follows Note selection" that works against us here. This is almost permanently enabled here (and probably in Ferro's case too). Obviously many events will be selected with each note selection then...

[ferropop]

Originally Posted by schwa

Hmm, I can't reproduce that. The channel setting happens whenever there is an undo point that results in exactly one event being selected. If you look at the undo history while selecting the notes, is an undo point created every time you change the selection? If so, is there any way some other event might be selected as well?

Can confirm Gofer's findings.

Selecting the CCs does correctly switch to the clicked CC's channel. Selecting the note is hit-or-miss described well by gofer.

The undos seems to be "Select events" followed by "Set CCs", nothing in between.

[Edgemeal]

Originally Posted by deeb

in this scenario, new lanes should be created so that previous lanes playability don't get affected. no?

I'd expect the last recorded item/lane to play. But gezz were already into RC8, is this really the time to start changing how things work now, its not like its broke or buggy, seems pretty awesome to me.

[schwa]

Originally Posted by gofer

The CC situation is depending on „CC selection follows note selection“ being enabled. Sounds logical now, knowing that the algorithm only switches channel when a single event was selected.

Right, that makes sense. We could change the preference to "selecting a single note sets the channel for new events".

[deeb]

Originally Posted by Edgemeal

I'd expect the last recorded item/lane to play. But gezz were already into RC8, is this really the time to start changing how things work now, its not like its broke or buggy, seems pretty awesome to me.

I don't mean the playability policy of the scenario showed on the GIF, but referring to the fact that new lanes should have been created instead, so playability is untouched. This what happens if i started recording just next to another media item.

look (this is desired):



(but i am still concerned with playability during a whole project to be honest, but maybe there is a better timing for that)

[ferropop]

Originally Posted by schwa

Right, that makes sense. We could change the preference to "selecting a single note sets the channel for new events".

I believe this is what js_option is doing! and yes this all makes sense, I also have "cc follows note selection" on always. Thanks for your attention to this, MPE editing is shaping up!

[schwa]

Originally Posted by deeb

I don't mean the playability policy of the scenario showed on the GIF, but referring to the fact that new lanes should have been created instead, so playability is untouched. This what happens if i started recording just next to another media item.

There is logic that reuses existing lanes when recording into empty space. I think the fix is to only reuse lanes when these preferences are set this way:

[deeb]

Originally Posted by schwa

There is logic that reuses existing lanes when recording into empty space. I think the fix is to only reuse lanes when these preferences are set this way:

i am not sure what you mean. this was my setting for recording:



and if you notice, the only difference from last to the other gif is that the recording happened not connected sections (apparently). Maybe i do another gif in a bit so it's clear what i mean.

[schwa]

I believe I understand what you mean. I am saying that we can change the behavior in REAPER so that lanes are only reused when the configuration is set the way I showed.