v7.07+dev1218 - December 18 2023

[AZpercussion]

Originally Posted by sockmonkey72

Because selection is used for other stuff (like record-arm), it's useful to have those decoupled.

Okay, so we should have ability to change focused status explicitly.

For now if you have one track auto rec armed and want to paste items on another track you have to toggle mute that track by mouse, or change envelope selection.
It's obviously a workaround and pain for those who don't want to change focus while manipulating tcp buttons and knobs.

[UknownSource]

Originally Posted by sockmonkey72

v7.07+dev1218 - December 18 2023

• * Includes feature branch: notify user if default menu changed after a menu was customized
• * Includes feature branch: media item edits in comping lane optionally affect media item edges in source lane
• * Includes feature branch: extended ASCII encoding for .wav file text metadata
• * Includes feature branch: preserve metadata when rendering media items
• * Includes feature branch: envelope list window improvements
• * Includes feature branch: video processors in containers
• * Includes feature branch: media items on higher numbered lanes optionally mask playback of lower lanes
• * Includes feature branch: large number of video items CPU use optimizations
• * Includes feature branch: record armed tracks obeying 'do not run muted tracks' preference
• * Includes feature branch: increase fixed lane limit to 256 lanes
• + Automation: add preference for automation rate when interpolating between points for FX that support sample-accurate automation
• + Automation: improve quality of sharp edits on volume/pan/width envelopes
• + Automation: improve quality of square envelope points for volume/pan/width envelopes
• + Lanes: actions to move items up/down by lane respect project auto-crossfade setting [p=2743624]
• + Lanes: improve MIDI editor behavior with certain combinations of preferences on fixed lane tracks [t=286332]
• + Mouse maps: fix click-type display order when names are localized
• + ReaScript: add GetSetMediaItemInfo("C_ALLLANESPLAY")
• + Tempo envelope: when inserting empty space, ensure tempo remains the same at the start of the moved content [t=286359]

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

wow so much amazing updates this year!!!
Thank you for listening
got to check those automation updates!

[EvilDragon]

Originally Posted by Loulou92

It's worth supporting ! For the hardware crowd !

Last time I checked Ctrlr is open source, and anyone could give it a shot and update how it handles automation and do it properly.

That's the right way to go here, instead of expecting the host to "fix it".

[sockmonkey72]

Originally Posted by AZpercussion

Okay, so we should have ability to change focused status explicitly.

This custom action will do it (kind of -- it also selects an item if present):



But it would be nice to have something explicitly made for this, rather than with that accidental side effect.

[schwa]

I think the simplest thing is to ensure that clicks in the arrange view change the paste target track (aka the "last touched track") regardless of the track selection preferences.

[sockmonkey72]

Originally Posted by schwa

I think the simplest thing is to ensure that clicks in the arrange view change the paste target track (aka the "last touched track") regardless of the track selection preferences.

I have absolutely no objection to that solution, either. :-)

[mschnell]

In the end a full integration of Midi CC and parameter modulation (including DAW parameters such as track Volume) might be desirable (in fact, AFAIU, VST3 did more or less successfully try this). Currently in Reaper the Routing of those two data steams is implemented completely different, and the conversion provided at many distinct locations is not intuitive for some users (been there ). But such a vast change in user interface might provide an uproar in the community.

[Loulou92]

Originally Posted by EvilDragon

Last time I checked Ctrlr is open source, and anyone could give it a shot and update how it handles automation and do it properly.

That's the right way to go here, instead of expecting the host to "fix it".

Argh...

- Why is Reaper offering a separate process for buggy plugins then ? the bugs should be fixed by the plugin developers, Reaper shouldn't have to provide facilities to use these buggy plugins.

- Why is Reaper providing universal oversampling ? Plugins that don't provide such function should implement it themselves. Reaper does not have to provide oversampling functions...

- Why a Dry/wet in Reaper ? Let the plugins implement it.

See where I'm going ? Badly interpolated VST2 "could" be helped by the host with a special mode. FL are doing it if I understand correctly. I guess CTRLR works better in FL Studio but I won't switch to FL... Reaper is still way too awesome for other things.

[sockmonkey72]

Originally Posted by Loulou92

See where I'm going ?

ED is being realistic, there's no reason to take it to absurd extremes. If the plugin is buggy/crashy, no amount of hole-plugging on REAPER's end is going to solve the underlying problems, FL Studio or whatever -- FL's "fix" _breaks_ plugins, too.

Anyway, it looks like Ctrlr is based on JUCE 6, so without a bunch of intervention, it's going to be limited to JUCE 6's implementation of VST3 parameters, which is not sample-accurate (JUCE 7's isn't either, but they are apparently considering it for JUCE 8, according to one guy on their forum sometime last year). Which is to say that you won't get any advantage with VST3 vs VST2 at this time in REAPER, all other things being equal.

Your most practical solution at this time would be to run your project at a lower block size if you need better timing resolution for Ctrlr. 64 (~1ms @ 48000) or 128 (~2ms @ 48000) should be adequate.

Hardware MIDI is transmitted at 3125 bytes/second; it takes 3 bytes to change CCs, and many more for sysex data which you'd be sending via Ctrlr, so you can fill the data pipe, as far your hardware is concerned.

[BartR]

Automation lanes
The lists are still not collapsed by default.

[Loulou92]

CTRLR VST2 5.3.201 is not buggy or crashy, sorry, there must be a misunderstanding. It is very stable in Reaper if run in separate process. It basically never fails. It's widely adopted and considered the sweet spot in term of feature and stability. IN 2023 people still release commercial cross-platform vst editors based on CTRLR 5.3.201 engine (links in my previous posts).

If i click&drag a CTRLR parameter with the project stopped, idle, there is no truncation of resolution. the hardware reacts in a wonderful way to the mouse movements, the sweeps are very detailed. 14 bit perfection. 16384 steps. Musical.

It's Reaper's playback of CTRLR automation that doesn't sound good. As soon as I hit play it's ugly and stepped. CTRLR doesn't receive enough clues about the automation evolution. It receives 1 point every audio buffer. It's not enough. It doesn't know how to interpolate is the guess. And it happens only when Reaper playbacks automations.

Shouldn't Reaper provide a mode for such situations ?

Shouldn't a Reaper's parameter link work correctly inbetween CTRLR and Silent way DC plugin ? Because it doesn't seem to work correctly, I hear artefacts correlated with Reaper audio buffers.

And please guys, don't tell me to run projects at buffers 64 or 128 or 256 ; at this point you're just being mean. I'm trying to produce & mix electronic music, I have a gazilion frozen tracks and plugins running simultaneously plus a big default template. There is no way I can run anything at buffer 64 ; these kind of buffers are useless unless you do a two tracks folk song (mild exageration).

I've been trying to explain to you guys that the only awesome and widely used free universal hardware editor out there needs help in regard to automation in Reaper. It just needs a little push from the host to work completely and forever. Now people will have to go pay 350 euros for the ultra-buggy MidiQuest vst, and trust me this is not a solution. CTRLR is way better than MidiQuest, for it allows the user to craft his own editors for his own equipment. And CTRLR will never be updated again, sorry, it's a free abandonware ; almost a perfect one at that !

Ok good evening and merry christmas ! Long live Reaper !

[Coachz]

Originally Posted by BartR

Automation lanes
The lists are still not collapsed by default.

Did you select it to be closed by default in the FX menu on top right ?

[creal]

Originally Posted by sockmonkey72

v7.07+dev1218 - December 18 2023[*]+ Automation: improve quality of sharp edits on volume/pan/width envelopes[*]+ Automation: improve quality of square envelope points for volume/pan/width envelopes

Thanks but I still encounter the problem reported here: https://forum.cockos.com/showpost.ph...90&postcount=3

Project to test: https://we.tl/t-hl1riF1eRT

Thanks for testing

[Reflected]

Thank you so much for the automation updates! <3

[EvilDragon]

Originally Posted by Loulou92

It's Reaper's playback of CTRLR automation that doesn't sound good.

No, it's CTRLR's improper handling of automation that doesn't sound good.

It doesn't even need to be updated to JUCE 7 or whatever. It "just" needs to interpolate the parameter updates across the block, like all decent plugins in the past 15+ years do. Well, "somebody" needs to do it.

[mschnell]

Originally Posted by EvilDragon

It doesn't even need to be updated to JUCE 7 or whatever.

Does JUCE 7 support sample accurate automation ?

[EvilDragon]

No. Read sockmonkey72's post above.

[schwa]

Originally Posted by creal

Thanks but I still encounter the problem reported here

FWIW this issue is unrelated to the volume automation fixes in this pre-release, it has something to do with the auto-stretch timebase.

[creal]

Originally Posted by schwa

FWIW this issue is unrelated to the volume automation fixes in this pre-release, it has something to do with the auto-stretch timebase.

You are completely right.

Do I have to create a specific bug report or is it already located somewhere in your to-do list?

[Loulou92]

Why is FL studio implementing a dynamic buffer if it's of no use to nobody. Seemed like a possible fix to my problem. Or a fixed user defined buffer for user defined plugins.
Oh well...
Ok thanks !

[mschnell]

Originally Posted by EvilDragon

No. Read sockmonkey72's post above.

Yep I see. Getting confused with those version numbers

Maybe JUCE 8 might feature sample accurate modulation

But even if, enhancing the user software to use that is not a trivial task. (I did some experiments with JSFX.)

[BartR]

Originally Posted by Coachz

Did you select it to be closed by default in the FX menu on top right ?

As I said several times in other DEV threads it should be shrinked by default. Not bay a change by the user.
Because that window, in several occasions and for who doesn't know it exist that command, if freaking intimidating.

So: the goal was to make it less intimidating. It isn't if that option is not by default as "collapsed".

[Loulou92]

Originally Posted by mschnell

Yep I see. Getting confused with those version numbers

Maybe JUCE 8 might feature sample accurate modulation

But even if, enhancing the user software to use that is not a trivial task. (I did some experiments with JSFX.)

We don't need sample accurate modulation really, you're overcomplicating things, we need sub buffer block automation updates, times 4, times 8, times 16, times 32 and 64, for specified plugins.
Oversampling is doing something like that already.
Reaper can do it, it won't come from zombie CTRLR haha.

[EvilDragon]

But hold on, I see newer versions of CTRLR available, even 6.0.4. What's wrong with those?

[Loulou92]

Originally Posted by EvilDragon

But hold on, I see newer versions of CTRLR available, even 6.0.4. What's wrong with those?

I tried them, they crash. The overall user experience is lessen.

Many if not all the commercial vst editors made with CTRLR are made with the 5.3.201 version. Momo's editor, Monstrum media's editors... All my editor run with the 5.3.201 too. Super stable via separate process. It's weird I know.

I wonder if the stepping I hear is not linked to the separate process mode too... Anyway.

Guys it's ok, I get it, no love for the badly coded VST2. I'm investing in hardware mix processors each month that passes so hopefully I'll be able to lower my Reaper buffers at some point...
Less plugins, more hardware.
This is the way.

[mschnell]

Originally Posted by Loulou92

no love for the badly coded VST2.

in fact all VST2s and lazily coded (e.g. JUCE based) VST3 !

IMHO an option for statically defining a (1/n slash-) buffer size for a dedicated plugin (slot) in the same way as defining an individual (n* over-) sampling rate does make a lot of sense, while dynamic buffer size seems to be asking for trouble.

[Loulou92]

Originally Posted by mschnell

IMHO an option for statically defining a (1/n slash-) buffer size for a dedicated plugin (slot) in the same way as defining an individual (n* over-) sampling rate does make a lot of sense, while dynamic buffer size seems to be asking for trouble.

Absolutely. Thanks .

Well actually, if the "alternative sub-buffer" for a given plugin depends on the Reaper project audio buffer, the danger is that if/when the user changes (reduce) the buffer session (from 1024 to 512 for example) then the strain on the CPU might become too much for the plugins that use sub block automation settings, and start throttle the CPU when the project goes from 1024 to 512. The user would have to go and change the sub-buffer multiplier settings to accomodate the new project buffer... Not good

(well in the case of CTRLR, as it doesn't process audio, only MIDI, I'm not even sure it would struggle with ultra small buffers really...)

So I think the best solution would be to define an alternative fixed sub-buffer multiplier setting either globally (via preference), or per plugin (via FX browser), or per plugin instance (via FX window). Sub-buffers settings could be 32, 64, 128, 256, 512 & 1024 (the last two being very steppy already). This would ensure les jumpy performances if/when the user decides to change (reduce) the project buffer at any given time.

Let's leave it at that. Maybe one day .

Merry christmas again everybody & sorry for all the noise.

[bolgwrad]

Any chance of a separate thread for this stuff? Thx.

[Justin]

Originally Posted by bolgwrad

Any chance of a separate thread for this stuff? Thx.

agreed, it is entirely worth having a discussion about automation accuracy and ways to improve that, but this is the wrong place for it!

[Justin]

Originally Posted by creal

You are completely right.

Do I have to create a specific bug report or is it already located somewhere in your to-do list?

Should be fixed in the next build, thanks!

[EpicSounds]

Originally Posted by sockmonkey72

• * Includes feature branch: notify user if default menu changed after a menu was customized

what does this look like?

[schwa]

Originally Posted by EpicSounds

what does this look like?

If you customize a menu using +dev1218 or later, and a later REAPER update adds or removes items from the default menu, then "Default menu has changed" will appear as a menu item at the end of the customized menu.

It's not really testable unfortunately...

[juan_r]

Originally Posted by schwa

If you customize a menu using +dev1218 or later, and a later REAPER update adds or removes items from the default menu, then "Default menu has changed" will appear as a menu item at the end of the customized menu.

This is very welcome, thank you!

[tohubohu]

Originally Posted by sockmonkey72

v7.07+dev1218 - December 18 2023[*]+ Mouse maps: fix click-type display order when names are localized

if it's the alphabetical order of mouse clicks in mouse modifiers, for langpacks, it doesn't work.

[lexaproductions]

Originally Posted by sockmonkey72

[*]+ Tempo envelope: when inserting empty space, ensure tempo remains the same at the start of the moved content [t=286359]

Happy new year everybody!
I've answered in the original thread about an unexpected behavior relating to this.