PreSonus Forums

We now have a correlation and can pursue this!
Thanks for your persistence Sabastian.

jpettit wroteIt seems to keep your computer from going into low power mode or screen shutting off.
and might just be the core of the problem.

No, I do not think so. It is not probable. I have disabled all Windows power management and all processor states, speedsteps and turbo from the BIOS.

sebastianholtzer wrote...so yes...shaking that box really helps...

May I ask you something?
1. Are you sidechaining the Presonus Compressor(s) (not the Fat Channel) with a Send?
2. Is one or more Compressor(s) receiving more than one Source of a Sidechain Trigger?
3. Are you using a Noise Gate to trigger some Instruments?

I wanted to do a test with my song and removing them, because 1, 2 and 3 are the case here at my side and I think the Bug is in the DAW and it`s PlugIns and not somewhere else.

1. No, I am not using any Presonus plugins.
2. No, guitars only from lead vocals and overheads only from snare
3. I am not using any noise gates. It is possible though that the Console 1 gate is on in some channel.

This may suggest that the bug is in Studio One itself.

karismolander wrote

jpettit wroteIt seems to keep your computer from going into low power mode or screen shutting off.
and might just be the core of the problem.

No, I do not think so. It is not probable. I have disabled all Windows power management and all processor states, speedsteps and turbo from the BIOS.

Yes Karismolander is right. I`tuned my PC for Audio like he does.
Jpettit, the Rendering Process fell to sleep. Maybe it has it`s own Power Management

karismolander wrote

sebastianholtzer wrote...so yes...shaking that box really helps...

May I ask you something?
1. Are you sidechaining the Presonus Compressor(s) (not the Fat Channel) with a Send?
2. Is one or more Compressor(s) receiving more than one Source of a Sidechain Trigger?
3. Are you using a Noise Gate to trigger some Instruments?

I wanted to do a test with my song and removing them, because 1, 2 and 3 are the case here at my side and I think the Bug is in the DAW and it`s PlugIns and not somewhere else.

1. No, I am not using any Presonus plugins.
2. No, guitars only from lead vocals and overheads only from snare
3. I am not using any noise gates. It is possible though that the Console 1 gate is on in some channel.

This may suggest that the bug is in Studio One itself.

OK. Then i don`t need to do this test.
What the hell is wrong with this Programm? They really need to fix this.

karismolander wrote

jpettit wroteIt seems to keep your computer from going into low power mode or screen shutting off.
and might just be the core of the problem.

No, I do not think so. It is not probable. I have disabled all Windows power management and all processor states, speedsteps and turbo from the BIOS.

There are manu layers to this.
Did you not say touch moving or bring focus help you?
If so then we have two people with same behavior.
Correct?

jpettit wroteDid you not say touch moving or bring focus help you?
If so then we have two people with same behavior.
Correct?

Yes, exactly.

That is news breaking and has been reported to the developers.

I had the same problem with automation not printed in another song. I noticed that you actually do not need to move the render dialog. It is enough that you keep your mouse button down on the dialog. Then automation is printed.

I also noticed that when you keep the mouse button down, all VSTs in the screen are updated. For example Superior Drummer keeps progressing. When you do not move the dialog or do not have the mouse button down, the VSTs are not updated and ultimately the dialog freezes and automation is not printed.

I hope this will be fixed soon. This is really annoying.

The song had no sidechains. About 15 tracks, 7 buses, many Console 1s and a couple of Neutrons. Some reverbs and delays. Softube Tape MixFX. One VSTi, Superior 3, latest version. The latest Studio One.

karismolander wroteHere is an experiment that explains something, maybe.

I made a mixdown (mastering update) and constantly moved the position of the mixdown dialog.
The result: the automation worked exactly as it should have worked. All automation changes were recorded to the mastering file. Everything was fine. The dialog did not froze.

Then I made another mixdown (mastering update) without moving the mixdown dialog.
The result: The dialog froze in about 55% of progress, but the process completed after waiting. None of the automation changes were recorded. The track automated was silent.

This is really weird. Maybe you can now find the bug easier.

Hi karismolander, it sounds like from your test/observation, you're running into some buffer overflow, as things work up to a point, then fail.

I'm finding more and more with such exports, or even sending files to the Projects page, stemming, and other such unwanted behavior behind the curtain, that setting your buffer to maximum can often help. Just for that time, as latency wont ne an issue. Then change that buffer setting back to where you need it, later for other requirements. I know that sounds obvious, but when performing these tasks, if you run into such issues, set your buffer to Maximum. When doing so, even dropouts disappear, or such buffer overflow occurrences.

Also have a look in your metering and view all plugins. Sort by CPU, and just make sure there isn't some big draw (large percent figure) on any plugs. Determine if they're needed. Then change the buffer again if necessary, and check the results.

Possibly, when exporting, maybe Studio One could incorporate some feature, or option to switch buffer settings automatically, for the task at hand, such as when recording, playback, and exporting. Possibly even rendering to audio if the same issues arise.

One last thing. Check that you have no other processes running on your computer (anti-virus, streaming, etc,) and keep an eye on unnecessary background activity.
Hope this helps.

How is latency/audio interface buffer related to moving the export dialog? Makes no sense.
Lokefley, you have not read the thread.

With respect to "mixdown" as you've used that term throughout the the thread, my point of buffering simply helps accuracy of internal processing. Up until some point in time where automation curves, or dropouts/variences can hapoen. No, latency has no impact as I clearly mentioned, because a high buffer during mixing down will not be a concern (as apposed to real time use). Which you said real time playback was fine.

As to your OP:

I have problems with bus volume automation when updating the master file. I have a plain normal volume fader automation in one of my buses. The graph goes like -inf -> 0 -> -inf -> -1.4 -> 0 during my four minute song, i.e. there are four changes in the song. The first two work all right, but the second one does not show in the master file. In real time everything works fine, but master file update does not.

Is this a bug or is there something I do not understand?

Yeah, it is strange when you playback a master file and it is different (and certainly annoying) I'll simply say, at a cost of reiterating, that I've ironed out having the Master, or mixdown file with auromatuon changed, or dropouts by adjusting buffering.

Might even be similar to what Sebastian termed "shaking the box".

Also, check pre/post fade routings. This is why I mostly stem out mixdown, checking what is via track, and what is via channe, and pre/post fader selection.


Under most cases, all automation should print. It's when things work up to 50% to 80% (or potentially 3%), one has to check and ring things out. You've received some helpful hints.

Yes, I previously read the thread.

Keep up the investigation.

More variable must be involved.
I created a test file with 20 minutes of white noise a few Presonus plugins and a square wave automation and set my computer to bring up the screen saver in one minute. I could get not behavior to cause automation to fail.

It could be specific 3rd party or almost anything.

The elusive test song that more that one person can confirm has yet to be made.

karismolander wroteHere is an experiment that explains something, maybe.

I made a mixdown (mastering update) and constantly moved the position of the mixdown dialog.
The result: the automation worked exactly as it should have worked. All automation changes were recorded to the mastering file. Everything was fine. The dialog did not froze.

Then I made another mixdown (mastering update) without moving the mixdown dialog.
The result: The dialog froze in about 55% of progress, but the process completed after waiting. None of the automation changes were recorded. The track automated was silent.

This is really weird. Maybe you can now find the bug easier.

I'm a fairly new user to Studio One. I was a long time Sonar user but switched over when Gibson dumped them and support disappeared. Anyway, I'm having the exact same problem with automation not being written to my mixdowns. I saw this comment and gave it a try. It works every time. As long as I periodically move the mixdown dialog box the automation seems to get applied properly to the mixdown. Otherwise the dialog freezes at the half way point and the automation stops being written despite the mixdown process completing.

This was driving me insane as I would listen to my mix outside of the studio and many aspects of the mix would seem off. I would come back to the studio and it seemed fine when I was playing it back in real time. I really like Studio one but this is a major show stopper for me and I've lost confidence with this program. I really hope it gets fixed in the next update. Having to sit at my desk and move the mixdown dialog box is getting to get old fast.

Thank you to person who discovered the work around. You saved me a lot of time troubleshooting.

Eric

As said earlier. This workaround was given to the developers and they were amused, to say the least.
As of one year of trying to trace this down, no one has produced a simple ( transportable enough) song that can reliably demonstrate the issue.

I have tried for several hours and have failed.

Please persist in try to find a song to demonstrate this.

Until it can be replicated, it can't be fixed.

Wow! A year for this bug? That is so bad. Hard to believe they have not been able to reproduce this one in that time frame. It happens to me every time I try to render a mix. I will try some basic tests to see if I can narrow it down but I'm very discouraged by this.

I did a brief test by eliminating certain plugin groups. In this test it seemed Slate Digital Virtual Mix Rack on my channels is the culprit. As long as that plugin was present on my channels the mixdown dialogue froze resulting in failed automation reading from the point the dialogue froze. I took that plugin off my channels and it never failed. I'm using the VST2 version of the Slate plugin.

erichansen4 wroteI did a brief test by eliminating certain plugin groups. In this test it seemed Slate Digital Virtual Mix Rack on my channels is the culprit. As long as that plugin was present on my channels the mixdown dialogue froze resulting in failed automation reading from the point the dialogue froze. I took that plugin off my channels and it never failed. I'm using the VST2 version of the Slate plugin.

This is potentially great news! Did you try with the latest VMR, version 2?

Yes I have the latest version of the Slate plugins. It might be specific to the project I first tested with but not certain. I tried to replicate the problem with a new project (from the same template) with the same plugins and track count. I put 4 bars of audio, volume and pan automation on each track and cascaded through the tracks for 7.5 minutes. The mixdown dialogue kept freezing towards the end of each mixdown attempt but the automation did not fail in that series of tests. I rendered 7 mixdowns and may be worth mentioning some mixdowns did seem to have automation get a little out of sync with the project.

erichansen4 wroteYes I have the latest version of the Slate plugins. It might be specific to the project I first tested with but not certain. I tried to replicate the problem with a new project (from the same template) with the same plugins and track count. I put 4 bars of audio, volume and pan automation on each track and cascaded through the tracks for 7.5 minutes. The mixdown dialogue kept freezing towards the end of each mixdown attempt but the automation did not fail in that series of tests. I rendered 7 mixdowns and may be worth mentioning some mixdowns did seem to have automation get a little out of sync with the project.

Ouch! Sounds like a pain.

I think some people find it confusing assigning hardware controllers to VMR because of its modular nature. Could this be something that messes up automation as well? F.i. changing the sequence of VMR modules after the automation is written or something like that?