Little note about compressors, myths and issues
Let's start with 2 little notes,
- don't change PROG RATE in MAST page unless you know exactly what you are doing. If you change PROG RATE after you loaded the compressor you COULD (it will be explained later) change the internal PROG RATE. It means the compressor will react in a faster way but the sound will change, and in a way not expected or tested by the developer. This concept will be explained below
- If a compressor program is based on RAWFUNS (latest compressor releases) you'll have a different behaviour in Nebula CoreII and Nebula CoreI. Nebula CoreII is adopted in Nebula pro and Nebula Server edition. Nebula CoreI is adopted in Nebula2 and Nebula3. Here main differences:
CoreI: times will could be tuned manually and they are not sampled. If internal mode is RMS 17 you'll have strange attack and release times compared with other software compressors. Latest nebula releases support mode EVF 17. You could tune it directly in EVF page of nebula (push EDIT). Times should match other software compressors now. Anyway let's clarify a point: it will not sound better or worse just because times, times are a convention. Anyway it will sound slighly different even if you tune similar attack and release times using your ears because in RMS 17 inputs are squared, and it doesn't happen in other software compressors or EVF 17 mode.
Myth-buster 1: adopting a different EVF mode nebula will not be faster, nebula will not detect transients in a better way, it will not fix ringing distortion when you process audio rich of low frequencies. Simply timings will be respected. NOTHING more.
Myth-buster 2: it's not true that tuning something magic in nebula you could fix all compressor issues. You could fix something loosing something else. It depends on what you are trying to fix. The golden rule in nebula, use what works, don't try to convert an horse to a dog. Sometimes the limitation is not hardware specific, but introduced by nebula. In such case be clever: if you like the sound try to use a different compressor (even from an other manufacturer) and add nebula later for the 3d effect or the color or the sense of spaceness. There are so many stock plugins with a nice transfer curve around, don't pretend nebula is the solution for compressing a bottom drum, because it will not work(described below).
Case 1: you don't have the proper attack or release time directly from nebula interface.
Solution: it could be a limitation introduced by the developer in CoreII, check the user manual. Change compressor if you need something different. In CoreI you could dial times in a prefixed range, and everything should be allowed.
Case 2: you dial a proper attack or release time but nebula is slow or it doesnt' detect the transient in time. It happens in general because the PROG RATE is high. You could force PROG RATE to a smaller value (faster), but before doing it think twice. The slow PROG RATE is there for getting a smooth compression and ringing/aliasing-free effect. And for playing the whole kernel length, so it's a piece of the sound. Use a different compressor based on a faster PROG RATE before starting converting an horse to a dog. For sure the developer didn't test your new PROG RATE setting you are using. You could introduce noise, artefacts... so think about it.
Case 3: you hear ringing artefacts. In general it happens when the source is rich of low content frequencies, for example a bassline. In most commercial compressor you don't hear it because the envelope follower is measuring an high-passed source. You can emulate it using sidechain and an high pass filter before the sidechain input. If you can't fix it, change compressor preset as usually. If you want to experiment, read this charapter further, but please try to understand and test things before addressing new questions. When you ask something in our forum other uses who didn't read this note or didn't test your exact procedure could be confused by your questions and by the direct answer.
If PROG RATE is big enough (for example 20 milliseconds) and it's based on SMOOTH 2 (there are 2 players for H1 in KERN page) you could tune a different algorithm in EDIT/GLOBAL page of nebula, SMOOTH item. You select a different function for crossfading between kernels switches (it will be explained below). It affects only the way a block of samples is mixed with next block of samples. Anyway do it only if you are expert, or you want to fix a perfect preset you can't live without it. This is something for experts. It will not affect harmonic distortion, it will not affect frequency response, it will not affect compression. On the contrary, it will affect alising, ringing. Compressor could be slighly more responsive simply because each block is merged with next block in a different way, so a new peak could appear slighly anticipated (think to audio: if you have 2 pieces of audio and you are crossfading them, if you change the fade algo you could see the new event "before" or "later").
and now a bit of theory, HOW COMPRESSORS WORK IN NEBULA
In almost software compressors for each incoming sample there is a gain changement. It means it's accurate, for example you don't miss accuracy on transients. If there is oversampling it will be even more accurate and aliasing will be reduced accordingly.
Ok, nebula doesn't work in this way. If you need it, nebula is not for you. Probably you are not satisfied by commercial compressors, otherwise you would not try using nebula for compression. Don't ask continuously for fixes or updates in our forum, saying we should be faster or quicker, or assigning a different priority to our developements. We are continuously improving the engine and trying to fix issues introduced by our different approach, we are perfectly aware about pros and cons of our engine. What's important to understand, Nebula works in a different way than other tools. Which could be better sometimes, and worse sometimes. Being the only software with a different approach, you'll achieve things in nebula which are not possible using other software compressors and viceversa. The sooner you understand it, the better it will be, so you'll enjoying results.
Here the first fact: Nebula processes BLOCKS of samples. It doesn't process blocks just because the patent on F*******e products, or because computers are still slow. It processes blocks because it tries to be ACCURATE on sound,on both the frequency and harmonic content and switching the kernel context too much often could lead to other unwanted effects, for example ringing noise or a fake sound. We try to be accurate on the sound, so we go SLOW and we try to mix the next event minimizing distortion, because distortion is already reproduced by the engine which plays directly harmonics.
How many blocks of samples? this is the PROG RATE value. Please note that PROG RATE is a parameter FIXED by the library developer. Here a golden rule, so you'll understand why it's so important:
1) fast PROG RATE means that your compressor will react in a faster way. If you have a PROG RATE of a single sample you have exactly the speedness of a common software compressor. BUT please keep in mind: you can't have in nebula something working if you go too much fast unless kernels are short. Very short. How much short? a single sample if you want such speedness. SO a nonsense. You would use nebula introducing all issues of nebula and adding artefacts, noise, aliasing...
2) slow PROG RATE means that compressors will react in a slower way. It means less clipping issues, artefacts, troubles, but you could start processing sound later, and a transient could not be processed correctly (so you hear something loud at the beginning because compression is not engaged yet). On the other side you loose something but you gain something, which is the sound. When PROG RATE is slow you could reproduce the whole kernel lenght. It means accuracy of harmonic distortion and accuracy of frequency response.
Now there are 2 possible types of compressor in nebula. Nebula could see "ahead" around 1.5 milliseconds. It means that when PROG RATE is around 2 milliseconds you will be pretty there. When PROG RATE is around 20 milliseconds you'll be "late" of about 18 milliseconds.
But remember: you can't have both of them. The faster, the less accurate and less color, but a more standard compressor effect. The slower means you'll be accurate from the color point of view, but you'll loose something on the dynamic side.
So the question: I can't do it using that compressor xx but not using compressor yy is a consequence of that.
Officially Licensed 3rd Party Developer Libraries
Free 3rd Party Programs
Free 3rd Party Programs
1 post • Page 1 of 1