Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Pre-Release Discussion

Reply
 
Thread Tools Display Modes
Old 05-13-2022, 08:30 PM   #1
PitchSlap
Human being with feelings
 
PitchSlap's Avatar
 
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,792
Default Auto-bypass on silence/silent-track CPU reduction Discussion/Issues

Common thread for discussing issues/bugs and requests related to the new "auto-bypass on silence" in v6.57+dev0513 and "silent-track CPU reduction (experimental)" features.

Original thread in the Feature Requests forum with examples of other implementations and a few benchmarks.
Intelligent Plugin Sleep On Silence (CPU Saver)

Quick and dirty benchmark
3 track project with one instance of Acustica's FireClip (128x OS) on each track.
Render Times:
-1:49 with silence bypass disabled
-0:54 with silence bypass enabled. 0:50 and 0:51 running the plugins as a dedicated/separate process (margin of error?)
-1:06 with the same plugin inside BC Patchwork using it's built-in silence bypass so Reaper's native version seems more efficient.

Using silence bypass was over 100% faster to render which is a very nice improvement.


Preliminary thoughts/requests:
1)DONE! (but existing projects ignore the setting) Option to enable by default or set the default plugin behavior for auto-bypass from the FX Browser (for multiple plugins at a time) and use the current per-instance menu option as an override. This way it doesn't need manual enabling each time for every plugin.

2) Save the setting with Reaper presets. A column in Project Bay/FX would be a quick way enable/disable and also know where it's active.

3)DONE! (in Project Bay) Visual indication of when auto-bypass is active. i.e Italic font, a ❄️ icon or * in front of the plugin name in the mixer (not a big deal, but a nice extra).


4) Option to bypass silence optimizations when rendering. This allows more aggressive use of CPU saving features for mixing mixing/RT playback without worrying if there are compromises to the final render.

5) Option to treat non-audible (i.e. non-soloed) tracks as silent. Useful to free up CPU to record a new MIDI part at low latency in projects that are too CPU intensive for low buffers. It's much easier to solo the tracks we want to hear while recording than to mute everything else and then remember not to accidentally unmute tracks that were supposed to be muted afterwards.

6)DONE! -160dB is much better than perfect silence, but any threshold choice has trade-offs. If there is a single global threshold it would be nice to be user definable. -160dB is below the noise floor of 24-bit which is fine for most plugins but many output noise between -140dB to -80dB which may not add anything other than unnecessary processing.

When there are multiple plugins in a signal path with cumulative low level noise (pseudo-analog, amp sims etc.) this can easily pass the -160dB threshold causing later plugins, send FX, and group FX to remain active. -90dB (16-bit noise floor) is my preferred option from the fixed silence thresholds in DSEQ but other's may feel differently. A choice between Reaper's default and a user defined setting in preferences from the right-click menu in the FX browser which can be overridden per instance from the + menu would cover most cases.

7) A workaround tip for when the noise is above the silence threshold is adding noise gates as needed, but it would be best not to require them.

Huge thanks to the Reaper devs for this major performance increase!

Feel free to add any thoughts/issues below...
Any mixdown issues or plugins with unexpected behavior where this shouldn't be used etc.?
__________________
FRs: v5 Media Explorer Requests, Global Quantization, Session View
Win10 Pro 64-bit, Reaper 6(x64), AMD 3950x, Aorus X570 Master, 64GB DDR4 3600, PowerColor Red Devil 5700XT, EVO 970 2TB, 10TB HD, Define R6

Last edited by PitchSlap; 07-16-2022 at 04:25 PM.
PitchSlap is offline   Reply With Quote
Old 07-14-2022, 02:04 PM   #2
daxliniere
Human being with feelings
 
daxliniere's Avatar
 
Join Date: Nov 2008
Location: London, UK
Posts: 2,581
Default

Quote:
Originally Posted by PitchSlap View Post
3) Visual indication of when auto-bypass is active. i.e Italic font, a ❄️ icon or * in front of the plugin name in the mixer (not a big deal, but a nice extra).
Yes, that's a great idea. Would love to see that added to FX bay and Performance meter. Perhaps the text colour changes from black to ..?

Quote:
Originally Posted by PitchSlap View Post
4) Option to bypass silence optimizations when rendering. This allows more aggressive use of CPU saving features for mixing mixing/RT playback without worrying if there are compromises to the final render.
C'mon, you know that they'd never implement a compromised feature. If there were sonic compromises, I'm sure this feature wouldn't have been implemented in the first place.
__________________
Puzzle Factory Sound Studios, London [Website] [Instagram]
[AMD 5800X, 32Gb RAM, Win10x64, NVidia GTX1080ti, UAD2-OCTO, FireFaceUCX, REAPER x64]
[Feature request: More details in Undo History]
daxliniere is offline   Reply With Quote
Old 07-15-2022, 06:57 AM   #3
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

It may have been lost in the noise of the other features, but you can now set the project bay to view all FX (not grouping them by type/preset), and it will show when a particular plug-in is in idle mode.

Re: disabling auto-bypass on render -- IMO it's better to have playback and rendering match, you never know, if some funky-behaving plug-in is acting up, and it sounds good to you on playback, you don't want surprises in the render.
Justin is offline   Reply With Quote
Old 07-15-2022, 09:06 AM   #4
Edgemeal
Human being with feelings
 
Edgemeal's Avatar
 
Join Date: Apr 2016
Location: ASU`ogacihC
Posts: 3,913
Default

I set these FX to auto bypass, is it normal that the FX with PDC say active instead of idle?

+dev0714/x64 on Win10



EDIT Also sorting the Status column doesn't seem to sort correctly.
Edgemeal is offline   Reply With Quote
Old 07-15-2022, 10:55 AM   #5
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by Edgemeal View Post
I set these FX to auto bypass, is it normal that the FX with PDC say active instead of idle?

+dev0714/x64 on Win10



EDIT Also sorting the Status column doesn't seem to sort correctly.
Do those plugins report tail information?

Sorting by status isn’t supported because we update them dynamically and having the plugins move around would be annoying
Justin is offline   Reply With Quote
Old 07-15-2022, 11:05 AM   #6
Edgemeal
Human being with feelings
 
Edgemeal's Avatar
 
Join Date: Apr 2016
Location: ASU`ogacihC
Posts: 3,913
Default

Quote:
Originally Posted by Justin View Post
Do those plugins report tail information?
You got me, how/where do I look to see if a plugin supports it?
Edgemeal is offline   Reply With Quote
Old 07-15-2022, 06:47 PM   #7
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by Edgemeal View Post
You got me, how/where do I look to see if a plugin supports it?
Click the + menu in the plug-in and look in Compatibility settings
Justin is offline   Reply With Quote
Old 07-16-2022, 12:34 AM   #8
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

I also have a plugin (in development) with PDC that doesn't get auto bypassed i.e. the status stays at "active". However, I do see performance go down to 0.00%, so mabye it is auto bypassed, but it just doesn't show it under status?

Tested in REAPER v6.64+dev0715 on macOS 12.4. I have also tested on Win10, where it also doesn't auto bypass, but I haven't payed enough attention to performance there, oops.
Tale is offline   Reply With Quote
Old 07-16-2022, 03:33 AM   #9
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by Tale View Post
I also have a plugin (in development) with PDC that doesn't get auto bypassed i.e. the status stays at "active". However, I do see performance go down to 0.00%, so mabye it is auto bypassed, but it just doesn't show it under status?

Tested in REAPER v6.64+dev0715 on macOS 12.4. I have also tested on Win10, where it also doesn't auto bypass, but I haven't payed enough attention to performance there, oops.
ah thanks i’ll take a look at that!

edit: thanks, got it, fixing!

Last edited by Justin; 07-16-2022 at 10:39 AM.
Justin is offline   Reply With Quote
Old 07-16-2022, 03:39 PM   #10
PitchSlap
Human being with feelings
 
PitchSlap's Avatar
 
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,792
Default

Quote:
Originally Posted by Justin View Post
It may have been lost in the noise of the other features, but you can now set the project bay to view all FX (not grouping them by type/preset), and it will show when a particular plug-in is in idle mode.

Re: disabling auto-bypass on render -- IMO it's better to have playback and rendering match, you never know, if some funky-behaving plug-in is acting up, and it sounds good to you on playback, you don't want surprises in the render.
1) This was lost in the noise, very useful!
It would be amazing if we could also multi-select and enable/disable auto-bypass from the Project Bay. I've manually enabled this one at a time for thousands of plugins in existing projects and it would save so much time and tedium.

2) I find I sometimes get unexpected behavior with certain plugins on render that isn't present during real-time playback so the reverse can also be true.
Most commonly it's with delays (i.e Valhalla) where the first time the plugin gets enabled it does the pitch modulation thing similar to tweaking the delay time on the fly during playback.

Much of the time it sounds cool and I like it, but not always.
Your point is totally valid, it would just be nice for those who know what the project sounds like with auto-bypass disabled and only use it when mixing to save CPU where minor differences in sound are already present in many plugins that have separate RT/offline quality and OS settings.

I wonder if an option for a lookahead time could solve some compatibility issues? For example if there was a lookahead time of x blocks/ms Reaper would detect when plugins need to be enabled by reading ahead, then enable them slightly before. The trade off could be slightly increased latency, but when mixing and trying to save CPU other latency trade offs like higher audio buffer size are commonly used.

Also, it could be placebo, but when using this feature my mixes tend to sound slightly tighter/more defined (my threshold is ~-90dB), possibly since there's less low level gunk/fizz a bit like having a noise gate on many tracks that cuts sounds off below 16 bit noise floor. It might also have something to do with FX/instruments that have running LFOs getting "reset" when a plugin is enabled so it's always in phase (re-triggered) at the beginning of a sound.
__________________
FRs: v5 Media Explorer Requests, Global Quantization, Session View
Win10 Pro 64-bit, Reaper 6(x64), AMD 3950x, Aorus X570 Master, 64GB DDR4 3600, PowerColor Red Devil 5700XT, EVO 970 2TB, 10TB HD, Define R6

Last edited by PitchSlap; 07-16-2022 at 04:23 PM.
PitchSlap is offline   Reply With Quote
Old 07-16-2022, 05:16 PM   #11
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by PitchSlap View Post
1) This was lost in the noise, very useful!
It would be amazing if we could also multi-select and enable/disable auto-bypass from the Project Bay. I've manually enabled this one at a time for thousands of plugins in existing projects and it would save so much time and tedium.
...which is why it's preferable to use the project setting, then disable it for problematic plug-ins via compatibility settings.

Quote:
2) I find I sometimes get unexpected behavior with certain plugins on render that isn't present during real-time playback so the reverse can also be true.
Most commonly it's with delays (i.e Valhalla) where the first time the plugin gets enabled it does the pitch modulation thing similar to tweaking the delay time on the fly during playback.

Much of the time it sounds cool and I like it, but not always.
Your point is totally valid, it would just be nice for those who know what the project sounds like with auto-bypass disabled and only use it when mixing to save CPU where minor differences in sound are already present in many plugins that have separate RT/offline quality and OS settings.
We could add a compatibility setting to pre-feed silence through. It doesn't need to be lookahead exactly, just when transitioning from silence we could send a bunch of silence to simulate it having been processed sooner... or, you could just disable auto-bypass for those plug-ins (maybe that'd be better and avoid the cpu spike).


but in any case: a global option to not use auto-bypass when rendering offline seems like it would be useful?

Last edited by Justin; 07-16-2022 at 05:27 PM.
Justin is offline   Reply With Quote
Old 07-17-2022, 02:15 PM   #12
Edgemeal
Human being with feelings
 
Edgemeal's Avatar
 
Join Date: Apr 2016
Location: ASU`ogacihC
Posts: 3,913
Default

Quote:
Originally Posted by Justin View Post
Click the + menu in the plug-in and look in Compatibility settings
OK I think I understand, for plugins that don't go idle out of the box then in fx browser I enable the Compatibility > 'Use automatic tail detection' option for the plugin, and enabling auto-bypass option in project settings is like the global on/off switch. That seems to be working fine so far (+dev0717). For example plugins by IKMM like MixBus works out of the box, but AmpliTube 4/5 needs the compatibility option enabled.

Last edited by Edgemeal; 07-18-2022 at 05:48 AM. Reason: Updated
Edgemeal is offline   Reply With Quote
Old 07-17-2022, 02:55 PM   #13
PitchSlap
Human being with feelings
 
PitchSlap's Avatar
 
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,792
Default

Quote:
Originally Posted by Justin View Post
...which is why it's preferable to use the project setting, then disable it for problematic plug-ins via compatibility settings.



We could add a compatibility setting to pre-feed silence through. It doesn't need to be lookahead exactly, just when transitioning from silence we could send a bunch of silence to simulate it having been processed sooner... or, you could just disable auto-bypass for those plug-ins (maybe that'd be better and avoid the cpu spike).


but in any case: a global option to not use auto-bypass when rendering offline seems like it would be useful?
1) It seems I could be confused with how the different settings interact (will have to wait for the Reaper Blog video/manual update).
My assumption is that the project setting was more of a global enable/disable, but when it's enabled it's still only for plugin instances where it's been set already.

I use the compatibility settings in the FX browser. But if it's enabled by default for a plugin and I have 100 instances of it in an existing project, it will still be disabled for each one and needs to be enabled one by one, because the FX browser setting is only for new instances.
If the project setting globally enabled it for ALL plugins, I don't really see a way to disable it for problematic plugins individually. The per instance checkbox state is unaffected by the project setting, so if it wasn't previously enabled it will already be disabled.

2) A prefeed silence compatibility setting could really help with certain plugins while still allowing the feature to be used, or even just provide a bit more peace of mind when using auto-bypass in general. Time-saved troubleshooting at the expense of slightly less CPU savings is an option many users could prefer.

3) Definitely yes for an option to disable for offline rendering (looks like it's in the newest build ).
Full mixdowns aside, if I'm freezing or printing an individual track it doesn't make as much sense to have plugins turning on/off to save CPU as the frozen/rendered track will take zero CPU going forward and an uncompromised archive quality render is desirable.
__________________
FRs: v5 Media Explorer Requests, Global Quantization, Session View
Win10 Pro 64-bit, Reaper 6(x64), AMD 3950x, Aorus X570 Master, 64GB DDR4 3600, PowerColor Red Devil 5700XT, EVO 970 2TB, 10TB HD, Define R6
PitchSlap is offline   Reply With Quote
Old 07-17-2022, 06:48 PM   #14
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by PitchSlap View Post
1) It seems I could be confused with how the different settings interact (will have to wait for the Reaper Blog video/manual update).
My assumption is that the project setting was more of a global enable/disable, but when it's enabled it's still only for plugin instances where it's been set already.
The project setting affects all plug-ins in the project that report tail length (or have automatic tail detection enabled). You can also enable it per plugin-instance, in case you don't want it enabled for everything at once.

Quote:
I use the compatibility settings in the FX browser. But if it's enabled by default for a plugin and I have 100 instances of it in an existing project, it will still be disabled for each one and needs to be enabled one by one, because the FX browser setting is only for new instances.
This is no longer the case, in the +dev branch:
Code:
v6.58+dev0523 - May 23 2022
  + FX: when setting compatibility settings, update all open FX instances
Quote:
If the project setting globally enabled it for ALL plugins, I don't really see a way to disable it for problematic plugins individually. The per instance checkbox state is unaffected by the project setting, so if it wasn't previously enabled it will already be disabled.
If you have a problematic plug-in you can either enable "automatic tail detection" (to use a silence-detection heuristic, useful for plug-ins that misreport tail but still have silence->silence behavior), or "ignore plug-in reported tail" (for plug-ins that produce output from silence).

Quote:
2) A prefeed silence compatibility setting could really help with certain plugins while still allowing the feature to be used, or even just provide a bit more peace of mind when using auto-bypass in general. Time-saved troubleshooting at the expense of slightly less CPU savings is an option many users could prefer.
I'm still evaluating whether this is a good idea, for problematic plug-ins it might be better to just opt them out of auto-silence.
Justin is offline   Reply With Quote
Old 07-17-2022, 10:41 PM   #15
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Quote:
Originally Posted by Tale View Post
I also have a plugin (in development) with PDC that doesn't get auto bypassed i.e. the status stays at "active". However, I do see performance go down to 0.00%, so mabye it is auto bypassed, but it just doesn't show it under status?
Fixed in v6.64+dev0717, thanks!
Tale is offline   Reply With Quote
Old 07-19-2022, 12:59 AM   #16
PitchSlap
Human being with feelings
 
PitchSlap's Avatar
 
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,792
Default

Quote:
Originally Posted by Justin View Post
The project setting affects all plug-ins in the project that report tail length (or have automatic tail detection enabled). You can also enable it per plugin-instance, in case you don't want it enabled for everything at once.


This is no longer the case, in the +dev branch:
Code:
v6.58+dev0523 - May 23 2022
  + FX: when setting compatibility settings, update all open FX instances

If you have a problematic plug-in you can either enable "automatic tail detection" (to use a silence-detection heuristic, useful for plug-ins that misreport tail but still have silence->silence behavior), or "ignore plug-in reported tail" (for plug-ins that produce output from silence).


I'm still evaluating whether this is a good idea, for problematic plug-ins it might be better to just opt them out of auto-silence.
Thanks a lot for clarifying, I overlooked some changes.
Some of the random issues I've been having are probably due to thinking I needed the project setting enabled for it to work at all.

With the change you mentioned, and the new project bay option there's enough control for me to not use the global option.

I think part of the confusion on my part is that while the FX browser settings now affect existing instances, it's not reflected by the per-instance checkbox.
The setting says default for "new instances", and new instances will have the setting checked, but existing instances of the same plugin won't have it checked, even though the state is apparently the same?

Also, there's a custom threshold in the project settings, does that affect all plugins using auto-bypass in the project even if the option is not checked?

Aside from wonkiness with delays, I've found Acustica/Nebula plugins can need some time to initialize (impulse loading) so in the dark ages of using FX bypass envelopes I'd enable them early. If pre-feed becomes a thing, it might be best per plugin.
__________________
FRs: v5 Media Explorer Requests, Global Quantization, Session View
Win10 Pro 64-bit, Reaper 6(x64), AMD 3950x, Aorus X570 Master, 64GB DDR4 3600, PowerColor Red Devil 5700XT, EVO 970 2TB, 10TB HD, Define R6

Last edited by PitchSlap; 07-19-2022 at 01:17 AM.
PitchSlap is offline   Reply With Quote
Old 07-21-2022, 04:31 AM   #17
ovnis
Human being with feelings
 
ovnis's Avatar
 
Join Date: Oct 2011
Posts: 2,924
Default

Quote:
The project setting affects all plug-ins in the project that report tail length (or have automatic tail detection enabled).

It would be not more easy/understandable and powerfull to make only an option for all the projects (global option) and not per project?


And if we want to tweak some plugs (like no automatic idle for this plug), it should be only on the FX browser (like that the change will be inside all the projects and the contextual menu inside the FX window will be more simple).
ovnis is offline   Reply With Quote
Old 07-27-2022, 02:03 PM   #18
mim
Human being with feelings
 
Join Date: Mar 2009
Posts: 370
Default

This feature remind me that, years ago, I wrote a script that auto mute sends when send level is -inf.
It saves a massive amount of processing power :
https://forum.cockos.com/showthread.php?t=156820

I used this script in real world situations and it works great. I mixed a lot of projects that couldn't be RT computed otherwise.

I think there could be a native alternative for this that could be better. Because performance would be even better (no need to refresh every send constantly) and Cockos would be able to use an "hidden send bypass" rather than the otherwise very useful "send mute".
mim is offline   Reply With Quote
Old 07-27-2022, 05:31 PM   #19
ovnis
Human being with feelings
 
ovnis's Avatar
 
Join Date: Oct 2011
Posts: 2,924
Default

Amazing! It could be great if native.
ovnis is offline   Reply With Quote
Old 07-28-2022, 05:00 AM   #20
ovnis
Human being with feelings
 
ovnis's Avatar
 
Join Date: Oct 2011
Posts: 2,924
Default

Quote:
Originally Posted by mim View Post
This feature remind me that, years ago, I wrote a script that auto mute sends when send level is -inf.
It saves a massive amount of processing power :
https://forum.cockos.com/showthread.php?t=156820

I used this script in real world situations and it works great. I mixed a lot of projects that couldn't be RT computed otherwise.

I think there could be a native alternative for this that could be better. Because performance would be even better (no need to refresh every send constantly) and Cockos would be able to use an "hidden send bypass" rather than the otherwise very useful "send mute".

Why you don't talk about this on pre-release topic? Like that Justine could read this.
ovnis is offline   Reply With Quote
Old 07-28-2022, 03:12 PM   #21
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by mim View Post
This feature remind me that, years ago, I wrote a script that auto mute sends when send level is -inf.
It saves a massive amount of processing power :
https://forum.cockos.com/showthread.php?t=156820

I used this script in real world situations and it works great. I mixed a lot of projects that couldn't be RT computed otherwise.

I think there could be a native alternative for this that could be better. Because performance would be even better (no need to refresh every send constantly) and Cockos would be able to use an "hidden send bypass" rather than the otherwise very useful "send mute".
ah yeah we could optimize this case, I imagine
Justin is offline   Reply With Quote
Old 07-28-2022, 04:49 PM   #22
moliere
Human being with feelings
 
moliere's Avatar
 
Join Date: Mar 2007
Location: Wellington, New Zealand
Posts: 2,261
Default

Oh man, this would be awesome for my stupid massive live projects, it's all the bus sends that really hit me, but I need them to limit the organisational madness.
moliere is offline   Reply With Quote
Old 07-29-2022, 05:45 AM   #23
mim
Human being with feelings
 
Join Date: Mar 2009
Posts: 370
Default

Quote:
Originally Posted by Justin View Post
ah yeah we could optimize this case, I imagine
Great !
mim is offline   Reply With Quote
Old 07-29-2022, 05:27 PM   #24
ovnis
Human being with feelings
 
ovnis's Avatar
 
Join Date: Oct 2011
Posts: 2,924
Default

Quote:
Originally Posted by Justin View Post
ah yeah we could optimize this case, I imagine

Amazing!
ovnis is offline   Reply With Quote
Old 08-05-2022, 07:34 AM   #25
PitchSlap
Human being with feelings
 
PitchSlap's Avatar
 
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,792
Default

Quote:
Originally Posted by ovnis View Post
It would be not more easy/understandable and powerfull to make only an option for all the projects (global option) and not per project?


And if we want to tweak some plugs (like no automatic idle for this plug), it should be only on the FX browser (like that the change will be inside all the projects and the contextual menu inside the FX window will be more simple).
If the custom threshold in the project settings is independent from the checkbox I think it's useful to be per project. I assume this is the case, but as the settings are on the same line it's not entirely clear if it affects plugins with auto-bypass manually checked when the project setting is disabled.

If the threshold only works when checked in project settings it should probably only be for plugins without auto-bypass manually enabled with a global preference for threshold in the main Reaper settings (or vice-versa?)

As it's now possible to multi-select plugins in the project bay to enable this feature I'll mostly use that vs. the project setting for all plugins.

(*On the topic of project settings being ambiguous, a more thorough explanation at the bottom of the window like global preferences wouldn't be a bad idea)
__________________
FRs: v5 Media Explorer Requests, Global Quantization, Session View
Win10 Pro 64-bit, Reaper 6(x64), AMD 3950x, Aorus X570 Master, 64GB DDR4 3600, PowerColor Red Devil 5700XT, EVO 970 2TB, 10TB HD, Define R6

Last edited by PitchSlap; 08-05-2022 at 09:05 AM.
PitchSlap is offline   Reply With Quote
Old 08-07-2022, 08:14 PM   #26
PitchSlap
Human being with feelings
 
PitchSlap's Avatar
 
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,792
Default

I'm wondering if a project setting for the length of silence required to engage auto-bypass would be useful?
The main use case would be for short percussive sounds.

For example:
If you have a bunch of drums/percussion or sparse but frequently repeating tonal sounds that play every other 32 bars (or just in the last section) the silence length setting could be used so plugins are auto-bypassed during the empty sections, without being constantly turned on/off between every drum hit.

Maybe it already works flawlessly, but I tend to feel safer using the bypass envelope in these cases (which is much more time consuming).

Supporting BPM-based values would take the guess work out as it could just be set to 0.5-1 bar if you want to keep plugins active during sections when sounds are playing once or twice times per bar.

Has anyone noticed any problems when plugins are frequently enabled/disabled?
__________________
FRs: v5 Media Explorer Requests, Global Quantization, Session View
Win10 Pro 64-bit, Reaper 6(x64), AMD 3950x, Aorus X570 Master, 64GB DDR4 3600, PowerColor Red Devil 5700XT, EVO 970 2TB, 10TB HD, Define R6
PitchSlap is offline   Reply With Quote
Old 08-08-2022, 11:13 AM   #27
Subz
Human being with feelings
 
Subz's Avatar
 
Join Date: Jun 2006
Location: UK
Posts: 3,210
Default

Quote:
Originally Posted by Justin View Post
IMO it's better to have playback and rendering match, you never know, if some funky-behaving plug-in is acting up, and it sounds good to you on playback, you don't want surprises in the render.
YES!
Subz is offline   Reply With Quote
Old 09-06-2022, 07:13 PM   #28
PitchSlap
Human being with feelings
 
PitchSlap's Avatar
 
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,792
Default

If "silence" was defined as the noise floor of 32 or 64-bit. We could set the project setting to -2000 or something ridiculous the feature could be temporarily disabled as the threshold could never be reached.

A clear setting to temporarily disable/ignore while keeping the current auto-bypass state for all plugins would be preferable though.

Quote:
Originally Posted by Justin View Post
IMO it's better to have playback and rendering match, you never know, if some funky-behaving plug-in is acting up, and it sounds good to you on playback, you don't want surprises in the render.
Quote:
Originally Posted by Subz View Post
YES!

I have 16 cores and many of my projects can't play back in real-time with everything enabled at full quality.
That's why features like this, and the online/offline quality settings in CPU intensive instruments/FX are a god send.

If there's a something funky, it's likely to happen with silence optimizations on while mixing, not on rendering when the plugin behaves exactly as it always has.
Sometimes I'm hearing glitches only after rendering and have no idea which plugin it's related to which is why I'd rather take my chances with slightly longer render times, rather than trouble-shooting and re-rendering multiple times.

Mixing, music production and creative software development are art-forms/skills involving endless trade offs. Running out of processing power is a constant and daily struggle. Potentially minor differences or occasional issues with rendering pales in comparison and is a trade off I'm more than happy to choose.
__________________
FRs: v5 Media Explorer Requests, Global Quantization, Session View
Win10 Pro 64-bit, Reaper 6(x64), AMD 3950x, Aorus X570 Master, 64GB DDR4 3600, PowerColor Red Devil 5700XT, EVO 970 2TB, 10TB HD, Define R6

Last edited by PitchSlap; 09-06-2022 at 09:09 PM.
PitchSlap is offline   Reply With Quote
Old 09-08-2022, 06:21 AM   #29
ovnis
Human being with feelings
 
ovnis's Avatar
 
Join Date: Oct 2011
Posts: 2,924
Default

It would be nice to not allow some problematic plugs (like "time adjustement delay.js") to be auto bypassed.
ovnis is offline   Reply With Quote
Old 09-08-2022, 07:09 AM   #30
daxliniere
Human being with feelings
 
daxliniere's Avatar
 
Join Date: Nov 2008
Location: London, UK
Posts: 2,581
Default

Quote:
Originally Posted by ovnis View Post
It would be nice to not allow some problematic plugs (like "time adjustement delay.js") to be auto bypassed.
Oh man.. maybe JS plugins are the cause of the random glitches in render (but not playback).
__________________
Puzzle Factory Sound Studios, London [Website] [Instagram]
[AMD 5800X, 32Gb RAM, Win10x64, NVidia GTX1080ti, UAD2-OCTO, FireFaceUCX, REAPER x64]
[Feature request: More details in Undo History]
daxliniere is offline   Reply With Quote
Old 09-08-2022, 08:48 PM   #31
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by ovnis View Post
It would be nice to not allow some problematic plugs (like "time adjustement delay.js") to be auto bypassed.
can remove the "ext_tail_size = srate;" line from it... but in what case is it problematic? err I guess that should be "ext_tail_size = srate+40000;" ?
Justin is offline   Reply With Quote
Old 09-09-2022, 06:28 AM   #32
ovnis
Human being with feelings
 
ovnis's Avatar
 
Join Date: Oct 2011
Posts: 2,924
Default

Quote:
but in what case is it problematic?
For exemple, MIDI Note filter or ReaControlMIDI don't work when autobypass is enabled. Nothing happens.

Edit: time adjustement delay seems to work well with autobypass. Bad memories.

Last edited by ovnis; 09-09-2022 at 06:57 AM.
ovnis is offline   Reply With Quote
Old 09-10-2022, 03:43 PM   #33
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by ovnis View Post
For exemple, MIDI Note filter or ReaControlMIDI don't work when autobypass is enabled. Nothing happens.
If you enable auto bypass for the _instance_ of ReaControlMIDI (or MIDI note filter), then yes, it will get auto-bypassed. If you enable auto-bypass only for the project (and not the instance specifically), then it shouldn't get auto-bypassed.

We will give you the rope, it's your job not to hang yourself.
Justin is offline   Reply With Quote
Old 11-29-2022, 08:22 AM   #34
binbinhfr
Human being with feelings
 
binbinhfr's Avatar
 
Join Date: Oct 2021
Location: France
Posts: 363
Default

Hi there,

I just tried this feature and it's wonderfull : saves me a lot of CPU, no need to freeze anymore.

I just wonder if it works for VST instruments as well ? When I look at the perf meter, it's not as clear to me...
__________________
Reaper's lunatic
Reapack repository / GitHub / SoundCloud / Donate
binbinhfr is offline   Reply With Quote
Old 11-30-2022, 10:47 AM   #35
operator
Human being with feelings
 
operator's Avatar
 
Join Date: Nov 2019
Location: Austria, near Lake Constance
Posts: 453
Default

Quote:
Originally Posted by binbinhfr View Post
I just wonder if it works for VST instruments as well ? When I look at the perf meter, it's not as clear to me...
Yes, but for that you have to activate the option "use automatic tail detection..." in the "Compatibilty Settings" under the "+".

You only have to activate it once for every Instrument, it will remeber the setting when loading it in the future. (and it is a "global" setting --> this means changing it in one instance will change it in all other instances in the project aswell)

Last edited by operator; 11-30-2022 at 11:01 AM.
operator is offline   Reply With Quote
Old 11-30-2022, 12:21 PM   #36
Daodan
Human being with feelings
 
Join Date: Jan 2011
Posts: 1,167
Default

Quote:
Originally Posted by operator View Post
Yes, but for that you have to activate the option "use automatic tail detection..." in the "Compatibilty Settings" under the "+".
Wouldn't it be better to use "Auto-bypass plug-in on silence" option? It under the "+" but not in "Compatibilty Settings" or right click fx window title menu or project bay.
After that, if everything is good, I think we can set this setting for new instances in FX browser.

added
tested "use automatic tail detection..." with Serum. Didn't work. "Auto-bypass plug-in on silence" seems fine.
Daodan is offline   Reply With Quote
Old 11-30-2022, 03:01 PM   #37
binbinhfr
Human being with feelings
 
binbinhfr's Avatar
 
Join Date: Oct 2021
Location: France
Posts: 363
Default

Quote:
Originally Posted by Daodan View Post
Wouldn't it be better to use "Auto-bypass plug-in on silence" option? It under the "+" but not in "Compatibilty Settings" or right click fx window title menu or project bay.
After that, if everything is good, I think we can set this setting for new instances in FX browser.

added
tested "use automatic tail detection..." with Serum. Didn't work. "Auto-bypass plug-in on silence" seems fine.
Infact, I have to use "Auto-bypass plug-in on silence" to enable the bypass feature, but in case of VSTi, as @operator said, it seems that I also have to enable "use automatic tail detection...", which is the option that makes the difference for some VSTi plugins.

Thanks to both of you.
__________________
Reaper's lunatic
Reapack repository / GitHub / SoundCloud / Donate
binbinhfr is offline   Reply With Quote
Old 12-01-2022, 05:12 AM   #38
Triode
Human being with feelings
 
Triode's Avatar
 
Join Date: Jan 2012
Posts: 1,180
Default

Dear devs

Thanks for Auto-bypass

I reckon the wording of some of the auto-bypass menus could be changed to make the functionality clearer.

How about "Force Auto-bypass plug-in on silence" instead of just "Auto-bypass plug-in on silence" via the "+" sign to indicate that this overrides the project-wide option?
Also this should then be how it is labeled in default settings for new instances to help users know why it's there.

Also the in compatibility settings, how about "Ignore plugin reported tail size (designed for plugins that produce noise from silence)"

Should those two options (Ignore tail length/Use automatic tail length) be mutually exclusive? In which case should tick one remove the tick from the other? Or is there a reason why you'd want to use both?!

Many thanks again
__________________
Mixing / Brush and Beater Drums Online: www.outoftheboxsounds.com
Triode is offline   Reply With Quote
Old 12-01-2022, 09:18 AM   #39
nofish
Human being with feelings
 
nofish's Avatar
 
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,096
Default

Quote:
Originally Posted by Triode View Post
I reckon the wording of some of the auto-bypass menus could be changed to make the functionality clearer.
Agreed, I was also a bit confused by the various auto-bypass settings and their wordings at first (though Justin chimed in meanwhile and cleared it up, thanks).
nofish is offline   Reply With Quote
Old 12-04-2022, 02:01 AM   #40
PitchSlap
Human being with feelings
 
PitchSlap's Avatar
 
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,792
Default

I like that auto-bypass has it's own auto-bypass now.

Generally I'd want to keep it enabled globally for rendering mixdowns and turn it off only for project specific glitches (when it's hard to nail down the source).
It might make more sense as a per-project setting for master/stem rendering (in the render dialog itself or project settings).

When applying fx RT cpu isn't an issue and I don't mind that taking a bit longer vs rendering a full mix when the difference might be minutes.
__________________
FRs: v5 Media Explorer Requests, Global Quantization, Session View
Win10 Pro 64-bit, Reaper 6(x64), AMD 3950x, Aorus X570 Master, 64GB DDR4 3600, PowerColor Red Devil 5700XT, EVO 970 2TB, 10TB HD, Define R6
PitchSlap is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 03:11 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.