giancarlo wrote:and no, nebula doesn't know if a program is static or not... even the cache engine is based on forecasts... if things don't change then it caches... it means a particular program could null... an other one not... you can't predict it and it doesn't mean anything; even a dynamic program could behave as a static program sometimes, ok?null tests = garbage
Is it correct to say that using a static preset, it doesn't really matter at what level you "hit" Nebula?
well, there are many examples around. For example for a particular setting you take let's say 30 samples, but you discover later than first 4-5 are wrong and you simply delete them. When you play nebula it happens that for most of time the behaviour is "static". This is just an example. Maybe you turn a knob a bit and it's dynamic, you move it again and it's static. You can't forecast what a developer or a program is doing... on the eq side we are sampling so many variables, that adding also the dynamic process could increase a lot the cpu load. Someone did it though.... In general static programs are ligher on cpu.... especially because nebula is not algorithmic so mixing 300 kernels in real time is not a joke. Using an algorithmic approach you could just move a bit here and there and you get something perfectly fake and dynamic. But in our case we are REALLY mixing kernels, they are MANY and the engine itself can't forecast the next state saving resources. When it happens it just saves resources and everyone is happy. An other useful thing, sometimes the developer is happy to NOT sample the dynamic effect again: for example you have a strip channel, and you want the dynamic effect and the static eq section separately, so you could add them in linear fascion getting a matched result. For example alexb is sampling the only "dynamic" (preamp" section alone), than he samples the eq section alone. The eq section alone maybe it's not dynamic by its own... so it would be a waste of time and resources to get them in dynamic mode. So there are many reasons. Nebula allows everything, and you can sample pretty everything. If you limit your variables you get something ligher on cpu side, ram usage and disk space.
I assume this static vs. dynamic difference you are discussing has nothing to do with input amplitude-dependence of the effect (i.e., kernel selection from input value), right? The difference you are discussing involves variation over time at a given amplitude?
[EDIT - never mind, you dealt with this question above.]
Last edited by biomuse on Sat Aug 13, 2011 8:24 am, edited 1 time in total.
Mercado_Negro wrote:I've read the whole thread and I think most people have mentioned and/or given advice for all possible solutions to this problem so, I'm afraid I have to say there's no problem at all but just wrong expectations about this library and what a preamp is supposed to sound like at nominal levels.
audioanal wrote: So console emulation makes a difference: the transients are a little compressed and the sound is more glued, crunchy and open (at least to my ears), the separation beetween instruments is more noticeable. This works for me. I love the sound when using this libraries. Cheers
@audioanal- can you give more details about your test: levels used/sample-rate/presets? the reason I'm asking is because I think your results are very interesting/important since they contradict the the general view of the console emulations. I've tried repeating your test with the MLC (in+out x2) and had very different results (slight emphasis of the transients- up(raw) down (Nebula) max peak -9dBFS (0vu) 96kHz:
I guess that different libraries make different results. I only inserted 1 nebula instance with the N**e 1084 line amp in every buss (6 instances), didn't touch input or output. Same levels. Simple test. Do you want me to make any new test? Cheers
Thanks, did you use 44kHz? if yes, could you repeat the test @96kHz, making sure you don't go above say -9dBFS (pre Nebula)? I'm wondering if this compression is related to the library, levels or something else (src bug for instance).
Edit: I repeated your test with 6x "1084 free K7" in a chain. Also this time the transients were slightly enhanced and not compressed. Used a 96kHz file for testing.