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.

My conclusion, after hours of testing: volume automation does not work in 3.5.6. or it works just occasionally. I have tried it in buses and tracks and only some have appeared in mixdowns or mastering updates. I have deleted and recreated automation envelopes.

In real time live playing it works exactly right. In mixdowns and mastering not. This is a total show stopper. I cannot complete my tasks.

Yeah! Welcome in da Club Does the Mixdown-Box freeze while you export the audio file? If yes, try to shake it to prevent freezing. Some Users had luck with this and it seems to help even me but i don`t use realtime rendering and i still notice some incorrect rendered things.Then i read that you should set your Device Block Size to the highest Size once you export PlugIns and Automations.And yes some threads seems to be locked. Thank you. I thought they banned me. Now i know i`m not alone.

Really? Yes, the box freezes in mixdown, in about 60%. Shake the dialog? And it is not April 1st any more. So this is a known bug and not fixed?This totally prevents me from finishing my task. The only way that I can think to go around this is to create extra tracks for each event with different volumes. Luckily I have only one and not so important gradual change in my volume fader. How do people use automation in lead vocal channels or buses, if needed? These are often complex and gradual.I wonder why these threads were locked and some even disabled. This is a serious bug.

There's not a lot to go off here but I did some quick tests on 10.12.6 Mac OS X, Studio One 3.5.6

I could not replicate the behavior you mentioned of Master Files not updating and Mixdowns not reflecting Bus Volume Automation or Track Volume Automation.

It's likely that either the forum or Support will need more information on your individual situation and operational flow before anyone can duplicate what you're seeing. If the actual mixdown isn't reflecting your automation it might be productive to start with that. Can you show your routing in your mixer and your export mixdown settings?

My steps that produced a normal result, for reference:

1. create a project from a template2. create an audio track with a test tone lined up at -6 db3. loop this for 24 bars4. put the end marker at 24 bars5. assign the audio track to a bus6. automate the volume on the bus.7. Song -> Add to Project -> New Project

Here, the Project reflects the automation accurately

8. Went to the song9. Made an adjustment to the bus automation10. Made an adjustment to the audio track volume automation11. Song -> Update Mastering File12. Navigate to the Project

Here, the Project reflects the automation accurately

13. Go back to the song14. Make changes to the bus and track volume automation15. Navigate back to the project16. Update Mastering Files from the Project window

Here, the Project reflects the automation accurately

17. Go back to the song18. Export Mixdown between Start and End markers with "Import to Track" selected.19. Imported Mixdown accurately reflects the automation.

Last edited by robertgray3 on Mon Apr 02, 2018 12:11 pm, edited 1 time in total.

I have about 20 tracks, three VST synths, Superior 3, ten buses, 2 FX buses, Console 1 in each bus and channels, two sidechains, 1-5 plugins in each track and bus, Softube Tape MixFX with passthrough, a couple of normal tape plugins. How can I or you replicate this exactly? Creating this project has taken lots of hours. This is a complex project, but it can run easily in my Xeon with 128 sample buffer (MOTU 828ES).

karismolander wroteI have about 20 tracks, three VST synths, Superior 3, ten buses, 2 FX buses, Console 1 in each bus and channels, two sidechains, 1-5 plugins in each track and bus, Softube Tape MixFX with passthrough, a couple of normal tape plugins. How can I or you replicate this exactly? Creating this project has taken lots of hours. This is a complex project, but it can run easily in my Xeon with 128 sample buffer (MOTU 828ES).

Bummer was hoping for a simpler case.

You will have to take smaller steps to workaround the issue like pre bouncing tracks or sections.

When you have time Sabastian is tracking down a trail on the side-chain as a possible cause to the issue.

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.

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.

That’s super weird! I still suspect support will want to look at the .song file to see how the project is routed and what effects are on what channels/buses. If you can save a backup of the affected song file and send it to Support when you have more time after the project that would probably be best. If routing plays a role in this it could offer much more information.

I’ve seen people post about this before but I haven’t seen a lot of confirmation that people sent their .song files to Support. That’s probably how it will get solved, just a thought. Anyhow thanks for posting about it

To the OP,Your spec's would help. Please create a signature* with your PC, SW and HW specs and versions, so we know how to better help you... now and in the future.See mine or another users at the *bottom of their posts for an example.You can create one in your User Profile.

I will post my specs when I have time. I have Windows 10, Xeon E3-1231 V3, Asus Z97-A, 8 Gb, couple of terabytes hard disk, MOTU 828ES.S1 runs fine the song in real time, without glitches.Actually in my latest experiments the VSTi:s, except Superior 3 were disabled.I really have optimized my PC. I am an experienced software professional and I know what I do. I have built my own pc:s for the last 25 years.

If real time playing works without glitches, why asynchronous rendering does not? That does not make sense at all.

The gist that I've gotten from the previous posts on this is that it is a complex issue that isn't as simple as the CPU being heavily taxed. There's a lot of data on how the session is setup that will help Support in the .song file, that'll hopefully clear some things up- hope you get it sorted out karismolander.

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.

Yes, Sabastian has found this out as well.

He calls it "shaking the box"It seems to keep your computer from going into low power mode or screen shutting off.and might just be the core of the problem.

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.

...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.

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.

Yes, Sabastian has found this out as well.

I read this somewhere in the forum here before. A guy was talking about that before i had this bug and i was reminding then. But that explains why I was so confused in the 3.5.5 thread when it worked a few times and then not. Think you remember.