v5.97pre1 - February 15 2019

[vitalker]

v5.97pre1 - February 15 2019

• + ReaComp: deprecated non-fully-functional AA support, hidden when not used
• + ReaComp: improve ratio/attack/rms slider curves and display precision

Changelog - Pre-Releases

Generated by X-Raym's REAPER ChangeLog to BBCode

[EvilDragon]

Mr. Worrall needs to do more "dirt" videos on Reaper, apparently.


(But really, it'd be nice to have some actually functional AA in ReaComp! )



(Maybe also update ReaPlugs, while at it? )

[Justin]

Maybe someday, for now probably best not to encourage people to use the modes which make things louder

[Mercado_Negro]

Originally Posted by Justin

Maybe someday, for now probably best not to encourage people to use the modes which make things louder

Louder is better

[emwhy]

I always wanted to tell people Reaper goes to 11.

Awhile back it was stated that ARA would be in 5.97....still on pace?

[EvilDragon]

Well, ARA is still in this pre, so that seems legit.

[Edgemeal]

What the heck is 'OSF(!):' ?

[EvilDragon]

OverSampling Filter? (Used to be AA, for Anti-aliasing, but it didn't do any antialiasing really.)

[EpicSounds]

Originally Posted by Justin

Maybe someday, for now probably best not to encourage people to use the modes which make things louder

any thoughts on changing the position of the gain stage for the Wet/dry sliders to work better with feedback mode?

[EvilDragon]

That'd be a very nice checkbox, I agree. It should just tap the level before wet/dry and have a separate gain control in case of feedback detector. Right?

[lolilol1975]

Originally Posted by Justin

Maybe someday, for now probably best not to encourage people to use the modes which make things louder

Wait isn't that the whole point of a compressor ?

[IIRs]

Seems I put the cat among the pigeons

Originally Posted by EvilDragon

That'd be a very nice checkbox, I agree. It should just tap the level before wet/dry and have a separate gain control in case of feedback detector. Right?

I would suggest leaving the current setup as is for compatibility, but adding a proper "feedback" tick box that taps the signal before the output mix sliders, and also doubles the gain reduction so the ratio shows the correct value. This also leaves the aux inputs available for sidechain EQ etc.

[_Stevie_]

OMG it's Mr Worrall himself! I really enjoy your videos and learned a lot, thank you!

[EvilDragon]

Originally Posted by IIRs

I would suggest leaving the current setup as is for compatibility, but adding a proper "feedback" tick box that taps the signal before the output mix sliders, and also doubles the gain reduction so the ratio shows the correct value. This also leaves the aux inputs available for sidechain EQ etc.

That also sounds good and is probably a better solution.


Thanks for your very interesting videos, and please keep them coming!

[Justin]

It would be pretty straightforward to add another combo-box selection after "Output (feedback)" which would be "Output pre-fader (feedback)".

The GR issue is more complex -- it's not a matter of simply doubling the GR in feedback mode (from what I can tell). I'll do some experiments though.

[EvilDragon]

That sounds even better - no additional checkboxes on the GUI, just another menu selection. Could do!

[bFooz]

Originally Posted by EvilDragon

That sounds even better - no additional checkboxes on the GUI, just another menu selection. Could do!

But checkbox is faster to set. And there is a very nice place for it right next to the detector menu.

[EvilDragon]

Yeah but if you're already changing detector mode, you go to the menu anyways, so it's actually faster than first setting the detector to output, then clicking a checkbox

[bFooz]

I was thinking what Dan suggests - a proper feedback also needs an ability to have an aux input detector. So I imagine the new FB option be an altenative to FF in all modes in the existing detector menu (except maybe existing feedback, which could be renamed to just "Output"). If it would work like this, then a checkbox wold work best.

[amagalma]

Instead of having all these checkboxes (weird knee, osf, classic attack, proper feedback etc), why not having a simple setting for all? Old behavior/New behavior

[EvilDragon]

Because it's not black and white like that, since you can toggle each of those options individually, and projects depend on that behavior.

[lolilol1975]

Originally Posted by amagalma

Instead of having all these checkboxes (weird knee, osf, classic attack, proper feedback etc), why not having a simple setting for all? Old behavior/New behavior

I know I'm saying something controversial, but personally, I prefer a cleaner interface with features that work correctly than something cluttered with obscure options to preserve compatibility. Those who want to keep the old wrong behaviours can still use the older version of the plugin (or better yet: keep an older version of Reaper if needed for that matter).

Aka, I am in favor of a breaking change for plugins, since it's always possible to run the ancient versions of Reaper.
All Cockos has to do is: 1) warn that there is this breaking change 2) always provide the old versions for download (which they already do).
It's up to the users to update their old projects if they need to rework them, but how many were using AA x64 or the more obscure check boxes anyway ?

[timothys_monster]

Valid points in the discussion here on both sides. I tend to vote for ReaComp v2 to not break existing projects even in newer versions of REAPER using ReaComp v1. And the new ReaComp v2 with a less cluttered interface.

[Subz]

can you not "hide a compatibility mode" so old projects keep the old setting enabled till you change such setting?

with a warning message when you open the plugin gui (so you would know to update templates)

[EvilDragon]

Originally Posted by lolilol1975

Aka, I am in favor of a breaking change for plugins

But Cockos isn't in favor of that, and there's been plenty of evidence supporting that notion

[BenK-msx]

I think a set of rea v2 plugs sound good, prob be x2 as good just from experience and not being tied to v1 artifacts.

then maybe introduce option to hide /not install v1 versions later if thats even necessary.

Do it for v6, nice little treat for us, more work for you

[wallace]

Agreed.
Cleaner and clearer to make a break from the past perhaps with the launch of 6?

[Yanick]

Once again I will write about the melodyne. This is annoying. Why is this happening?
Details on the video. https://drive.google.com/file/d/1WHc...RwwdtD9hd/view
I can't refuse SWS slots and heda scripts (Track Templates) - these are very popular features.

[schwa]

Originally Posted by Yanick

Why is this happening?
I can't refuse SWS slots and heda scripts (Track Templates) - these are very popular features.

Can you be more specific about what action exactly is causing Melodyne to discard the analysis? Those plugins along the left side, where are they inserted exactly?

[Yanick]

Originally Posted by schwa

Can you be more specific about what action exactly is causing Melodyne to discard the analysis? Those plugins along the left side, where are they inserted exactly?

Thanks for the answer!
This is a heda script (Track Templates VIP) that adds an FX chain. The same bug occurs after adding the FX chain using SWS slots

[schwa]

I'm sorry, I need really specific instructions for how to trigger it. Which SWS action or menu item exactly should I run?

[heda]

Originally Posted by Yanick

Thanks for the answer!
This is a heda script (Track Templates VIP) that adds an FX chain. The same bug occurs after adding the FX chain using SWS slots

mmm
I think this is probably my script's fault which uses reaper.SetTrackStateChunk to insert the FX chain file into the track chunk data and there was no ARA when I did that. But if it also happens with SWS slots, then maybe there is something else not working. I'll have a look at it.

[Yanick]

Originally Posted by schwa

I'm sorry, I need really specific instructions for how to trigger it. Which SWS action or menu item exactly should I run?

Extensions - Resources. https://drive.google.com/open?id=1ll...fkHLxuUJlZAhzk
Next you need to add a slot (right mouse click). Then double click on the slot.
Next you need to assign the FX chain. In the Action list, you can launch a slot using the action
SWS/S&M: Resources - Paste FX chain to selected tracks, slot 1

[schwa]

REAPER will prevent the user from inserting or moving and ARA plugin to anywhere other than the first FX slot. If a script inserts any plugin before an ARA plugin, the analysis will be discarded and ARA will be disabled -- basically the ARA plugin won't work any more. That is probably what's happening.

If the script is using the REAPER API to insert or move FX, that's something we can control on our side, but if the script is rewriting the project state, there's nothing we can do about that.

I think the best we could do on our side is prevent any script from calling SetObjectState on the track or take if there is already an ARA plugin inserted.

[Yanick]

Originally Posted by schwa

If the script is using the REAPER API to insert or move FX, that's something we can control on our side, but if the script is rewriting the project state, there's nothing we can do about that.

I already thought that the problem is not on the native side. At first it seemed to me that I noticed this bug with the usual adding of the FX chain, but now I can not repeat

[Meo-Ada Mespotine]

I would rather say, that the function should return false in that case and a string that says "ARA-Plugins must be inserted into the first slot".

That way, we could force that behavior programmatically as well, as we would know, that this is the case.

Just a quick thought, maybe there's a better solution...

[heda]

After chunk set state from a script or extension, REAPER could re check and move ARA if needed before refreshing anything else. Working with chunk data is difficult. But sometimes it is needed. I wouldn't limit that just because ARA is present.

[heda]

my script doesn't move ARA plugin position. It just adds more data after it. I guess SWS functions do the same.

I suspect that ARA plugin refreshes after reaper.SetTrackStateChunk() function because it believes it may be being inserted again as if it was new and ignores the data it has somehow. I don't know exactly the reason. But maybe we end up not being able to manipulate chunk if ARA plugin is present, which would be unfortunate.

[heda]

schwa
try this on a track with Melodyne, modify something in Melodyne, and run the script. Without any chunk processing, just to test it shouldn't modify anything.

local track = reaper.GetSelectedTrack(0,0)
local retval, trackchunk = reaper.GetTrackStateChunk(track, "", false)
setchunk=reaper.SetTrackStateChunk(track, trackchunk, false)

[nofish]

Originally Posted by heda

mmm
I think this is probably my script's fault which uses reaper.SetTrackStateChunk to insert the FX chain file into the track chunk data and there was no ARA when I did that. But if it also happens with SWS slots, then maybe there is something else not working. I'll have a look at it.

SWS does essentially the same in Resources / FX chain, Track template (manipulating track state chunk).