v6.42+dev1117 - November 17 2021

[mabian]

v6.42+dev1117 - November 17 2021

• * Includes feature branch: JSFX internals overhaul/cleanup/modernization
• * Includes feature branch: r8brain free samplerate conversion mode
• * Includes feature branch: Windows very long pathname support
• * Includes feature branch: media explorer crossfades
• * Includes feature branch: recording files wildcard support
• * Includes feature branch: video render/convert normalization
• * Includes feature branch: media item notes improvements
• * Includes feature branch: .caf media format support
• * Includes feature branch: ASWG metadata support
• * Includes feature branch: media item lanes
• + Metadata: include link to specification for various schemes on file metadata dialog
• + Metadata: internal code changes
• + Metadata: support more ASWG fields
• + Metadata: support renaming presets
• + Metadata: support sorting project metadata dialog by description, value, or key
• + Performance: avoid destroying send windows while locked when removing tracks
• + Samplerate conversion: reorder and rename various modes
• # Media item lanes: improve razor edit behavior when outside of all tracks
• # r8brain: reduce excessive lookahead

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

[sockmonkey72]

• * Includes feature branch: JSFX internals overhaul/cleanup/modernization

Are there any user-facing changes here, or is it all plumbing improvements with no functional change?

[Justin]

Originally Posted by sockmonkey72

Are there any user-facing changes here, or is it all plumbing improvements with no functional change?

All plumbing improvements (this is some of the oldest code in REAPER) but let us know if you see any changes of behavior.

[Phazma]

Originally Posted by mabian

+ Samplerate conversion: reorder and rename various modes

Great improvement (as already said)!

I see you decided to keep it as in your screenshot from yesterday, which is fine of course.
It seems clear that they are sorted based on quality. But perhaps you might want to add "fastest" to Point Sampling and describe Sinc 768pt as "slowest", so that it is also becomes clear that they not only go from worst to best but also from slowest to fastest (except r8brain)?

It came to my mind that UX wise it would also be pretty cool to have only 4 choices in the dropdown (Point Sampling, Linear Interpolation, Sinc Interpolation and r8brain free) and for Linear Interpolation and Sinc Interpolation have a stepped slider that goes from Fast to HQ and dragging it updates the mode name, in the Sinc mode for example by adding 64pt, 192pt, etc.

Might be a bit of overkill though to develop such an elaborated UX for something that most users only rarely if ever have to interact with.

Originally Posted by mabian

# r8brain: reduce excessive lookahead

Is there any way to test these lookahead tweaks? I guess they relate to phase accuracy?

[AZpercussion]

Originally Posted by mabian

* Includes feature branch: JSFX internals overhaul/cleanup/modernization

Oh! Is any plans on performance? Notably would be great to send audio via gmem successfully.
For now it's superdistorted on most systems, don't know about silicone.

[o_e]

Hi,

When importing .caf files the length is not correct (for looping):

[schwa]

Originally Posted by o_e

Hi,

When importing .caf files the length is not correct (for looping):

Can you link to that file please?

[Justin]

Originally Posted by AZpercussion

Oh! Is any plans on performance? Notably would be great to send audio via gmem successfully.
For now it's superdistorted on most systems, don't know about silicone.

You can absolutely send audio via gmem, existing performance is plenty for that.

Having said that, audio on different tracks is processed asynchronously, so it would be a lot of work to keep them synchonrized via gmem. For example, the audio on one track might be getting processed 100ms ahead of the other track. Etc. So "it's superdistorted" is likely an implementation issue.

[Justin]

Originally Posted by Phazma

Is there any way to test these lookahead tweaks? I guess they relate to phase accuracy?

Just make sure everything works. The lookahead tweaks are purely for performance/memory use and should not affect the output.

But perhaps you might want to add "fastest" to Point Sampling and describe Sinc 768pt as "slowest", so that it is also becomes clear that they not only go from worst to best but also from slowest to fastest (except r8brain)?

I don't think the performance matters much, except in the case of the very slow modes, so it's not really worth commenting on other than the very slow modes and to note that r8brain is fast despite being the highest quality.

[Phazma]

Originally Posted by Justin

Just make sure everything works. The lookahead tweaks are purely for performance/memory use and should not affect the output.

Ok I will just keep doing various tests and conversions and let you know if something unexpected or undesired happens.

Originally Posted by Justin

I don't think the performance matters much, except in the case of the very slow modes, so it's not really worth commenting on other than the very slow modes and to note that r8brain is fast despite being the highest quality.

Ok, makes sense. Thanks for considering and giving your opinion on these ideas though!

Btw, another thought that came to my mind.. do you think it is neccessary to show the full information about the chosen SRC mode (the part in brackets) in the render dialog / project settings?
In my opinion it would be sufficient to show it in the popup when chosing the mode and afterwards only display the actual mode name in Reaper’s UI. This would make it look a bit less cluttered, especially in the case of the r8brain description, which is quite lengthy and doesn’t even have space to be displayed entirely.

[Embass]

[o_e]

Originally Posted by schwa

Can you link to that file please?

Have sent a link at support@cockos.com..

[mschnell]

Originally Posted by mabian

v6.42+dev1117 - November 17 2021

• * Includes feature branch: JSFX internals overhaul/cleanup/modernization

Any Room for Feature requests ?

-Michael

[mschnell]

Originally Posted by AZpercussion

Notably would be great to send audio via gmem successfully.

This is not a question of performance, but of synchronization.
The tracks each run on a dedicated thread and at the same tick of the wallclock will work on different a sequence-numbered block. This just is how digital Audio works.
Hence pushing Audio through gmem is strictly impossible.

-Michael

[ferropop]

Originally Posted by Embass

Embass can I hire you to find the enigmatic rattle in my car?

[mschnell]

Originally Posted by Justin

Having said that, audio on different tracks is processed asynchronously, so it would be a lot of work to keep them synchonrized via gmem.

You would need to delay (PDC) both plugins by multiple blocks and have the receiver insert the gmem stream in the correct block. Really daunting.

-Michael

[Phazma]

Originally Posted by mabian

[*]+ Samplerate conversion: reorder and rename various modes

Something odd is going on in the Project Settings window with the resample mode selection.

- Open Project Settings
- Choose a Playback or Render resample mode
- Click OK
- Reopen Project Settings

-> A different mode than the actually selected one will show up

[ashcat_lt]

I understand this is OT for this thread, but while we're here...

Originally Posted by Justin

Having said that, audio on different tracks is processed asynchronously, so it would be a lot of work to keep them synchonrized via gmem.

Would the method used in the video peeker help this?

[Justin]

Originally Posted by Phazma

Something odd is going on in the Project Settings window with the resample mode selection.

- Open Project Settings
- Choose a Playback or Render resample mode
- Click OK
- Reopen Project Settings

-> A different mode than the actually selected one will show up

oops I missed a spot, fixing, thanks!

[AZpercussion]

Originally Posted by Justin

You can absolutely send audio via gmem, existing performance is plenty for that.

Having said that, audio on different tracks is processed asynchronously, so it would be a lot of work to keep them synchonrized via gmem. For example, the audio on one track might be getting processed 100ms ahead of the other track. Etc. So "it's superdistorted" is likely an implementation issue.

Ah, it's exact what I tried to get! I tried to capture sound from the track via a plugin in take fx chain on the other track.
And, honestly, sometimes it worked on PC with 2048 spl buffer and more.
Okay, so need just live with that.

[Phazma]

Originally Posted by mabian

* Includes feature branch: r8brain free samplerate conversion mode

Btw I have tried out the r8brain mode with varispeed automation, just to hear what happens.

In that particular scenario it is not even artistically usable, just doing a lot of nasty stuttering, sounding as if the CPU couldn't keep up.

But apart from that scenario it really seems to be the best choice almost always.

So I wondering.. would it be possible, if r8brain is chosen as resampling mode, whenever dynamic varispeed happens to automatically bypass it and use a different "backup" SRC mode instead?

Given how superior it is in all other situations, I think it could otherwise really be considered as new default mode (once it is extensively tried and tested of course), if it wasn't for this edge-case showstopper. I think many people who don't care about tinkering with settings and SRC modes and leave everything at default would be very unpleasantly surprised if r8brain was the default mode and they happened to do a varispeed automation. They would probably believe Reaper's playrate automation feature is buggy.

With the suggested backup SRC mode for dynamic varispeed however, Reaper wouldn't need to hold back on making the (otherwise) best mode the default mode, which would have people knowingly or unknowingly benefit from efficient great quality SRC directly out of the box by default.

[Justin]

Originally Posted by Phazma

Btw I have tried out the r8brain mode with varispeed automation, just to hear what happens.

Next build should have some improvements actually. It might even be pretty good sounding now! Stay tuned.

[Phazma]

Originally Posted by Justin

Next build should have some improvements actually. It might even be pretty good sounding now! Stay tuned.

That sounds promising, I’m curious! Can’t wait to try it out

[MonkeyBars]

Fixed media lanes feeling a LOT stabler this time around! Well done guys

[MonkeyBars]

There are 3 lanes in the top track, but when I drag the items from below, they first come in all the way down on lane 7. Where did those 3 extra lanes come from? I would expect the top dragged item to default to the next lane down (4), then if you continue dragging up they would go to 3-2-1.

[Vagelis]

Originally Posted by MonkeyBars

There are 3 lanes in the top track, but when I drag the items from below, they first come in all the way down on lane 7. Where did those 3 extra lanes come from? I would expect the top dragged item to default to the next lane down (4), then if you continue dragging up they would go to 3-2-1.

Nice catch, looks like when you hold the items above lane adder area, it creates the correct number of lanes at top track, that is 4-5-6. But when you release the mouse it adds those extra lanes.