TW: "After years of developing libraries, i've personally decided that TIMED mode, while using far more CPU, does not, in itself, sound better than FREQD. it was always assumed by many that it is superior quality-wise. My view now is that timed mode is only superior in that it allows for faster program rates. Freqd mode forces you to use larger/slower ones. Faster program rates means that the program can respond to dynamics quicker and more accurately in some cases.
But you shouldn't ever just switch to timed mode and set a faster program rate. Faster program rates lead to artifacts, unless you know what you're doing. The faster program rate won't even matter much or at all anyway if the program is using an RMS style envelope follower.
So ultimately, I recommend leaving this stuff alone. In my older manuals I may have tips saying you can switch to timed mode before rendering, but now i don't believe there's any point. the only benefit to doing this is from a dev who knows what they're doing and has timed mode set up with a proper program rate that won't lead to artifacts. This is stuff the end user shouldn't be thinking about, worrying about, stressing about, or messing with, in my opinion.
Splith mode is a special mode that uses timed for the first couple ms of the impulse then uses freqd for the rest. It was made under the assumption that timed mode inherently sounds better, which as i just said, I don't personally agree with. So in my opinion, splith mode is pointless, because it doesn't allow for faster prog rates. It's not even meant for dynamic programs anyway, it was intended for things like equalizer programs which are almost always (99.9% of the time), non-dynamic. If someone wants to disagree with that, ok, but I'd love to see a double blind test where anyone can tell the difference between something rendered with timed mode vs freqd vs splith mode, all using the same program rate. That's never going to happen. My SHQ programs have used timed mode to take advantage of faster prog rates or they have longer kern lengths (or both). They aren't just about using timed mode."
TW: "This is something else that people should really just leave alone. The dev should be responsible for setting this correctly. Although, it is true that an impulse less than 80ms long will create distortions in the frequency response. But if you increase this with a kern using freqd, the program rate will eventually go up, which throws off the dynamic action of the program. You could safely increase from 50ms to 80ms as long as the program rate doesn't change, and that will improve the bass response below 100hz, with no ill effects. As long as the prog rate doesn't change, that's the only case where i can say anyone should even consider messing with kern lengths. Well, there is one other- with reverbs. Although, in my opinion, nebula should have the ability to adjust the reverb lengths and apply fades right in the main program controls instead of forcing you to go to the kern page. It's not possible though, so I can't put that kind of control in my programs. Acustica would have to update Nebula to allow for this basic ability in reverb programs. Some of my reverb releases do have a fade control that shortens and fades at the same time but it's very CPU inefficient because I had to use a sneaky workaround. It'd be 100x better if Acustica made these controls possible in reverb programs directly. Using the kern length on the kern page to do it is pretty clunky and terrible."
TW: " Well, this one isn't really a question. The meters are hard to get right, and the devs all have to try to figure this stuff out on their own. If you want better meters ask Acustica to help devs make better meters. Of course acqua plugs have better meters, they know more about the system. I think my compressor meters have improved with each release."
TW: "you don't have to do anything except what sounds good. Not every program or library is made to the same exact standard, and even if they were, not every piece of gear that gets sampled is designed to that standard either. Some gear sounds better with different input levels. That's why i put a 'trim' control in all of my dynamic programs (besides comps where threshold is what matters). So you can adjust that, and listen, and get the input level right where it sounds best. Other than that i guess just try to follow the suggestion of the dev who made the library you're using."
TW: "I can't speak for anyone else, but i put a lot of effort into my manuals and i think they answer most questions anyone could have about my programs. I don't get enough support or money out of this to put in the effort that i put into this, let alone putting in even more effort making videos to show how to use a reverb or compressor. I think a lot of people are overthinking this stuff. If you can't figure out how to use the compressor program, you need to read about compressors, look at the manual, or send me an email if you have a specific question. It seems like people think there is some magical sweet spot where they set the controls and/or the levels and they will get the super best results or something. No. You just use your ears and adjust the controls, like anything else. If something is actually murky in one of my programs, email me and ask."
TW: "I don't really feel like this is my question to answer. I'm a 3rd party dev. Nebula is made by Acustica. They put it out and charge money for it, they should answer this kind of question. BUT if someone emails me with a specific problem about this kind of thing, I'll still try to help, and if I can't I'll tell them to email Acustica. My libraries cost a tiny fraction of the price of N4 itself. I can't be expected to provide technical answers or support with the overall platform, if there are issues with it that don't only affect my programs."
TW: "I don't sample things like consoles and rarely do things like preamps so i don't feel like this question pertains to me very much. But again my answer would be to use your ears and if the program has a trim control adjust that until it sounds good. I just think trying to come up with some blanket approach to apply to every nebula program out there or even released by one dev, to get the super best sound results seems kind of silly. But I'm guessing the info about the standards used during sampling is probably in the manuals of the console library releases out there. Maybe you start to notice that hitting a certain program or library at a certain input level sounds best, and you keep that in mind and always try to hit that program or library with that kind of input. To me that's what makes the most sense. I think people worry about it too much. Because here's a little secret - the way sampling in nebula works, the noise floor isn't nearly as much of an issue as it is in hardware. This makes gain staging less important when talking about lower levels leading to more noise, because in nebula it usually doesn't, nearly as much as with hardware. It depends on the library sampled though. You CAN get a noisy program. But most devs don't sample down low enough for it to be an issue in the programs like it could be with hardware. That means the upper dynamic levels leading to more grit or smashing is all you really worry about and I really think you need to use your ears there."
TW: "OK, so i have a lot to say about this one. May seem defensive or whatever to some but here it is - I question that they could show so much more. I provide free demo programs for my compressors usually. Anyone familiar with the hardware can download those and compare themselves, directly. I don't know how many threads i've seen at gearslutz where someone posts a blind listening test between two ore more things, and you always have a sudden surge of a bunch of people posting, claiming they knew which was which all along, AFTER the person doing the test posts the answers to which was which. These people usually didn't put their guesses out there before the answers were posted. I do my best to get as many of the details of my compressor programs working in-line with what i see in the hardware, after running extensive various types of test tones through both (and yes occasional musical audio comparisons, which are a lot less useful to me as a dev than the tones are). I really just don't think that your average person is ever going to notice the more subtle things, and the more obvious things are either there or they aren't. And if they aren't, people will probably say that in the forum thread where i'm selling my product. Either way I'm probably not going to make anywhere near the money to justify having spent the insane amount of time I spent making the thing, and I'm almost certain having these extra clips won't bring me any closer. If I ever came remotely close to making the kind of money that an actual plug-in developer like at UAD made, I would be sure to make the presentation around my products that much more professional. Then i could hire someone else to do all that stuff (and write my manuals which I probably also put too much effort/time into, considering how much i make off of this stuff) so i don't have to waste my time doing it. As it is i try to focus more on making the programs themselves as good as possible. Probably more importantly - the audio clips i *do* provide on my site to demo the compressors, those are just really not fun for me to do. It's always the thing i look forward to least (i dread it). I've asked the community for audio that i could use to demo my products with *multiple* times over the years, often with no replies, or very, very little interest. I've even offered free libraries in exchange and still got minimal response! This really surprised me! It's hard to find suitable material to 'show off' a nebula program, and then to do it in a way that really highlights the strengths of the program. I can only imagine how much of a nightmare it would be to try to do clips that match a result from hardware as close as possible, and how time consuming. iI'm just doubtful that those extra hours doing those clips are going to be made up for by more sales. Another thing, those types of comparisons can be misleading. I could show you tone sweeps or clips that seem to demonstrate something good about my program but guess what? Maybe that behavior doesn't hold up in every situation like it would with the hardware. Maybe the moment you add more compression by lowering the threshold, that behavior I'm showing off starts to break down, unlike with the hardware. Because all a clip example or tone sweep image shows is one snapshot of one scenario. That can be manipulated to emphasize one situation where something works seemingly well, but maybe otherwise it doesn't. The best case would be for people to make their own comparisons but then they'd need access to the hardware too. I just think some of the marketing out there can be misleading and people shouldn't 100% trust something simply because of perfect 'laboratory condition' snapshots of tone sweeps or audio clip comparisons which can be finessed in probably countless ways."
TW: "I can't say for 100% certain but I really, really don't think the daw buffer would affect the sound at all. The plug-in buffer meaning the nebula buffer? The dspbuffer setting? I don't believe that directly affects the sound either. BUT if you are automating a sampled control, say it's a program like of a low pass filter that you can sweep, or a good example would be my 'bawling brat wah' release. Those have peak filters you can modulate by lfos in the programs, or envelope followers, but also there are manual programs for you to automate yourself. OK, in those types of cases, if you are automating something like that, or using your DAWS lfos to modulate that type of control, the dspbuffer setting for nebula (and maybe the workbuffer setting, im not sure), will affect the smoothness of that control movement. You want a lower buffer amount to get the smoothest action. But having a lower buffer amount increases CPU. Other than that i don't think sound is affected by any of these buffers, but i could be wrong. Another answer would be that this is a question for Acustica since they make Nebula."
TW: "Yeah. Unless you know what you're doing. Actually, program rates above that can and will, too. It usually stops being noticeable around 20ms. There are certain 'sweet spots' where it's lower than the settings just above or below that. But this is really something that end users just shouldn't be messing with, in my opinion."
TW: "I didn't make that program, so i can't answer about it specifically. But as I already mentioned, you need a length of around 70-80ms to get the most accurate frequency response. The difference can be very subtle though. It's usually more noticeable in the lower bass, below 100hz."
AA: "You can change the engine setting, but if you change them, the Acqua Effect plug-ins will not work correctly."
TW: "Really really really not a question for me, and a question for Acustica. but again in my opinion timed mode is no better by itself, and nobody is ever going to show that they can hear a difference in a blind test (with prog rates being equal)."
Nebula under the Hood