Shibata wrote:If you want magic on lows, try to AlexB Thermionic Phoenix Mix Compressor with Siemens tubes. Copy preset from 3 to 5 times or by taste. But not compress. Important thing - nebula internal buffer, must be 128 and youre audio buffer the same or lower.
I've found that for colour and for that hardware sound, work best not pre's but full chain eq, built in the position, when all bands with ND go first and the last band is HQ. Especially nice sound in that chain the M****y massive passive from Alex and all his eq as well. Very good alternative to pre is Tim's Gyrator, because its dynamic and there famous Marinair transistors, which was on old N**e 1073. The most profit from that sound is 96k version ( even with SR ) and 128 nebula buffer. But is very heavy on CPU.
Why would a shorter Nebula buffer increase sound quality?
Because the engine render it with more resolution. And this can be seen by how render in reaper the waveform. At 8192 it do fast and at 128 it do slowest and of course it use more CPU. Higher buffer lacks the transient because of latency of the buffer and the latency compensate not work due to nebula engine. And it is easy to prove.
http://i.imgur.com/xBUTcbW.jpg?1 You see three files. One rendered with 8192 internal buffer and 128 audio card buffer. Second with 128/128. And the last is phase inverse difference between them and than normalized. You may here how much signal is gone at the 8192 buffer. And now imagine, how much you lose at mixing stage with lot of tracks.
I use 128 buffer on every tipe of nebula with the exception of reverbs and delays, which is better to put 8192 due to long kernels.
Yes the 128 eating much more CPU, but the sound worth it. Following this logic, if nebula had the lower buffer than 128, let us say 32, like on RME cards, this was even more precise emulation, but killer on CPU. Even so I would like to have than kind of opportunity.
Guys, I can help a little here. When using dynamic sampling, the internal program rate will effect the changes between samples. If the developer set the internal prog rate of the preset low(this is not the prog rate of master page), the buffer is likely to effect the overall prog speed when it is set higher, it's a latency rule introduced by freqd kernal player. At the top of the screen in KERN PAGE nebula you can see something called RTE, this is the rate the preset is working at at that current time. If you play with the buffer, you may see that number shift, this will have an effect on rate between all sample changes, including knob adjustments. Edit- I'm not sure but zl version I believe buff will not effect prog rate but I have not tested.
This is why some of us use timed mode for compressors for more real time changes and buffer will not effect program rate in timed mode. As a side note I worry that users may tweak something and knock a emulation out of spec. As a disclaimer, It's best to check with the dev if it's safe to change any settings on master page etc. In the case of GYRATOR eq, I had on purpose set the internal prog rate low, it's fairly safe to play with buffer and it is likely to sound better with those lower buffers, your CPU will suffer though.
Last edited by Tim Petherick on Mon Jun 13, 2016 3:07 pm, edited 3 times in total.
hey shibata, do you so the Same dsp Buffer Procedere for aquas? i'm a Little bit confused about Sound Quality dependent on dsp Buffer Settings ? giancarlo, can you confirm?
No i am not testing aqua, i don't like how the library sounds on it, though this is the same nebula in GUI and N4 features. Maybe it's a bad choice of sampled units or bad signal path ( converters, hands) _) duno, but i always return to 3rd party libraries. If I'm not mistaken, the default buffer in aqua is 1024, and you can change it by xml file. However, there are Z markered preset which means zero latency, but i never use it and can not say anything about them.
The buffer by itself not downgrade the sound quality. It's like a discrete processing. Because RTE in kernel page is larger when the buffer is higher. Look at this: http://i.imgur.com/kycxvJQ.jpg
During the rendering it miss part of the signal due to that difference between 2.902 and 23.21 and i don't know why latency compensate not work in this situation. Perhaps the case in the engine architecture.
By the way. Remember old holywar on forum between which engine sound better: timed or freqd? So here, if you set the buffer 8192 with 23.21 ms RTE ( don't forget save and reload preset after change ) and than switch all kernels to timed engine you'll get even faster RTE 1.995 ms. http://i.imgur.com/fRigtYM.jpg
So possibly its the answer why timed is better. But on CPU its crazy. So 2.902 ms not bad choise, though 1.995ms theoretically it render all transients better, especially in a mix stage where many nebula instance and cumulative effect more evident.
Hey Tim, I have a habit of changing the buffer to the max setting, 8192, in all my acquas and it's set that way in Nebula. My processor can handle things better that way... But if you're telling me it's effecting processes in a detrimental way, I suppose I should set it back to the original setting to get accurate emulations of said hardware. Yes?
waffleneck wrote:Hey Tim, I have a habit of changing the buffer to the max setting, 8192, in all my acquas and it's set that way in Nebula. My processor can handle things better that way... But if you're telling me it's effecting processes in a detrimental way, I suppose I should set it back to the original setting to get accurate emulations of said hardware. Yes?
You right, higher buffer less CPU ( more RTE ), but lower render "resolution". But you can change to timed mode and buffer does not make sense - you'll get lowest RTE and highest CPU. Listen the file: phase inverse difference and you hear what part of signal you lost. https://dropmefiles.com/qan3P
Hi shibata. Hope you don't mind me adding.....I don't recommend going to timed mode for eqs I've made because all the fades could change and kernal lengths change and also it can effect distortions produced by speed of sample changes etc etc , potentially a lot of synergistic effects and knock on effects that come into play. In other words the library's were tested with only buffer changes kept in mind as a user tweak, I don't support any other changes unless otherwise stated on on a product page, for example my phasers called for a specific setup. I really recommend sticking with the stock settings of that preset and I'd say find a balance that works for user with a buffer setting, work flow vs what's heard for changing buffer. At this time For my stuff I find using 512-1024 is perfect balance for me, unless it's something like reverb which needs to be higher. Regarding what other dev's have released: I can't give out blanket advice for all emulations other than my own, I cannot speak for them