v7.27+dev1203 - December 3 2024

[matt_t]

v7.27+dev1203 - December 3 2024

• * Includes feature branch: wildcard support for "save project as..."
• * Includes feature branch: Optionally display recording pass, wildcards in Big Clock
• * Includes feature branch: ripple edit when editing media item edges
• * Includes feature branch: MIDI item reconfiguration on effective timebase change
• * Includes feature branch: phase alignment dialog
• * Includes feature branch: per-lane ripple editing
• * Includes feature branch: auto-filter CC for MPE
• * Includes feature branch: graphical crossfade editor
• * Includes feature branch: MIDI editor CC point scaling
• * Includes feature branch: playback support for rendered files
• * Includes feature branch: automation timing and take FX fixes
• * Includes feature branch: take FX tail-length utilization
• * Includes feature branch: implode/explode support in batch converter
• * Includes feature branch: trim leading/trailing silence in batch converter
• * Includes feature branch: batch converter UI changes
• * Includes feature branch: trim leading/trailing silence when rendering
• * Includes feature branch: auto-bypass plug-ins with PDC when record armed
• # Big clock: fix occasional blank screen display
• # Phase aligner: add button to calculate best phase alignment without applying

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

[Etc.etera]

Thank you so much for doing the Ripple All - Automation fix. It works like a charm now. Absolutely stoked to use this!

The Ripple Edge edit is also really cool the way it is in this build, I love it, thank you. I have noticed however a strange case where if a second selected item gets to a duration of 0, it loses it's relative position to other selected items edges, and it can do some odd things such as introduce unexpected crossfades (see below). Is there a way of these other selected items maintaining relative edge position?

If not, I understand. I think this is the same way Reaper behaves when normal trimming selected item edges anyway.

[Etc.etera]

Originally Posted by matt_t

v7.27+dev1203 - December 3 2024
[*] * Includes feature branch: Optionally display recording pass, wildcards in Big Clock

Is it possible to add $length to the list of wildcards available?

A lot of the time I work in project where I have to meet a standard duration for broadcast. It would be amazing to see the project length while staying zoomed in doing edits.

[Thonex]

THANK YOU AWESOME DEVS!!!

... for fixing the lost-zoom issue when using the crossfade dialog navigation buttons!!!

A big THANK YOU!



Cheers,

Andrew K

[Thonex]

Devs: A question about how you are achieving your phase align numbers.

I hope you don't mind me asking (and I understand if you don't want to share)... but I do use Auto Align v1 by Sound Radix a lot for orchestral micing (many mics). In the new Reaper Auto Phase Align, do you analyze the whole file for a "best fit" phase-wise, or do you try to find a single zero-crossing within a window and align with the one reading? The reason I ask is if you record (say) a xylophone with an A-B pair of mics, the upper register of notes will reach one mic before the other and vice versa. So each tone bar will have its own phasing as you go up the scale:



There is no wrong answer per se; I'd just like to know for my own work case-uses.

Thanks in advance.

Cheers,

Andrew K

[mlprod]

Tried the new Big Clock, how come the actual clock is much smaller when having no wildcards? I like the BIG clock as is. Ideas?

[mschnell]

Originally Posted by Thonex

if you record (say) a xylophone with an A-B pair of mics, the upper register of notes will reach one mic before the other and vice versa. So each tone bar will have its own phasing as you go up the scale:

That obviously is correct.
Do you think there is a way to compensate that or is it just a bad idea to use two mics ?
Do you intend to dynamically move the phase to an optimum according to the set of sounding bars ? (I suppose that could result in nasty vibrato-like side-effects.)
OTOH, those phase differences would create a stereo feeling that might be natural and wanted.

[jessesbakery]

Ripple edge is welcome. Thank you!

I've noted that item ripple with lanes is sluggish and can cause Reaper to hang on large projects (>10k media items across ~24 tracks x 20 lanes). It's a classical music project. Ripple edit per-track is slow and all tracks is very slow.

Interestingly, when the source items are placed into folders instead of lanes (same number of media items across 24 parents x 20 child tracks), item ripple is zippy.

Please correct me if this is the wrong place for this, or if I can share more info.

Cheers, and thanks,
Jesse

[deeb]

Originally Posted by Etc.etera

Thank you so much for doing the Ripple All - Automation fix. It works like a charm now. Absolutely stoked to use this!

I am curious to see how it goes. no time now but will do it later. Thank you for your insights, it would be very probably unnoticed by me.

[schwa]

Originally Posted by Thonex

do you analyze the whole file for a "best fit" phase-wise

The phase aligner looks for the best overall fit within the time region that the alignable media item overlaps with the reference item(s). The only adjustment is the media start time, so that's pretty much all it can do. Adjusting different parts of the media item differently would require adding splits or stretch markers.

[Klangfarben]

Originally Posted by matt_t

[*] * Includes feature branch: MIDI item reconfiguration on effective timebase change

Hey devs, so did we just give up on this or what? Not only have we not really had anything to test since the first couple pres, but this is actually in a WORSE state than it was before. Several of us have spent considerable time laying out exactly what we need and patiently waiting but this just looks like you only had the intention of auto setting "ignore project tempo" and pretty much nothing else.

So what makes it worse you say? Two things. First, the auto check ignore project tempo works inconsistently. For example, if I have a track set to timebase time and then I drag a midi item into that track, ignore project tempo is not checked for that item. You have to either set it manually or toggle the timebase of the track. That means you could have several items on a track that you think are auto set to ignore project tempo but they aren't.



Let's go a step further with that and see where this gets really inconsistent. We have toggled our timebase and the item is set to ignore project tempo. We then drag that midi item back to the original track which was set to project timebase. Except now the item RETAINS its ignore project tempo state. Wait, what?? So now you have to manually set it back again every time you drag a midi item to a new track or once again toggle the timebase.



The issue here - and the inconsistency - is that we chuck midi items around to different tracks ALL the time. So now this "auto" ignore project tempo feature is essentially useless. Because if you move any midi around, you STILL have to set it to ignore project tempo. Worse, since when you have hundreds and hundreds of midi items on the screen, how could you possibly tell visually what got moved from a different track or not? Therefore, you are now basically required to do a "safety" check to determine if the item is set to ignore project tempo or not. Definitely not so "auto" anymore, is it?

The second is related to the above. Now that ignore project tempo is auto set for midi items in tracks set to time or beats (position only), it is also not doing it on midi import. So you've added a feature where the user has the expectation that ignore project tempo will be set for items in tracks set to timebase time or beats (position only) and after importing, it's turned off. And the user has NO IDEA if that box is checked for an item since again there is NO visual way of telling. Keep in mind, once the midi is imported, there is nothing that later tells the user "this was imported". Do you see the problem?

So the user has to open the properties for every single item to verify what the checkbox is set to. You've actually made the new feature worse because there's going to be a bunch of items not set to ignore project tempo that the user expects to be auto checked. Unless after every import, the user re-checks that box for every item imported. Which makes it just as it was before except worse because the expectation is the box will be checked. How could a new user possibly navigate this? There HAS to be some kind of prompt on import so the user 1) can specifically set it how they wish and 2) know what the bleeping bleep it is set to post import. Or a pref for import. Same as when moving midi items to another track. Because that is just a basic part of the workflow. It is done constantly on every single project.

Honestly, this is a giant mess. Auto, unless you move a midi item in which case it's not, unless you toggle the timebase, in which case it is, unless you then move back to the original track in which case it's not.

[schwa]

Originally Posted by jessesbakery

Ripple edge is welcome. Thank you!

I've noted that item ripple with lanes is sluggish and can cause Reaper to hang on large projects (>10k media items across ~24 tracks x 20 lanes). It's a classical music project. Ripple edit per-track is slow and all tracks is very slow.

Is the slowness a delay when you initiate the edit, or is it slow during the edit?

Also, is grouping in use in the project? If so, is it track edit grouping, item grouping, or both?

[Thonex]

Originally Posted by schwa

The phase aligner looks for the best overall fit within the time region that the alignable media item overlaps with the reference item(s). The only adjustment is the media start time, so that's pretty much all it can do. Adjusting different parts of the media item differently would require adding splits or stretch markers.

Awesome!! That's what I was hoping!!

Thanks!!

Cheers,

Andrew K

[Thonex]

Originally Posted by mschnell

That obviously is correct.
Do you think there is a way to compensate that or is it just a bad idea to use two mics ?
Do you intend to dynamically move the phase to an optimum according to the set of sounding bars ? (I suppose that could result in nasty vibrato-like side-effects.)
OTOH, those phase differences would create a stereo feeling that might be natural and wanted.

Yes... there are various ways to correct for this when recording. By using Mid/Side mic technique (or MS) or X/Y coincident micing... each one giving a different stereo sound. I really like the sound of MS but everyone has their preferences.

Mid/Side micing technique

X-Y Coincident Micing

[_Stevie_]

Originally Posted by Klangfarben

Hey devs, so did we just give up on this or what? ...

I wholeheartedly agree with this sentiment. Overall, I feel incredibly frustrated by the stagnation in MIDI development. Working with MIDI in REAPER often feels like navigating a ghost town—an overlooked area that receives little attention. More complex issues tend to be ignored, and it seems that the path of least resistance is frequently chosen.

Is there hope for MIDI or is it a dead end and we should move along?

[Crumbfort]

Originally Posted by _Stevie_

I wholeheartedly agree with this sentiment. Overall, I feel incredibly frustrated by the stagnation in MIDI development. Working with MIDI in REAPER often feels like navigating a ghost town—an overlooked area that receives little attention. More complex issues tend to be ignored, and it seems that the path of least resistance is frequently chosen.

Is there hope for MIDI or is it a dead end and we should move along?

Yeah, definitely agree with this. I'd love to know if there were plans to really dig into MIDI/MIDI editor/MPE/articulation mapper/etc stuffs. I absolutely love Reaper and don't want to move to Cubase, but if MIDI isn't a priority, I may have to do that.

[smandrap]

I admit I agree with Klangfarben. Devs, please, it’s so important to get this right, despite all the midi spec limitations. I know it’s not easy, but it hinders day to day work and I hate having to jump through different daws to do one thing or the other.

It might not be a low hanging fruit and probably the current internal state of MIDI in reaper doesn’t allow for it as easily, but I truly hope you take this chance to bite it once and for all to allow for future improvements in a more streamlined way.

[Thonex]

Originally Posted by _Stevie_

I wholeheartedly agree with this sentiment. Overall, I feel incredibly frustrated by the stagnation in MIDI development. Working with MIDI in REAPER often feels like navigating a ghost town—an overlooked area that receives little attention. More complex issues tend to be ignored, and it seems that the path of least resistance is frequently chosen.

Is there hope for MIDI or is it a dead end and we should move along?

Yeah, I feel the same way. I’m amazed by how dedicated the developers are when it comes to updating Reaper, but it does seem like MIDI features often get overlooked or only receive minimal attention. There definitely feels like a gap between how much focus is given to audio compared to MIDI.

Developers, is this just in our heads, or is there some truth to it?

Cheers,

Andrew K

[jessesbakery]

Originally Posted by schwa

Is the slowness a delay when you initiate the edit, or is it slow during the edit?

Also, is grouping in use in the project? If so, is it track edit grouping, item grouping, or both?

Thanks. The delay is on left-click-drag of item. Mouse moves, but item stays and Reaper hangs for a long time, but eventually becomes free again after a few minutes and the item follows the mouse to it's new position.

At the time of my first post, both item and track edit grouping were enabled.

Update:
- items grouped, track edit group on: sluggish/hang
- items ungrouped, track edit group on: sluggish/hang
- items grouped, track edit group off: fast (as expected)

I will use item groups as a work-around, now noting that track edit grouping causes slow edit ripples on large projects (>10k items over 24 tracks and 20 lanes per track).

Any more info to help?

Thanks,
Jesse

[schwa]

Originally Posted by jessesbakery

- items grouped, track edit group on: sluggish/hang
- items ungrouped, track edit group on: sluggish/hang
- items grouped, track edit group off: fast (as expected)

Thanks, that's helpful. We should be able to improve the performance in the next build.

[deeb]

this still happening. Is there a structural reason for not being able to solve this undesired behaviour? (Preserves the points after AI automation change)



maybe this happens because after creating the AI, the RE is still active?

maybe after creating automation:
1 - the razor edit should be cleared
2 - new AIs should stay selected

and maybe this would fix this?

[axel_ef]

Reaper v7.27+dev1203 in Linux LMDE6 (Debian 12)

Dragging Midi Item (with Ctrl+ALT+Mouse) to Media Explorer or Filemanager crashes Reaper.
Segmentation fault (core dumped)

Edit: was fixed in v7.28rc1

[mschnell]

Originally Posted by Thonex

Yes...

X/Y or M/S does seem to make sense !

[BenK-msx]

just had some freeze attempts make reaper 'poof' crash just as the freeze was about to be finished
- mixed project some uad plugs/instruments - mac m1.

stem render + mute originals was ok.

not much more to offer but might be related to latest build so take a peek.

[krahosk]

Originally Posted by smandrap

I admit I agree with Klangfarben. Devs, please, it’s so important to get this right, despite all the midi spec limitations. I know it’s not easy, but it hinders day to day work and I hate having to jump through different daws to do one thing or the other.

It might not be a low hanging fruit and probably the current internal state of MIDI in reaper doesn’t allow for it as easily, but I truly hope you take this chance to bite it once and for all to allow for future improvements in a more streamlined way.

Except for some occasional improvement (that I appreciate!), the MIDI Editor in terms of layout and features hasn't changed since about Reaper 4.
Reaper hasn't caught up with the growing wave of electronic music/VI instrument usage yet.

[R.Cato]

Originally Posted by krahosk

Except for some occasional improvement (that I appreciate!), the MIDI Editor in terms of layout and features hasn't changed since about Reaper 4.
Reaper hasn't caught up with the growing wave of electronic music/VI instrument usage yet.

Totally agree with that statement. In the beginning you might think it's just the midi editor itself which is lacking in features, but no, it's the entire midi side of things requiring attention and fixes. Personally I don't want the devs to add a feature, which already exists based on awesome community additions, but rather fix the vanilla stuff.

[fakemaxwell]

Originally Posted by mschnell

That obviously is correct.
Do you think there is a way to compensate that or is it just a bad idea to use two mics ?
Do you intend to dynamically move the phase to an optimum according to the set of sounding bars ? (I suppose that could result in nasty vibrato-like side-effects.)
OTOH, those phase differences would create a stereo feeling that might be natural and wanted.

This is what Auto Align Post does, the upgraded version of Auto Align. It's probably outside the scope of REAPER. Having a basic phase alignment built in is handy though.

[Kabraxis]

I don't like contributing to off topic discussions but I couldn't resist the urge to join the MIDI-programmers resentments.

To be honest I already moved onto two other DAWs a few months ago, after being a local Reaper evangelist for over 10 years. And with every click I'm thinking 'is there a way to do this in Reaper?', but with MIDI editing I hit dead ends pretty quickly.

I was checking if Mouse Modifier overrides introduced to MIDI editor yet so I landed in this very changelog thread. That was after I struggled with transposing my MIDI notes only to find out that JS also transposed keyswitch notes this morning on an old project. That's what I get for not moving to other DAWs much earlier.

It's not like Reaper is pretty stellar in almost any other context. It's just I gave up writing scores with Reaper. Looking forward the day MIDI editing get some love, so I can come back.

[amagalma]

Thank you devs for all your great work!

I checked the ripple edge editing a bit, and it seems very good! Here is one problematic case:


Essentially, the solution is that the first crossfade encountered after the edited edge must be treated separately to prevent it from breaking.

[amagalma]

Originally Posted by Etc.etera

Thank you so much for doing the Ripple All - Automation fix. It works like a charm now. Absolutely stoked to use this!

The Ripple Edge edit is also really cool the way it is in this build, I love it, thank you. I have noticed however a strange case where if a second selected item gets to a duration of 0, it loses it's relative position to other selected items edges, and it can do some odd things such as introduce unexpected crossfades (see below). Is there a way of these other selected items maintaining relative edge position?

If not, I understand. I think this is the same way Reaper behaves when normal trimming selected item edges anyway.

This issue arises because Reaper allows the edges of an item to be moved to a length of zero. See here:

I think this should not happen.

In my ripple edge editing script, I chose to prevent the user from dragging the edge if any of the items would have a length of zero. To address this, I set a minimum item length to either one grid unit or a predefined arbitrary length, in cases where the grid is not visible:

[inthevoid]

Originally Posted by _Stevie_

I wholeheartedly agree with this sentiment. Overall, I feel incredibly frustrated by the stagnation in MIDI development. Working with MIDI in REAPER often feels like navigating a ghost town—an overlooked area that receives little attention. More complex issues tend to be ignored, and it seems that the path of least resistance is frequently chosen.

Is there hope for MIDI or is it a dead end and we should move along?

Also share this sentiment fully. It would just be good to have some idea of whether there's any point hoping for improvements in the MIDI field or whether I just need to accept it's not going to happen.

[Crumbfort]

Originally Posted by inthevoid

Also share this sentiment fully. It would just be good to have some idea of whether there's any point hoping for improvements in the MIDI field or whether I just need to accept it's not going to happen.

I would love to know, as well. Obviously the devs aren't obligated to post any kind of roadmap and I'm not/will not be resentful or salty in the least no matter what happens. I'm incredibly grateful for how awesome Reaper already is and I'd be overjoyed if MIDI/the MIDI editor got some serious love, but I may have to look elsewhere for a bit.

(Sorry, I know this is off topic here in the pre-release section)

[woylie]

Originally Posted by matt_t;2827819[*

# Phase aligner: add button to calculate best phase alignment without applying

Works! Thanks!

[woylie]

PS It would also be useful if the calculated delay was shown in samples as well as ms.

[maxcomposer]

Originally Posted by matt_t

v7.27+dev1203 - December 3 2024
This thread is for pre-release features discussion. Use the Feature Requests forum for other requests.

If I may