10 posts
Page 1 of 1
What situation would maximum Dropout Protection not be called for?

I will summarize my understanding after reading S1 literature, watching tutorials and listening to the CTO of Presonus cover the latency engines of Studio One. Presonus could definitely step up its game on presenting easy to understand info on the Dropout Protection feature and Native vs Hardware Monitoring and Blue and Green Z's. Let's try to clear some of this up.

1) Dropout Protection is a unique feature in Studio one that separates the recording engine from the playback engine. If you are recording, the buffer size (latency) of your Audio Interface will be leveraged for the record armed tracks. For all other playback audio, the software will handle the audio through its own higher buffer to help protect from audio dropouts as a result of overloading your audio interface.
2) Studio One has three latency engines per the CTO: Software, hardware and instrument. This is the architecture that created the Green Z vs Blue Z.
3) Green Z is the ultimate latency source of truth and incorporates Virtual Instrument recording roundtrip ms. Whatever that ms reading is, will be your total latency with Virtual Instruments and Analog recording combined.
4) Blue Z is specific to audio recording latency and is directly related to your hardware (audio interface). This is the equivalent of dropout protection using the hardware engine for the armed recording tracks.
5) Z protection can be enabled/disabled by clicking the Z at the bottom of channel strips.

I don't understand #5 and what the use case is for toggling the Z on or off. Specifically for the Master Bus, what would the use case be for toggling the Z on or off?

DAW: Studio One Professional 6.5
User avatar
by stefanrauch1 on Wed Oct 13, 2021 12:42 pm
"Why wouldn't you have Dropout Protection on Maximum always?"

Because it creates more problems than it solves.
- Automation with high buffer size gets laggy and choppy
- Plugin Latency Compensation becomes unreliable
- Sync of recorded stuff is unpredictable
- not possible to hear instruments in real context with Green Z because all plugins with latency are bypassed.

Stick to Minimal DP and buffer size of 256 or smaller, use direct monitoring of audio interface for tracking, refrain from latency inducing plugins while song writing and you'll be fine.

PS: I have not used Drop Out Protection in years, so some of the listed issues might be solved, or others have popped up.

OS: Win10 x64 || Software: Studio One Pro [latest version]
Hardware: AMD Ryzen 9 3950X || Asus Prime X570-PRO || 64GB DDR4 RAM || Asus Dual-RTX2070S-A8G-EVO || UAD2 Octo & Duo PCIe
Peripherals: RME Fireface UFX II (+2x ADA8200) || Faderport Legacy || Atom || NI Komplete Kontrol A25
Audio Settings: 44,1/48kHz, 256 Samples, DP Off, 64 Bit
User avatar
by robertgray3 on Wed Oct 13, 2021 1:21 pm
The use case for toggling Green Z is to fix incompatibilities and bugs that come up when using Green Z.

I use DP at Max when I use S1 but it comes with a bunch of compromises. Some of what Stefan mentioned is still true, and some plug-ins don’t update properly with Green Z. Automation is better lately but Aux channels/external instruments have issues with Green Z and Green Z causes some problems with routing.

I definitely prefer the way Logic did it where a dual buffer is always active (so everything has to work with it) and there’s a separate button just to disable plug-ins with greater than X ms of latency.

Mac OS X Catalina 10.15.7
Mac Pro 6.1
3 GHz 8-Core Intel Xeon E5
32 GB 1066 MHz DDR3
Dual AMD FirePro D500 3072 MB
Quantum 2
User avatar
by waltong on Wed Oct 13, 2021 1:25 pm
robertgray3 wroteI use DP at Max when I use S1 but it comes with a bunch of compromises. Some of what Stefan mentioned is still true, and some plug-ins don’t update properly with Green Z. Automation is better lately but Aux channels/external instruments have issues with Green Z and Green Z causes some problems with routing.

I definitely prefer the way Logic did it where a dual buffer is always active (so everything has to work with it) and there’s a separate button just to disable plug-ins with greater than X ms of latency.


Yeah, I'm more confused than clear now :reading: . We really need some product level guidance from the marketing or product team on all of these twists and turns of the 3 latency engines and how they do and don't interrelate and the trade-offs/benefits of the various configurations.

I still have the same basic question on #5, what would be a situation where you would toggle on and off the Z on the master bus?

DAW: Studio One Professional 6.5
User avatar
by robertgray3 on Wed Oct 13, 2021 1:29 pm
You probably won’t get any guidance on the twists and turns because they’re not intended shortcomings- the option is there to disable it in case something isn’t working right. The options are there and you use whichever one you like and have the least problems with.

Let’s say you’re using a plugin on your master bus that doesn’t update from the controls while in Green Z mode. You would have to toggle it off.

Mac OS X Catalina 10.15.7
Mac Pro 6.1
3 GHz 8-Core Intel Xeon E5
32 GB 1066 MHz DDR3
Dual AMD FirePro D500 3072 MB
Quantum 2
User avatar
by fabiankiesewetter1 on Mon Oct 18, 2021 8:16 am
Have you seen the newest version of this KB article yet? (https://support.presonus.com/hc/en-us/a ... toring-FAQ)
Is there any information you miss here?

Fabian Kiesewetter - Product Manager - Presonus Software - Hamburg
User avatar
by j0001s on Mon Oct 18, 2021 8:52 am
The OP's question can be interpreted two ways.

Why won't you have it enabled always has been covered, but I'll give two personal examples. IK Amplitube controls are disabled when software latency protection is enabled (IK issue). And, you can't use it when you're using Pipeline.

The other way of interpreting it is "if you're going to enable it, why not set it to maximum?". Reason 1 is that the meters and any displays (such as RTAs) will lag by the number of samples used for latency protection. Does that matter? To me, no - my displays being off by 20 ms worst case won't change what I do.

I would also expect that VST2 plugins would stairstep when automated if dropout protection is set high just as they would with high buffer settings. In case you're not aware, VST2 plugins change their automated values at the start of each buffer only. With large buffers you can hear the stairsteps. VST3 and AU don't have this issue, as properly coded ones interpolate the values every sample. So, I use VST3 whenever possible, and dropout protection doesn't cause an issue here.

What I don't know is if dropout protection has any effect on writing automation with the faders. Hasn't been clarified anywhere that I found.
User avatar
by craigallen2 on Sat Jan 29, 2022 6:43 pm
waltong wroteWhat situation would maximum Dropout Protection not be called for?

...

I don't understand #5 and what the use case is for toggling the Z on or off. Specifically for the Master Bus, what would the use case be for toggling the Z on or off?



Thank you so much for raising this thread and for your synopsis.
In addition to other helpful answers to your questions... I'm a newb here, but just spent several hours playing around with all settings, and these are among my discoveries:

The Device Block Size (DBS) on the Audio Tab, the Process Block Size (PBS) on the Processing Tab, and the Dropout Protection (DoP) feature (on both the Processing tab and the Performance window) work in conjunction. Meaning, changing one affects how the others interact. (The difference is that DBS and DoP are user configured, and PBS is automated in response, by S1.) So, there appears to be no hard and fast rule on what setup is best for all scenarios.

The BIG thing that hasn't been mentioned yet is the CPU performance. I found I was peaking at 100% on a project with multiple orchestral instruments. So, I ran a bunch of tests. At 256 samples buffer (DBS), set to either MAXIMUM or HIGH DoP, the CPU was pegged at 100%. Meanwhile, at 256 DBS, Medium also hit 100%, but LOW & MINIMUM both peaked at 74%. Changing the buffer to 512 samples (DBS) was even more dramatic in CPU Performance: While MAX & HIGH still pegged at 100%, MEDIUM/LOW/MINIMUM all topped out at 60%.
What's to account for the difference? Well, it has to do with when DoP is engaged. DoP is engaged when the PBS is higher than the DBS. This changes (i.e. from affecting only Max, or Max and High, or Max, High and Medium), etc. So, at 1024 Samples (DBS), MAX peaked at 97% -- with DoP engaged. But now as PBS is raised, it's no longer higher than DBS on High/Medium/Low/Minimum -- so all of them run without Dropout Protection -- and peaked at 52%.

So, When to NOT run on Maximum? Well, when you need more CPU resources. In this case, I got 2x performance!!! by taking it off Maximum. In each case 256 or higher DBS, Low & Maximum give the same. But raising buffers gives increasingly better performance and expands that outward to Medium (at 512) and to even High (at 1024). And then presumably to Max at 2048, though I didn't test.

And when to disable (toggle off) the Green Arrow on the Master? Same scenario. When you need more CPU resources. As this accomplishes the same thing.

Interestingly, my BEST results were back on MAXIMUM -- but with DoP disengaged. 47% CPU resources.

So, rules of thumb that I found:
SIMPLEST APPROACH: (i.e. set and forget)
- Set DoP to MEDIUM.
- Record at 128 (or below). Engage Low Latency.
- Mix at 512 (or higher).

Variants: Set DoP to Low or Minimal if mixing at 256 or below. Set to High or Max if mixing at 1024 or above.

OPTIMIZED APPROACH. (tweak continually)
- Record MIDI Instruments at 128 or lower. DoP: MINIMUM. (7.1 ms RT at 128 on my Audient interface. usable. YMMV.)
- Record AUDIO at 128 or lower. Use Low Latency. DoP: MEDIUM (this drops audio latency from 35ms to 12ms on my Audient interface. YMMV)
- MIX at 512 or higher. Disable Low Latency. DoP: MAXIMUM.
Also, Don't have an Audio channel armed to record as that raises resources.

In general, only engage LLM on Master Channel when needed (like for recording), and when no plugins are adversely affected.

My Question: How to engage Hardware Monitoring (and get Blue Z)?
My box option "Use software low-latency monitoring instead of hardware monitoring" -- which is supposed to be disabled -- mine is grayed out. This would seem to be disabled; however, I do not get the affirmation of the Blue Z.
I wish S1 simply had an obvious check box for utilizing Hardware Monitoring.
(Samplitude's options are set up SO much more straightforward!)
User avatar
by frank.crow on Sun Jan 30, 2022 7:16 pm
I don’t even have that option anymore. I can’t even use maximum anymore. I was someone who always kept it on maximum without even thinking about it but maybe two updates ago I lost that ability. If I leave it on maximum all 3rd party meters introduce latency that makes them unusable

Very Respectfully

Frank Crow

Mac Mini (Late 2014)
Processor: 3.0 GHz Intel Core I7
Memory: 16 GB
Presonus. Studio One Pro V6
Presonus Quantum
Hardware DBX 160a
Hardware DBX 160XT
GA. LA2A (clone)
GA. LA3A (clone)
WA76 1176 (clone)
WA EQP Pultec (clone)
WA 73 Neve (clone)
Softube. Console 1 MK3 (pending)
Presonus. Faderport 8 (dual)


"God's grace" :D
User avatar
by Jemusic on Mon Jan 31, 2022 4:35 pm
When I set DP to medium or high and set for low instrument latency it works OK except the figures I get for the instrument latency might be 7 mS or so. When I set DP to minimum and don't use any Low Z Inst latency (eg set for normal operation with lowest buffer on 32 or 64 samples) I get a faster virtual instrument response that way eg under 3 mS.

Specs i5-2500K 3.5 Ghz-8 Gb RAM-Win 7 64 bit - ATI Radeon HD6900 Series - RME HDSP9632 - Midex 8 Midi interface - Faderport 2/8 - Atom Pad/Atom SQ - HP Laptop Win 10 - Studio 24c interface -iMac 2.5Ghz Core i5 - High Sierra 10.13.6 - Focusrite Clarett 2 Pre & Scarlett 18i20. Studio One V5.5 (Mac and V6.5 Win 10 laptop), Notion 6.8, Ableton Live 11 Suite, LaunchPad Pro

10 posts
Page 1 of 1

Who is online

Users browsing this forum: No registered users and 104 guests