superhero81 wrote:My last question, when changing the TIMED KERNELS to 50ms and then bouncing down, do I have to save and exit? Or will changing the kernels take place right away?
No need to save. Clicking SAVE on the KERNEL page will save that particular program so that every time you open it, it will open with TIMED Kernels instead of FREQD (along with any other settings that you may have tweaked). If you have a 2048-core processor, you'll be fine. Otherwise, I'd recommend leaving it FREQD and not saving, and setting kernels to Timed right before you mixdown/bounce. Its a good habit to get into IMO
FORGOT TO MENTION Just making the TIMED Kernels 50ms won't turn them on. There are 3 little arrows between the TIMED and FREQD columns, one for the Clean (H1) kernel, one for the Even-order harmonic kernels, and one for the Odd-order harmonic kernels. It is also worth noting that using TIMED kernels for both Even and Odd harmonics is buggy and not recommended. I usually prefer the Clean and Even categories with TIMED, but sometimes Odd sounds better. Experiment to find what you like
Step 1. Make the TIMED kernels 50ms for CLEAN and EVEN Step 2. Click the middle arrows over next to CLEAN and EVEN Step 3. Enjoy your audio processed through Timed kernels
Sweet! Good info. Yeah I read an article and saw the video on youtube about changing to timed Kernels. So I am familiar with the arrows. The guy doing the tutorial suggested just changing the first arrow "Clean" to Timed Kernels? And leaving the other two at FREQ Or would I get better quality changing both "Clean" and "Even". He did mention Odd was very buggy!
superhero81 wrote:Sweet! Good info. Yeah I read an article and saw the video on youtube about changing to timed Kernels. So I am familiar with the arrows. The guy doing the tutorial suggested just changing the first arrow "Clean" to Timed Kernels? And leaving the other two at FREQ Or would I get better quality changing both "Clean" and "Even". He did mention Odd was very buggy!
TIMED on all players is going to get you better quality....
I've heard that too, about Odd kernels acting buggy. Personally, I have yet to experience that, but I've never tried using TIMED for all 3, and the times I've used Odd have been only using Odd and Clean.
The Odd kernels seem to give the audio more of a spacial feel as opposed to the Even giving a more supportive, weightier feel. Those words don't do it justice, but eh
From what I recall, the possible 'bug' was indicated when using both ODD and EVEN in TIMED mode. I can't say I could identify that issue, as switching to full TIMED mode quickly produced this pathetic 'whimpering' from my computer
ngarjuna wrote:Before you fall down the rabbit hole that is TIMED mode, here's my suggestion: ask someone who swears by TIMED mode being "higher quality" or "better sounding" to compare 2 audio samples, one in normal FREQD and one in TIMED. I've asked in several TIMED threads and in all the years I've seen this tweak nobody has ever delivered. Makes me wonder about this "miraculous" Nebula tweak that nobody has ever tried to demonstrate in their zeal to promote it on the forums. Personally I wouldn't suggest using Nebula libraries in ways other than their developers hand tweaked them (there are a few developers who produce TIMED programs; that is a different story, obviously, as you're running the program as its creator intended) unless you've heard (and prefer) the difference.
Further: if TIMED is so far superior to FREQD why haven't hardly any of the developers started using it for "High Quality" or "render quality" variants of their programs (I only know of 2 or 3 devs making TIMED programs)?
my take on the whole timed thing is, funnily enough, that i'm not so super sure that timed mode itself does sound so much better than freqd. i haven't made tons of comparisons just between the two modes. i say 'funnily enough' because i'm one of the devs releasing programs that i call 'shq' that use timed mode.
so what am i saying? well, here's the thing. in that transient thread you can see plenty of confusion and lots of it, in my opinion, is that you had plenty of people comparing the two modes, but they weren't making sure to ONLY compare the difference between the two modes. i pointed out a few times that you need to make sure there are no other variables changing, which could also affect the results, because otherwise you aren't comparing differences just between timed and freqd mode, you are comparing multiple things being changed. that's totally unscientific, and of course, it's not going to show anyone what differences may exist between the two modes.
the main example is that if you switch all or some kerns to timed mode, it can change the prog rate. this DOES have an effect on how nebula works, and this is just a simple fact. it dictates how often nebula can act on switching between samples based on the level coming in, for dynamic effects. any kind of program that has samples being interpolated between for any reason, not just dynamic ones, will also be affected. a 20ms program rate means nebula can only dictate changes between samples every 20ms.
so if you switch to timed mode, and program rate changes, now you are NOT just hearing differences between timed and freqd. you aren't. if you REALLY want to hear any differences between the two you will have to make sure to keep the program rate the same after the change. you can go into edit and glob and turn the 'rate s' parameter to on and then adjust 'rate' to match what it was in freqd. you'll have to do it that way because freqd can't have faster rates like timed can, so if a change happens when you switch to timed, it will be that the prog rate gets faster, and to really compare the two modes ONLY, you will have to increase the rate back to what it was before you switched.
you would have to render SEVERAL different clips in both modes, making sure to adjust the prog rate as i described after switching to timed, and then compare all those clips, to really get a good idea of a difference. here's why- ever notice how reverbs sound different every time you apply the same program's reverb to the same drum loop? if you have an identical drum loop repeating multiple times, the same snare may trigger the reverb differently each time it's hit. this has been a known thing and people have asked about it. know what that is? program rate. for reverbs it's even higher. in 44.1khz its all the way up to 180ms. 96khz i think its 80ms or so. reverbs are also dynamic. so what this means is that nebula is measuring the incoming audio's volume level to decide which dynamic reverb impulse to play, but it's averaging the measurements from blocks of 180 or 80ms (depending on the program rate), and then taking that value and using that to pick the dynamic sample. i'm simplifying a bit here but this is basically what happens. the problem with that is that those 180ms chunks are not in any way synchronized with your drum loop. this means that when the snare hits one time, it could be right at the front of a 180ms block, which means neb won't react to it for almost 180ms. so the appropriate dynamic step for that snare's level comes late. the next time, it may come right in the middle of a block, so neb's reaction will be sooner. that's why you get different results and that's why it's more noticeable with reverbs. the longer program rate means that you kind of get like a seemingly random reaction to each drum hit depending on where it falls in the program rate blocks, which are not synchronized to your project or anything.
SO, back to what i said earlier about comparing the two modes. i said if you want to compare whether timed mode itself sounds better than freqd, then you'd have to make sure to keep program rate the same. but there's another side to this. the fact that timed mode allows faster program rates (in fact you can adjust it to anything, no matter what the kern length is, unlike with freqd where program rate is tethered to the length), is, to me, it's biggest benefit.
faster possible program rates is something that you can't argue with as being little to no difference. if you do, you'd be just plain wrong. it's measurable, and it's visible by looking at waveforms rendered with slower vs faster program rates. it's going to be more important with some types of programs than with others. compressors act more consistently on the transients coming in, with a faster program rate. this is why the default compressor template/setup always has freqd kerns at 10ms, which allows a faster prog rate of ~2ms than preamp programs which load at 50ms and have a ~20ms program rate.
so with comps, faster program rates are needed to catch transients and play the appropriate dynamic samples which is where the compression comes from. with a typical preamp program (especially a solid state one), it's not going to make AS much of an important difference, because high end preamps are designed to give you very similar results at lower inputs as they do at higher ones, until you start clipping. tube stuff may change a bit more as your input gets hotter, and that may or may not be something you'd notice with a faster program rate compared to a slower one. the faster program rate would allow a more consistent catching of the transients to be colored by the higher level dynamic samples, but it still won't be as noticeable as with a compressor, unless there is a really heavy non-linear behavior in that tube pre and in the samples taken from it. i still think it can matter with preamps, but i'm just saying it's usually not AS noticeable as with compressors where it makes the difference between the comp compressing the transients more consistently.
i already talked about reverbs and there it would definitely be great to have faster program rates so that there would be a more consistent response to the input.
lastly, with an eq it barely matters at all. because vast overwhelming majority of EQ programs out there are not dynamic. they are totally static. so nothing is changing as audio goes into them. the only change happens when you adjust a band, and so the program rate would come into play there, but only WHILE you are adjusting it, and it only affects how smoothly the sound changes, which isn't really so important for normal eq purposes. if you are automating a control change then program rate would matter. but if you are just setting an eq and leaving it, program rate doesn't matter, as far as my understanding goes. there are no dynamic samples, so program rate has nothing to dictate there. this is one thing that kind of bugs me, to see people talking about transient response with regards to eqs. it doesn't make sense. because there are no dynamic samples (again there are a FEW exceptions, but as far as i know it's VERY few), so there is no envelope follower measuring the input level going into the eq program. i've even seen people talk about adjusting the detection type from RMS to EVF or whatever and getting better results with EQs. which can't be, because 99% of EQs do not USE the envelope follower/detector. the transients and everything else are just going into the eq, and getting a static convolution. a low level signal gets the same exact effect as a higher level one. sorry to say this, but none of the way the actual hardware eq affected the transients is actually translated into nebula. how could it be? the only way that happens is with dynamics. all a static program has is the frequency response and phase response, and harmonics. but the transient of a drum will get the same freq/phase/harmonics as the body of that drum, with static convolution. the transients are not handled any differently from anything else in the audio. if what i'm saying is akin to throwing a gauntlet down here, or going against things others have said, so be it. i'm not wrong about this.
but back to program rate. for me, it's the MAIN reason to use timed mode. it's why i do it. i could show you waveforms from a comp program with a slower vs faster prog rate and you could see how the transients are caught much less consistently with a slower rate. or you could do it yourself (which i'd prefer). the thing about it though, is that i do this as a DEV. nothing i've said here, is meant to be like 'hey guys check out this tweak you can make to your programs to make them better'. no. it's what *I* do to *MY* programs because i think it's a benefit for people willing to spend the extra time/cpu for render to get a more consistent result. and *possibly* a small benefit from timed mode itself sounding better than freqd (again i don't know about that so much, but it's less important to me than the prog rate change). the thing is, messing with this stuff gets into dangerous areas. you can cause lots of artifacts to happen. there are ways of minimizing them, though. different specific program rates are like 'sweet spots' where these artifacts are much lower, and by the way, they are always there, even with freqd. i've even seen cases where all kerns in timed mode resulted in FEWER artifacts than freqd. you really just have to experiment with lots of different factors to find a good spot where the sound is great, you have a good fast prog rate, and acceptable artifact levels.
basically what i'm saying is, all this stuff i've said about prog rate, in my opinion it's not something for end users to concern themselves over unless they have all kinds of time to experiment with the stuff. as a dev, i have that time. and one more thing- i understand that there are other devs out there making their own stuff, and there's always this statement of 'well they optimized it to work like it's supposed to'. so the stuff i say in this forum sometimes may come off like i'm saying that, well, if i'm talking about ways i think things can be improved, then how else will that come across? but here's the thing- i can't worry about that. i look for ways to get better results, and i think there is still room for improvement for ALL program types. so in my opinion, nobody's programs are perfectly optimized to be as close to the hardware as nebula allows. sorry. true fact. i think tons of programs out there still sound great though. but everything i said about program rate can be measured and proven. the only thing that calls the advantage of faster prog rates into question, the ONLY thing, is the danger of artifacts. i'll contend that my releases where i've given timed mode programs have acceptable artifact levels that will be imperceptible even with multiple processes, and not perceptibly worse than if the programs used freqd mode. but the benefit will likely be perceptible. with my comps that have 'shq', anyone should be able to hear a more consistent handling of the transients compared to the non shq versions, which is due to the program rate.
i really don't want any of this to come off like i'm trying to butt heads with anyone. but on the other hand i feel like i should be able to discuss thing i've done that i think are advances. and i feel the need to point this out, but with regard to that tired old statement of 'the devs set it to how it's supposed to work', that's not ALWAYS the case. i'm not going to say anything too specific here, but let me just point this out. i have plenty of libraries, and i can look at plenty of the preamp style programs i have, for example, and tell that they are using the default template for preamp programs. now, that's fine. it works. but it becomes a simple matter of fact, that if that default template (which was designed and provided by acustica) was used for that program, then that dev didn't do anything custom to that program. that's just how it works. either they did or they didn't. if they didn't, then phrases like 'they set it to how it should be to reflect the hardware' means nothing. because if the default template was used, they did nothing to that program to that end. so when i see people telling others that it's like sacrilege to adjust any program because the dev fine tuned it to be how it's supposed to, i have to laugh. because that isn't always the case, at all. from what i've seen, it usually isn't. acustica made the default templates. just using those doesn't constitute fine tuning a program to behave like hardware. it still gives a good result, which really is a testament to acustica and their forethought with this stuff. like i said, the compressor templates were set to only have 10ms lengths because giancarlo/acustica knew what they were doing and that they needed quicker program rates than with preamps programs. that was acustica designing a template to allow for compressors in general to be emulated better than the preamp template would allow. so anyone using that template can't take credit for that, unless they actually were involved in the development of that template, with acustica. all i'm saying here, is that if i can look at two different programs from two different devs, and glance at the kern page, prog rate, smooth type, FUN page, evf page, etc, and see the same exact stuff there, and recognize it as default template stuff, neither of those programs can be said to have been 'set to work like the hardware' by those devs. sorry. true fact. because the default compressor template may be better for compressors in general than the preamp template would be, but each hardware comp is different. the default template is generic. it's not geared towards a specific piece of equipment. two different compressors may behave totally differently, so how could use of the default template for both of them provide the most accurate results for both? if the default template is used (and often it is), then there is no customization on the part of the person using it. that's why it's called a template. it's really just that simple.
all i'm saying is that the sentiment some people express that you are treading on sacred ground if you adjust parameters in some of these programs is just bogus. i would ONLY even think of agreeing with that if i could see that that program ACTUALLY was customized in some way, and not using a default template provided by acustica. and i would be willing to bet that most programs out there are using those default templates. it's easy to check.
on the other hand, i don't think users should go prying around, messing with stuff, unless they know what they are doing or are willing to put LOTS of time into figuring it out. and unless they understand that they shouldn't save over the original versions unless they make backups first, and that if they get funky/bad results after modifying stuff, that's their own fault and they can't cry to the dev about it. and if they are putting that much time into experimenting with these things, they might as well be a dev, because it takes a lot of time, mucking around, to figure out what works and what doesn't.
Well that's an interesting post with a lot of thought provoking information, Cupwise.
The only thing I'd like to say is: my whole point was not a matter of sacred ground but rather a matter of giving new users bad advice. I don't jump into TIMED threads where experienced users or developers are discussing their tweaking and testing because RJ Hollins, for example, doesn't need any of my advice about how to best use Nebula. But when someone comes to the forums and clearly doesn't even know how to use Nebula yet (all I'm saying is that there is a bit of a learning curve) and starts asking about TIMED I think that's an appropriate time to issue warnings that this isn't a no compromise, automatic improvement; and, more importantly, that whether or not you consider it an improvement you might in fact be decreasing fidelity to the hardware. Which is exactly what you said in one of those paragraphs there, that this is not something that you would advise for new users (for users at all I believe was your point) and that FREQD, in some cases, would be the higher fidelity choice if I understand you correctly.
If this was a simpler subject that would be one thing; but it's clear from your rather detailed understanding of the issues that there are tradeoffs either way. So I return to my original suggestion that the program developer has a better view of the various tradeoffs and issues their programs are bound by than end users (unless, as you said, that user just has all kinds of time for proper testing and comparison; personally, I have way too much work due every day to even consider that possibility); not to mention the actual hardware unit in question (not just the make/model) with which to compare. So on that basis: how does a guy with VST analyzer compare to a developer with all the info they have access to in terms of hardware original fidelity (and unlike many VSTs where the old adage 'it doesn't matter how much of an LA5A it sounds like, it matters how good it does its job' applies, imho in Nebula it actually does matter to a larger degree how much something sounds like what it's being sold as).
Like I said, if people want to tweak and test and compare, have at it, there's a whole big beautiful engine in there with lots of exposed parts. But when those same people who return to the forum because they made a bunch of tweaks to the engine and now some latest, greatest reverb library won't play back correctly, what then?. To the people handing out advice about how to switch from FREQD to TIMED: what's your guaranteed level of support when this advice affects their ability to use some other program or library?