|
|
|
05-13-2022, 08:30 PM
|
#1
|
Human being with feelings
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,795
|
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.
|
|
|
07-14-2022, 02:04 PM
|
#2
|
Human being with feelings
Join Date: Nov 2008
Location: London, UK
Posts: 2,583
|
Quote:
Originally Posted by PitchSlap
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
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.
|
|
|
07-15-2022, 06:57 AM
|
#3
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
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.
|
|
|
07-15-2022, 09:06 AM
|
#4
|
Human being with feelings
Join Date: Apr 2016
Location: ASU`ogacihC
Posts: 3,921
|
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.
|
|
|
07-15-2022, 10:55 AM
|
#5
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by Edgemeal
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
|
|
|
07-15-2022, 11:05 AM
|
#6
|
Human being with feelings
Join Date: Apr 2016
Location: ASU`ogacihC
Posts: 3,921
|
Quote:
Originally Posted by Justin
Do those plugins report tail information?
|
You got me, how/where do I look to see if a plugin supports it?
|
|
|
07-15-2022, 06:47 PM
|
#7
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by Edgemeal
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
|
|
|
07-16-2022, 12:34 AM
|
#8
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,653
|
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.
|
|
|
07-16-2022, 03:33 AM
|
#9
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by Tale
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.
|
|
|
07-16-2022, 03:39 PM
|
#10
|
Human being with feelings
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,795
|
Quote:
Originally Posted by Justin
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.
|
|
|
07-16-2022, 05:16 PM
|
#11
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by PitchSlap
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.
|
|
|
07-17-2022, 02:15 PM
|
#12
|
Human being with feelings
Join Date: Apr 2016
Location: ASU`ogacihC
Posts: 3,921
|
Quote:
Originally Posted by Justin
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
|
|
|
07-17-2022, 02:55 PM
|
#13
|
Human being with feelings
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,795
|
Quote:
Originally Posted by Justin
...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
|
|
|
07-17-2022, 06:48 PM
|
#14
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by PitchSlap
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.
|
|
|
07-17-2022, 10:41 PM
|
#15
|
Human being with feelings
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,653
|
Quote:
Originally Posted by Tale
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!
|
|
|
07-19-2022, 12:59 AM
|
#16
|
Human being with feelings
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,795
|
Quote:
Originally Posted by Justin
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.
|
|
|
07-21-2022, 04:31 AM
|
#17
|
Human being with feelings
Join Date: Oct 2011
Posts: 2,924
|
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).
|
|
|
07-27-2022, 02:03 PM
|
#18
|
Human being with feelings
Join Date: Mar 2009
Posts: 370
|
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".
|
|
|
07-27-2022, 05:31 PM
|
#19
|
Human being with feelings
Join Date: Oct 2011
Posts: 2,924
|
Amazing! It could be great if native.
|
|
|
07-28-2022, 05:00 AM
|
#20
|
Human being with feelings
Join Date: Oct 2011
Posts: 2,924
|
Quote:
Originally Posted by mim
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.
|
|
|
07-28-2022, 03:12 PM
|
#21
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by mim
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
|
|
|
07-28-2022, 04:49 PM
|
#22
|
Human being with feelings
Join Date: Mar 2007
Location: Wellington, New Zealand
Posts: 2,262
|
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.
|
|
|
07-29-2022, 05:45 AM
|
#23
|
Human being with feelings
Join Date: Mar 2009
Posts: 370
|
Quote:
Originally Posted by Justin
ah yeah we could optimize this case, I imagine
|
Great !
|
|
|
07-29-2022, 05:27 PM
|
#24
|
Human being with feelings
Join Date: Oct 2011
Posts: 2,924
|
Quote:
Originally Posted by Justin
ah yeah we could optimize this case, I imagine
|
Amazing!
|
|
|
08-05-2022, 07:34 AM
|
#25
|
Human being with feelings
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,795
|
Quote:
Originally Posted by ovnis
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.
|
|
|
08-07-2022, 08:14 PM
|
#26
|
Human being with feelings
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,795
|
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
|
|
|
08-08-2022, 11:13 AM
|
#27
|
Human being with feelings
Join Date: Jun 2006
Location: UK
Posts: 3,221
|
Quote:
Originally Posted by Justin
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!
|
|
|
09-06-2022, 07:13 PM
|
#28
|
Human being with feelings
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,795
|
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
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
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.
|
|
|
09-08-2022, 06:21 AM
|
#29
|
Human being with feelings
Join Date: Oct 2011
Posts: 2,924
|
It would be nice to not allow some problematic plugs (like "time adjustement delay.js") to be auto bypassed.
|
|
|
09-08-2022, 07:09 AM
|
#30
|
Human being with feelings
Join Date: Nov 2008
Location: London, UK
Posts: 2,583
|
Quote:
Originally Posted by ovnis
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).
|
|
|
09-08-2022, 08:48 PM
|
#31
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by ovnis
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;" ?
|
|
|
09-09-2022, 06:28 AM
|
#32
|
Human being with feelings
Join Date: Oct 2011
Posts: 2,924
|
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.
|
|
|
09-10-2022, 03:43 PM
|
#33
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Quote:
Originally Posted by ovnis
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.
|
|
|
11-29-2022, 08:22 AM
|
#34
|
Human being with feelings
Join Date: Oct 2021
Location: France
Posts: 363
|
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...
|
|
|
11-30-2022, 10:47 AM
|
#35
|
Human being with feelings
Join Date: Nov 2019
Location: Austria, near Lake Constance
Posts: 453
|
Quote:
Originally Posted by binbinhfr
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.
|
|
|
11-30-2022, 12:21 PM
|
#36
|
Human being with feelings
Join Date: Jan 2011
Posts: 1,182
|
Quote:
Originally Posted by operator
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.
|
|
|
11-30-2022, 03:01 PM
|
#37
|
Human being with feelings
Join Date: Oct 2021
Location: France
Posts: 363
|
Quote:
Originally Posted by Daodan
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.
|
|
|
12-01-2022, 05:12 AM
|
#38
|
Human being with feelings
Join Date: Jan 2012
Posts: 1,185
|
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
|
|
|
12-01-2022, 09:18 AM
|
#39
|
Human being with feelings
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,110
|
Quote:
Originally Posted by Triode
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).
|
|
|
12-04-2022, 02:01 AM
|
#40
|
Human being with feelings
Join Date: Jan 2008
Location: Vancouver, BC
Posts: 3,795
|
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
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 03:51 AM.
|