not sure if it’s just my setup (apollo 8 , 10 pro , i5 Mac 10.4.6) but I have noticed that when I work in a low buffer like 256k and export it takes ages, but when I have it set to 2048k the rendering or exporting of stems is much quicker. I can’t keep it on 2048k because of the latency but I was wondering is it possible to add a feature that when you click the export or render button cubase automatically changes from your current buffer setting temporarily to the maximum buffer then switches back after exporting or rendering has finished so you can carry on with the session.
thanks
I’d also like this - for the opposite reason 
I’d like to know all rendering is being done at a small buffer size in order to minimise issues with automation latency, and still be able to work in a high buffer size for mixing.
Is this a thing? Do you really hear audible differences by rendering/exporting a track with a buffer size of 256 and the same track with 2048? Or is it because you are using outboard gear?
Yup… and it’s not outboard related. Pretty much all VST FX/Instrument automation is affected by buffer size, as well as sidechain information being sent from one channel to another - this can seriously change the sound of a mix. When you have an automated filter plugin that closes then opens up bang on a kick drum, that extra latency can completely kill a transient. VST3 claims to have sample accurate automation - but it’s up to each individual manufacturer as to how they deal with this, so I wouldn’t trust that it is.
What would be your recommended buffer size for exporting be then?
If you have automation/routing that is highly time dependant like the example I mentioned, then the lowest possible, with Asio guard off (it’ll be sloooow to render though, comparatively). However - you might find the sound of the mix changes subtly in other ways when you change the buffer size/Asio guard setting (maybe for the better, maybe not), especially if it’s a busy mix with lots of live vsti’s, automation, heavy plugins and complex routing. I tend to avoid that kind of automation when working in Cubase now, if I need something like a fast tempo synced volume/filter effect I’ll use LFOtool, which handles it’s own timing internally, and I know that it will sound the same regardless of buffer size. When automating plugin bypass or dry/wet I just try to leave a bit of ‘grace room’ before the part is coming in, to give time for the effect to ‘kick in’ - not ideal, especially on a part that doesn’t have a break around the point you want to automate, but there we go.
Hmm… but shouldnt this then already be audible at playback at the same buffer size ?
And do you know if other daws have the same “issue”?
Yes it will be. If you are not HEARING any issues at the buffer size you are using, then there is no reason to be concerned… chances are you aren’t using any automation where the timing is critical by a few ms… most automation isn’t in my experience, and in fact, if you want your render to be the most accurate representation of what you’re hearing while mixing, then you should export at the same buffer size.
I believe Protools has 100% sample accurate automation, internally and with all plugins, but they have their own plugin standard, which is how this is possible. As far as I know, any VST2 plugin automation running in ANY host will have latency affected by the host buffer size. The way it affects things differs from one DAW to the next. There have been plenty of tests done on this. Here’s one - DAW v. Daw - Part 1: Automation and Fades
Search around and you’ll find more.
Maybe I’m missing something but since Cubase doesn’t set the buffer size in the first place (that happens in the software for your audio interface) it seems unlikely that it would be able to set a second different buffer size.
Well it could change the internal audio driver to ASIO just for the moment of export/render. After that the driver would be switched back to the standard audio driver. I see no problem there.
Why would you want to be using a non-ASIO driver unless you had no other choice - even then you’re still (always) using ASIO either via the Generic ASIO Driver or ASIO4ALL.
NVM, I thought the buffer size of the ASIO4ALL driver would be displayed in cubase internally in the device setup.
It is a bug if that happen. VST3_SDK has it’s audio and parameter data in a method called process() in AudioEffect.
There there is a paramQueue->getPoint() witch is the sample sample where the parameter should start to be applied.
I think it was the same for VST2. So it does not matter if it is 32 samples or milion sample. The plugin knows how to handle it.
VST2 plugin automation is absolutely NOT sample accurate, and IS affected by buffer size. VST3 automation purports to be sample accurate, but as you have just pointed out - it relies on correct implementation by the plugin developer, and I’ve read many reports of problems in this area.
+1 for this
I made a somewhat similar FR and was told by a Cubase rep that VST3s have sample accurate automation, but I think it could just be the native ones. On top of that, it’s not realistic for me, and I assume for most people, at this point to ditch VST2 entirely.
Seems to be a very awkward thing to do now when VST2 is obsoleted. Better to move on to VST3.
That doesn’t sound right. 2048 should be faster than 256, but not a lot faster. How much of a difference are you seeing?
It depends on the project, but I did some testing a few years ago.
Purely from memory, One project would render in 2m30s @ 32 buffer and 0m40s @ 2048.
I did post the results somewhere, may have been on GearSlutz.com
Automation accuracy is indeed a challenge to be aware of.
Yes, it depends entirely on what’s in the project. The projects I typically work on don’t show a huge difference. That’s why I’m asking keltech how much of a difference he is observing.
sorry for the late reply, about 1 -2 mins quicker from memory