Volume Automation - gremlins and inconsistencies

[parityflux]

I am doing a sound remix on a documentary and I am having difficulties with the mix automation. I have lost confidence in the project file because of the rendering problems I am having. It really feels like a bug, but I haven't reported it yet. Here is my sub-mix and final mix busses:

For my testing I am only exporting FullMix as a stem. I have two very apparent problems, which also leads me to be suspicious of the rest of the mix:
1) There is a final fade-out on the Music sub-bus (MX sub). It gets rendered correctly if I export the last 20 seconds of the program. It does not get rendered correctly if I render the whole program (10 minutes). The end just cuts off. For all of my projects I render using the start-end loop points. I confirmed numerous times that I am not cutting anything off.
2) There is a section in the middle of the piece where the volume automation on the MX sub simply doesn't render. The music is under dialog and if I render the full stem, this section is way too loud. If I select a loop range just in this area, the exported stem is normal.

Things I have tried to seek out the root cause:
1) removed all VCAs (there were a few and I think only 1 was automated)
2) turned all effects off
3) transformed audio tracks that had elastique time-stretching (and some RX11 ARA) into rendered tracks.
4) rendered the MX sub as a stem (segment correct, full 10m length incorrect)

The project itself isn't all that intense. It barely touches my CPU even with low buffers and all effects on. At this point it is all audio (I rendered a few VSTs that I had for sfx).

Has anyone come across this, or have ideas about what might be wrong?

 

[Trucky]

Need more details...
Please post screenshots... automation on MX sub (include routing details), markers and your stem export settings?

 

[js1]

One thing to try is exporting in real time to see if that makes a difference. I had an issue some years ago where my export wasn't correct, but was OK if I exported in real time. Whatever the issue was, it got corrected, and regular exports have been fine for me.

FWIW, I do use a fair amount of automation, and haven't encountered your problem (at least, not yet).

 

[parityflux]

Need more details...
Please post screenshots... automation on MX sub (include routing details), markers and your stem export settings?

OK. I don't know if any of this will explain the issue of it working for segment and not working for the full duration, but at least you will some context:

music bus volume

transport range (hh:mm:ss:ff)

start point (MX fade in not too important here, as the source music stems have their own volume automation)

end point

export dialog

 

[parityflux]

One thing to try is exporting in real time to see if that makes a difference. I had an issue some years ago where my export wasn't correct, but was OK if I exported in real time. Whatever the issue was, it got corrected, and regular exports have been fine for me.

FWIW, I do use a fair amount of automation, and haven't encountered your problem (at least, not yet).

Great idea. I should have thought of this. Maybe subconsciously I didn't want to wait for a 10.5 minute render under deadline conditions. Rendering in realtime fixed both 1 and 2 of my original post. I think it's time to report a bug, because this shouldn't happen for such a simple project. Rendering barely touches the CPU. As expected, in rendering it again offline, the issue reappeared.

 

[Skap]

This sounds very similar to an issue reported on the old official forum about previous versions of S1. All those posts are unfortunately gone now as the forum got taken down, but I remember it happening to longer file exports and that some people used a work-around that weirdly seemed to fix the issue temporarily: while exporting the audio, try grabbing the export audio dialogue box with the mouse cursor and wiggle it around. I think the issue has been reported several times, but I don’t know if it’s been resolved. I can not remember seeing any notes of it in any of the many S1 updates since. Perhaps it’s time for a revisit?

P.S.: This issue and the issue with random muting of audio during playback (across several platforms and systems) are the main reasons why I still haven’t upgraded from version 3. Not that I couldn’t have gotten work done if I upgraded; it’s just me being me.

 

[ianaeillo]

Great idea. I should have thought of this. Maybe subconsciously I didn't want to wait for a 10.5 minute render under deadline conditions. Rendering in realtime fixed both 1 and 2 of my original post. I think it's time to report a bug, because this shouldn't happen for such a simple project. Rendering barely touches the CPU. As expected, in rendering it again offline, the issue reappeared.

Skap is right. This was an issue back in the day. Now I’m so paranoid I only mix in Realtime. I often mix full symphonic concert recordings so I try to embrace the 1.5 hour realtime bounces and solder some cables or replace a cap or two. Once got an entire eight channel TRS snake soldered during some slog of a Mahler piece. I know that isn’t like, impressively fast but it’s pretty good for me.

 

[dominicperry]

This needs fixing. Sending inaccurate mixdowns to a client is absolutely the way to reduce the status of a product from professional to hobbyist. It doesn't matter how many features a DAW has if it produces inconsistent mixes.

 

[parityflux]

[...], but I remember it happening to longer file exports and that some people used a work-around that weirdly seemed to fix the issue temporarily: while exporting the audio, try grabbing the export audio dialogue box with the mouse cursor and wiggle it around.

For real? What?? So now it's like a game of Twister. I will try that and if it doesn't work, I will wiggle the dialog while playing F# minor on my controller, and tap my sustain pedal twice, but not too fast and not too slow.

Seriously though, I will try shaking the dialog box into submission.

 

[parityflux]

A ticket was put in yesterday. Have not heard anything. We used to get acknowledgement emails. Will be patient as the team is small.

 

[lokeyfly]

OK. I don't know if any of this will explain the issue of it working for segment and not working for the full duration, but at least you will some context:

music bus volume
View attachment 2130

FWIW, From your example, the bus volume almost immediately jumps up quickly and drops the same at the end. That is fine, however I always, always leave plenty of lead in and out space at the begining and ends. This eliminates any misread of automation when stemming, or exporting a mix. It won't matter if the material is 10 minutes, or 10 seconds. It might be something worth trying. I've never ran across a stem or export issue or had real time or accelerated export, make a difference. However, particularly with the begining and close ramps (using grips) might cause a misread from automation if there's some conflict with cutoff points. For now, try a 5 second flat line at the begining, and the end. Then export, making sure your start and end markers are selected for the length and not the loop markers. Verify the start and end markers are out past the automation. If the ends are too long where there's silence, you can always trim that back. This would be sort of an extra protective try.
Also make certain nothing is running in the background, as I'm sure you do anyway.

 

[FMN-Music]

yes, I remember that issue, too. Never got fixed, because Presonus could not reproduce it.
One visual cue to look for was the freezing of the render window. When it froze, all Automation in the project was not rendered anymore from this point forward.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

In my case the song out of nowhere started this behavior.
It had the following things to be tru, otherwise the render would work fine again:
Render Time over 25 Minutes
Render Speed under 2x

 

[andgar]

Yes, I agree that it is absurd that this issue still exists many versions after being identified. The solution I use and that was advocated back on the old forum was to run the following script in AutoHotKey that automates the shaking of the window I just copied and used the below script as suggested. I don't know how it works, just that it does!

_________________

#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
; #Warn ; Enable warnings to assist with detecting common errors.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.


CoordMode, Mouse, Screen
Z:=0
Loop
{
Sleep, 10000
WinWait, Please wait... ahk_exe Studio One.exe
WinGetPos, X, Y,,, Please wait...
X:=X+100 ; coordinates for empty spot in window title bar
Y:=Y+15
Click, %X% %Y% 0 ;move to coordinates but don't click
Click, Down
If Z = 0
{
X:=X+5
Y:=Y+5
Z:=1
}
else
{
X:=X-5
Y:=Y-5
Z:=0
}
Click, %X% %Y% 0
Click, Up
}

 

[lokeyfly]

Skap is right. This was an issue back in the day. Now I’m so paranoid I only mix in Realtime. I often mix full symphonic concert recordings so I try to embrace the 1.5 hour realtime bounces and solder some cables or replace a cap or two. Once got an entire eight channel TRS snake soldered during some slog of a Mahler piece. I know that isn’t like, impressively fast but it’s pretty good for me.

I'd be careful of this. All too many responses and posts (not saying every) had a slew of varied complaints about rendering, and most specifically "drop outs" in the old forum. Only every kind of complaint included when bouncing, when stemming, or when mixing, and became a hodgepodge of "me too" reactions towards dropouts. Rarely if ever the same as the OP's actual issue. Yes, I remember the shaking the window box to fix some issue that was a plus ten minute export. It seemed to work in some situations by a couple of users.
Therefore, some have experienced this to whatever degree and thats, fine but some also are throwing out, how they cant believe this hasn't been fixed. Let's pose the question to Parityflux and see what they find first shall we. I'd hate to see this forum be about taking jabs at what hasn't been fixed yet (not you). Better to direct possible suggestions to the OP.

For real? What?? So now it's like a game of Twister. I will try that and if it doesn't work, I will wiggle the dialog while playing F# minor on my controller, and tap my sustain pedal twice, but not too fast and not too slow.

Seriously though, I will try shaking the dialog box into submission.

Yeah, try the box shake, but be aware as stated, Presonus couldn't duplicate the issue. Also check my earlier comments for addressing the start and end of automation out further. In any case, let us know your findings so that the best outcome can be passed on. Thanks.
Many here including myself dont experience this, even when rendering is accelerated. So it may be a rogue issue for some and is difficult to capture. But let's keep things in a troubleshoot fassion.
That will make for the best fix.
Let us know
Thx.

 

[ianaeillo]

I'd be careful of this. All too many responses and posts (not saying every) had a slew of varied complaints about rendering, and most specifically "drop outs" in the old forum. Only every kind of complaint included when bouncing, when stemming, or when mixing, and became a hodgepodge of "me too" reactions towards dropouts. Rarely if ever the same as the OP's actual issue. Yes, I remember the shaking the window box to fix some issue that was a plus ten minute export. It seemed to work in some situations by a couple of users.
Therefore, some have experienced this to whatever degree and thats, fine but some also are throwing out, how they cant believe this hasn't been fixed. Let's pose the question to Parityflux and see what they find first shall we. I'd hate to see this forum be about taking jabs at what hasn't been fixed yet (not you). Better to direct possible suggestions to the OP.

You are, of course, correct as usual James. I also *never experienced* the issue at the time. I was merely saying, hopefully with a bit of charm, that due to my reading of it being an issue, I became so paranoid of it occurring in an 80 minute recording with 26 tracks, 500 faded regions, and 300 automation moves, that I set a standard of realtime bouncing for *everything* I do for work while checking on the listen back for correct automation moves.

Edited to add: I *did* experience the dreaded audio dropouts but 7.2 knocked those out and I haven’t experienced a single one since.

 

[Skap]

I *did* experience the dreaded audio dropouts but 7.2 knocked those out and I haven’t experienced a single one since.

Thank you for posting this information, ianaeillo! I was not aware that the other issue with audio dropouts possibly was fixed. Very welcome news! Hope the automation issue will be fixed as well!

 

[parityflux]

Thanks for all of the useful comments and suggestions. Some of my tests and results:

• The Shake did not resolve the issue.
• Somewhere along my testing, I confirmed that all automation was affected, not just the MX bus. The dialog automation was subtle but needed for balancing. Because it was subtle it was hard to pick out that it stopped working at some point.
• Through addition of new pulsed and drastic volume automations, I was slowly able to isolate where the automation decided to quit and it was around 4:00 - 4:03. Each time I needed to do the full 10.5 minute render, as rendering small sections were usually fine.
• There weren't any automation points in the 4:00 - 4:03 area, but there was straight-line interpolation (typical anyway).
• Tech Support asked me to start a new song and use "Import Song Data". I was able to do that, and the issue was still present.
• When scouring the isolated area, I was looking at all tracks for anything unusual. I noticed there were 14 disabled mono audio tracks. [see below image]. Two of them had automation, and only one was set to Read mode. These tracks were my storage because they were from the original AAF file import from the film editor (Adobe Premier Pro in this case). I kept them around in case I needed to do comparisons while I worked. I did and they were quite useful actually. I always have them set to disabled, unless I need them for reference. I deleted all of these tracks and the original issue went away. This was highly repeatable.
• I tried to narrow down the cause by tracks, but it was somewhat chaotic. e.g. removing the first 5 tracks caused all audio render (in the printed stem) to cease somewhere around the 09:50 mark. Removing the last 5 of these disable tracks resulted in resolution of original problem 2 but not 1, the final fade out. I did not pursue a track by track culling at this point. I had already spent 5 hours running tests and at this point I concluded I had done all I could. There is nothing in the _AAF import tracks that I felt I could examine further. Besides, they were DISABLED.

I am reporting back to Tech.

Best,
John

 

[lokeyfly]

Good attempt and info on trying to disect the issue, parityflux
Just a thought....

• ........I noticed there were 14 disabled mono audio tracks. [see below image]. Two of them had automation, and only one was set to Read mode. These tracks were my storage because they were from the original AAF file import from the film editor (Adobe Premier Pro in this case). I kept them around in case I needed to do comparisons while I worked. I did and they were quite useful actually. I always have them set to disabled, unless I need them for reference. I deleted all of these tracks and the original issue went away. This was highly repeatable.

This makes for some curious but possibly valuable info or leads. I wonder if you had sone overuse of swap files where your ram was being off loaded onto them. After so many minutes rendering, and even a mostly full drive, this can cause issues. I take it, you have plenty of drive space?

• I tried to narrow down the cause by tracks, but it was somewhat chaotic. e.g. removing the first 5 tracks caused all audio render (in the printed stem) to cease somewhere around the 09:50 mark. Removing the last 5 of these disable tracks resulted in resolution of original problem 2 but not 1, the final fade out. I did not pursue a track by track culling at this point. I had already spent 5 hours running tests and at this point I concluded I had done all I could. There is nothing in the _AAF import tracks that I felt I could examine further. Besides, they were DISABLED.

I am reporting back to Tech.

I'd recommend another option, John.
Removing some first or last five might make some progress, but I'd instead recommend determine what tracks are drawing the most CPU. By clicking on the CPU bar along the transport par, then select to show all plugins.
Then click the percentage column twice so that the highest CPU percentages are at the top. Then select a few of these (whatever they are, be it plugins, or instruments) so that they turn off (gray). Try selecting the top Three to turn off. Now export and see what that does.

If by chance you are not experiencing high CPU in the first place, it may not matter. On the other hand, if rendering causes something to build up after those four minutes you were seeing an export fail, it just might be part of the problem.
Its what I would try. Just a suggestion. : )

 

[parityflux]

[...]
I'd recommend another option, John.
Removing some first or last five might make some progress, but I'd instead recommend determine what tracks are drawing the most CPU. By clicking on the CPU bar along the transport par, then select to show all plugins.
Then click the percentage column twice so that the highest CPU percentages are at the top. Then select a few of these (whatever they are, be it plugins, or instruments) so that they turn off (gray). Try selecting the top Three to turn off. Now export and see what that does.

If by chance you are not experiencing high CPU in the first place, it may not matter. On the other hand, if rendering causes something to build up after those four minutes you were seeing an export fail, it just might be part of the problem.
Its what I would try. Just a suggestion. : )

Thanks for the thoughtful response. I appreciate you. I ran a lot of tests with all plugins turned off; however, I will double check via a few render tests this coming week. My CPU is at 25% with all plugins enabled and a buffer of 256, but when I was doing all the mixing I was running at 2048 and the needle was barely moving: lots of CPU headroom. I might run a test or two after deleting the small handful of the higher CPU-use plugins (deleting rather than disabling). Still working with tech support as time permits.

 

[lokeyfly]

Ok, CPU down. Thought I'd throw that out there. Only because its happened to me at times where I was abusing my resources. It was an easy fix and I'd resolve the issue that way. Yeah, let us know how it works out. Hoping the fix is quick, and easy.
James