Volume automation latency issue (BUG)

[nofolobricity]

YouTube BUG Demo
The attached video shows how inaccurately the volume automation curve is behaving. A piece of the clap's attack doesn't get muted in time, and the following clap fails to unmute fast enough either.
I never expected such a fantastic DAW to have such a seemingly basic issue. I've already posted this on Reddit, but I want to bring more attention to this bug. Hopefully, we can get enough people reaching out to the Fender Studio Pro team so they at least acknowledge and react to it. It’s incredibly frustrating that such an awesome DAW suffers from such a rookie flaw.

 

[dominicperry]

Your problem here is probably related to the 266ms of latency in your mixer. Although you could argue that delay compensation out to allow for automation to work correctly on volume automation of a specific part (which I would agree with), I imagine if you remove whatever is causing so much latency, the problem will be cured, or at least worked around. If I'm correct (i.e. removing the large latency fixes the problem), then it would be interesting to know more detail of the setup of that particular song to figure out why lack of latency compensation is messing with volume automation.

Dominic

 

[nofolobricity]

Your problem here is probably related to the 266ms of latency in your mixer. Although you could argue that delay compensation out to allow for automation to work correctly on volume automation of a specific part (which I would agree with), I imagine if you remove whatever is causing so much latency, the problem will be cured, or at least worked around. If I'm correct (i.e. removing the large latency fixes the problem), then it would be interesting to know more detail of the setup of that particular song to figure out why lack of latency compensation is messing with volume automation.

Dominic

Thanks for the reply. I'll experiment with this in the future, as this particular project is already finished. Yes, the latency is indeed high. However, that's because modern plugins are quite demanding. Even a simple linear phase EQ will introduce at least the same amount of delay. The most interesting thing is that Ableton Live and FL Studio handle automation perfectly, even with much higher latency. Logic also has something like sample-accurate automation, which perfectly matches the drawn curves. So, regardless of what my experiment might show, this is genuinely a very bad bug. Automation is one of the most crucial aspects of modern music production right now.

 

[bailatosco]

Even if SO/FSP uses this kind of "dual engine" with dropout protection, latency should be perfectly compensated no matter what buffer size you choose in any of the engines. Is that really hard to do? Maybe, I don't know, figure it out.

I'm bitter about this because as soon as I started producing electronic music, I had to run the hell away from studio one because it became very obvious that timing in general was very wonky, so you can't trust it with the kind of "sharp" automations that are so common in electronic music.

I still use it for producing bands sometimes but I never do things like automating bypasses of effects, muting/unmuting when timing is critical. I'll just make another track with the settings I need.

 

[nofolobricity]

Even if SO/FSP uses this kind of "dual engine" with dropout protection, latency should be perfectly compensated no matter what buffer size you choose in any of the engines. Is that really hard to do? Maybe, I don't know, figure it out.

I'm bitter about this because as soon as I started producing electronic music, I had to run the hell away from studio one because it became very obvious that timing in general was very wonky, so you can't trust it with the kind of "sharp" automations that are so common in electronic music.

I still use it for producing bands sometimes but I never do things like automating bypasses of effects, muting/unmuting when timing is critical. I'll just make another track with the settings I need.

Your track duplication method, even though it's a bit of a workaround, is actually a really good and viable solution. Thanks!
I moved away from S1 to other DAWs a long time ago, and later became a dedicated Ableton Live user. But I was still missing a lot of things, which I finally found in the new FSP (SO). I had no idea that this old automation issue still existed, though! The devs keep adding so many new features to FSP, yet they can't fix a genuinely critical problem. It's a shock to me.
I hope my posts create some buzz and people start knocking on the devs' doors en masse asking them to fix the automation. It really is an excellent DAW, but not with this kind of flaw.

 

[dominicperry]

You need to report this directly to Fender/Presonus (this forum is independent, and does not belong to Fender, although we are lucky to get some Fender/Presonus employees here). Sometimes fixes come quickly if there's a repeatable problem that's clearly explained.

For the record, delay compensation is fiendishly complex and some other DAWS are struggling with it too - there's a bunch of complaints going back years on the Avid forum about Pro Tools audio and MIDI delay compensation.

Dominic

 

[nofolobricity]

You need to report this directly to Fender/Presonus (this forum is independent, and does not belong to Fender, although we are lucky to get some Fender/Presonus employees here). Sometimes fixes come quickly if there's a repeatable problem that's clearly explained.

For the record, delay compensation is fiendishly complex and some other DAWS are struggling with it too - there's a bunch of complaints going back years on the Avid forum about Pro Tools audio and MIDI delay compensation.

Dominic

Thank you, Dominic, for clearing that up. I'm pretty far removed from the internal technical side of things, especially when it comes to delay compensation under the hood.
If I just submit a direct ticket, it's unlikely anything will change since I'm just one user among thousands. That's exactly why I'm trying to bring some public attention to this issue. I actually asked some friends and ran tests on their computers. In FL Studio, Ableton Live, Bitwig, and other DAWs, the delay compensation issues seem to be completely resolved (at least based on the tests I did using CPU-heavy synths that report PDC, linear-phase EQs, and heavy-hitters like Melda's MSpectralDynamics).
Because of this, I've come to the conclusion that solutions definitely exist, since other DAWs have successfully tackled it. My hope is to get more people interested enough to run their own tests or at least forward my video to the FSP (ex-S1) team, so they can figure out how to make the DAW even better in the future.

 

[Navar]

If I just submit a direct ticket, it's unlikely anything will change since I'm just one user among thousands. That's exactly why I'm trying to bring some public attention to this issue. I actually asked some friends and ran tests on their computers.

I don't agree with this approach from my personal experience with SPro/S1/whatsoever. In my personal opinion the best way to really get in contact and to address problems like this is, to create a reproducable test project with this behaviour.
As clean and simple as possible, and if possible only with stock plugins (which should be easy). Than reach out to the support and send them this project and if you have it available a link to the video. Include your system specs (as they will ask them anyway) and every information you find useful.
To be honest, I don't think, that a YT video will get the attention you need because there are so many of them and no support team have the time to read through comments or wait until they got linked or anything like that.
And of course, you can make this test available for other users so they can download and check it very easy on their side, confirm and report it also. Not many users are willing to create a test project on their own and work their way to get to the problem.

I have reported a lot of stuff over the years and got the best results by doing it like this. That doesn't mean, that every problem got solved or got solved quickly and there are other PDC problems which drive me crazy in V8 that didn't got addressed yet. But at least I've got an official reply from the support, that the problem is real and they have an internal open ticket for this. All I can do is wait and hope, that's a bit frustrating but at least I really know, that the case is open and the problem is not on my side of the screen. And if I want to ride their nerves I can refer to an official reply and say: "hey, x month ago you've officialy confirmed a bug but nothing happend, what's going on".

Why stock plugins? Because it's reproducable and has no need to get cross-checked. I'm not a big fan of this "oh you use a lot of 3rd party plugins, it's you're fault because you don't use the stock ones" but it's also clear, that there are a lot of plugins which cause problems, have problems with outdated libs or stuff like that. And if you can show it with stock plugins, there is nearly zero chance, that the problem is somewhere else. As an example here, I don't have a lot of trust in Melda plugins because not every plugin reports the plugin delay correct. I found some which definitly don't do it. Don't know if it's by design or a bug or got fixed, but it's not my problem, I've stopped using them.

 

[nofolobricity]

I don't agree with this approach from my personal experience with SPro/S1/whatsoever. In my personal opinion the best way to really get in contact and to address problems like this is, to create a reproducable test project with this behaviour.

That makes perfect sense, Lavar, thanks for the detailed advice! I'll definitely take it on board.

Regarding Melda, I wouldn't really point the finger at them, since none of their plugins have ever caused any glitches in other DAWs, and everything lined up perfectly. By the way, a friend also checked this in Logic. They have a 'Sample Accurate Automation' option, which he used for the test. It works flawlessly, perfectly sample-accurate.

As for the test itself, it's as primitive as it gets. I actually made a thread on Reddit, and someone there confirmed the exact same issue.

You just load up Impact or Sample One. Drop a snare or a clap in there. Automate the track Volume knob so it drops from 0 down to silence exactly right before, let's say, the 2nd note that triggers the sample. And then bring it back from silence to 0 right before the 3rd note. And enjoy the show.

The result will be this: the clap where the volume returns from silence back to zero will have its attack chopped off. And in a fully loaded project, the behavior can get even more erratic. Not only does the attack get chopped off, but on the preceding sample where the volume automation goes from 0 down to silence, it won't mute fast enough, leaving a sharp click from the clap/snare.

The problem is that other modern DAWs handle sharp volume cuts and boosts perfectly fine, whether you are using native or 3rd-party plugins. It just seems like the guys at Fender/PreSonus overlooked this aspect.

What surprises me is that right after I decided to switch to Fender Studio Pro 8 and got frustrated by this issue, it feels like I'm the only one noticing it. I haven't really found any other posts about this specific problem on the forums or Reddit.

 

[Crossinger]

What surprises me is that right after I decided to switch to Fender Studio Pro 8 and got frustrated by this issue, it feels like I'm the only one noticing it. I haven't really found any other posts about this specific problem on the forums or Reddit.

Maybe I’m just an old chap, but since this was a more widespread issue amongst DAWs back in the days, I’m accustomed to always giving some offset to automation and never do it on beat/bar. Never changed my behavior and so I simply wasn’t affected by your observation.

 

[nofolobricity]

Never changed my behavior and so I simply wasn’t affected by your observation.

I'd venture a guess that you mostly work with live music and audio recordings, where there's generally less automation compared to modern EDM or Pop music. Since I used to work in Ableton Live, I'm used to dealing with an absolute ton of automation. Having to manually shift every single point slightly off the grid here gets a bit tedious. But I'll try to get used to it, of course

 

[SwitchBack]

To me this looks like level automation in the wrong place. If you want to automate what goes into a channel's FX chain then automate before the FX chain, and if you want to automate what comes out of the FX chain then automate after the FX chain. A channel's fader comes after the FX chain, which does not serve the goal intended in the video. Try automating the instrument's output level/velocity instead.

 

[nofolobricity]

Try automating the instrument's output level/velocity instead.

Thanks for the input, SwitchBack. I fully understand the signal flow and that the channel fader is post-FX. However, that is exactly where I need the automation to be.

In modern electronic music, we often need to abruptly chop off reverb tails, delay feedback, or heavy distortion that is generated inside the FX chain. Automating the instrument's internal volume or velocity won't help with that, because the plugin tails will still ring out.

The core issue here isn't the routing. The issue is that the DAW's Plugin Delay Compensation fails to align the post-FX volume automation perfectly with the delayed audio stream. Regardless of where the fader is in the chain, the automation should be sample-accurate, just like it is in other modern DAWs.

 

[Crossinger]

Having to manually shift every single point slightly off the grid here gets a bit tedious. But I'll try to get used to it, of course

I don't want to deny your need. Your request is totally valid and going the "offset" way for many automation lanes is not an acceptable workaround. Indeed, the amount of automation in my tracks is rather manageable.

 

[SwitchBack]

Thanks for the input, SwitchBack. I fully understand the signal flow and that the channel fader is post-FX. However, that is exactly where I need the automation to be.

In modern electronic music, we often need to abruptly chop off reverb tails, delay feedback, or heavy distortion that is generated inside the FX chain. Automating the instrument's internal volume or velocity won't help with that, because the plugin tails will still ring out.

The core issue here isn't the routing. The issue is that the DAW's Plugin Delay Compensation fails to align the post-FX volume automation perfectly with the delayed audio stream. Regardless of where the fader is in the chain, the automation should be sample-accurate, just like it is in other modern DAWs.

OK, I see your point. But then the problem isn't the audio processing but merely the GUI presentation: When a track has an automation curve overlay then that overlay should show compensated for latency

 

[nofolobricity]

OK, I see your point. But then the problem isn't the audio processing but merely the GUI presentation: When a track has an automation curve overlay then that overlay should show compensated for latency

Exactly. Whatever happens under the hood, the grid, the automation, and the audio need to match perfectly. Hopefully, the devs will sort it out!

 

[Navar]

Exactly. Whatever happens under the hood, the grid, the automation, and the audio need to match perfectly. Hopefully, the devs will sort it out!

I've made a small test because I was curious about this. And there is a kind of a thing with the automation but I don't think, that this is related to the delay compensation. Because it also happens without any delay and it doesn't change the behaviour with more plugin latency. If there would be a problem with the delay compensation, than the problem would change with added latency, gets worse or gets better.
I've loaded a short clappy sample into impact and added a volume automation like you did. And the sample comes through for a tiny glitch and the next note looses it's transient. But even with an added latency of 600ms with some pro eq instances the behaviour doesn't change. And this would be the case if there was a probleme with the compensation engine.
But it's not accurate as it should be and automating the mute button seems to be even worse. And it's the same in V7 and V8, I see no difference between them.

 

[SwitchBack]

Delay/latency in the operation of the fader itself? Like steering a ship...

 

[sintil8]

I've made a small test because I was curious about this. And there is a kind of a thing with the automation but I don't think, that this is related to the delay compensation. Because it also happens without any delay and it doesn't change the behaviour with more plugin latency. If there would be a problem with the delay compensation, than the problem would change with added latency, gets worse or gets better.
I've loaded a short clappy sample into impact and added a volume automation like you did. And the sample comes through for a tiny glitch and the next note looses it's transient. But even with an added latency of 600ms with some pro eq instances the behaviour doesn't change. And this would be the case if there was a probleme with the compensation engine.
But it's not accurate as it should be and automating the mute button seems to be even worse. And it's the same in V7 and V8, I see no difference between them.

As you are already set up with a test project, any chance of trying a Mix Device at the top of the Fx chain and automate either the volume or the on/off switch with the appropriate settings. Does this present the same result?
I suppose I'm asking if the point at which the automation hits the signal is the deciding factor.

Kindest regards to all.

Edit: Don't bother, I tried it myself same outcome?

 

[nofolobricity]

But it's not accurate as it should be and automating the mute button seems to be even worse. And it's the same in V7 and V8, I see no difference between them.

Thanks for testing this, Navar! Your theory makes perfect sense. Since you already have a clean test project that confirms the bug, could you please do the community a huge favor and submit it to support as an official ticket?
Also, I noticed that when I had a fully loaded project (it was almost finished), the initial glitch and the loss of the next clap's transient actually got slightly more/bigger. I can't say for sure if it's caused by a PDC error, but something was definitely adding to that delay.