SWAN wrote:Well - from what Ive read it appears that Nebula comes set-up for generalised usage. It appears there are different uses/processes Nebula can do - so that the standard settings are as you say - a compromise. A sensible one at that. I understand the TIMED and SPLIT compromise which I think you are referring to. ngarjuna this thread is not intended to be an attack on Nebula - merely Im trying to demystify its approach to compression to understand it better, and get some feedback on the recent programs. This is so I can make an informed decision on my studio purchases. You appear to be launching a defence of AA when I dont think anyone is attacking-just observing and discussing. ... The only suggestion I have made is that if there are tweaks that can improve things like the transient response on compressors (on a per program basis) - then perhaps the developers should be advising on those tweaks.
I fully understand where you're coming from. The way I see it (and perhaps I'm in the minority on this one) is that the devs, whether it be G/E or the third party library developers, really have produced the very best possible tunings for their programs. Yes, of course real world usage comes into play; nobody is going to try to sell a preset that takes 35% of quad core i7! But that's probably as it should be.
So when you complain (not you personally, the colloquial "you") that the devs have not provided optimization I don't really agree with that; they may have optimized for a different goal than some users would optimize for and, for those users, there's a fully tweakable engine. But we can't realistically expect these new variations, many of which A-A has declared explicitly inadvisable, to receive the kind of support that the product receives when it's used as intended.
And now it's all seriously confused; people come and post about this problem or that issue and one can only wonder: how is their Nebula setup configured? Have they tweaked programs for TIMED? When they ran in "normal" configuration, did they explicitly UNDO the TIMED tweaks or did they just run in a normal, untweaked Nebula installation (from my understanding of this tweak those are not the same thing, each program is actually tweaked on an individual basis in order to adjust kernel switching, kernel length, program rate, etc.)? It's all fairly confusing now. I can only guess only how many "technical support" questions G/E have had to solve by suggesting that people put things back the way they're supposed to be run. So that's why, to me, ensuring that we're discussing vanilla Nebula is actually important to all of us getting good and accurate information from this thread. Something I'm also interested in.
I am trying to get the best result and get into these programs - it sounds like your message is "we all know the limitations just use it or shut up".
Not at all; if that's the impression you got, then I probably misspoke. I think it makes perfect sense to discuss the limitations as they exist -- because they do indeed exist. Not only does it help the devs get a reading on where the user base is at on particular issues it also compels us as users to help one another optimize our usage of Nebula (albeit sometimes in less than standard or intended manners). I just want to make sure that, in the context of this particular discussion, we're all talking about the same thing. Highvoltage's confirmation that he has been running his samples in normal/standard configuration is a good example; now that I know that, I know that what he's describing applies to him, me, you and anyone else; as opposed to some special problem that he introduced into his compressor programs tweaking kernel lengths and the like.
With regards to compressors which is what this thread is about Enrique already suggested a tweak to the look-ahead so I dont think any of this discussion, which is intended to be a neutral investigation, is off base so far...I for one am interested in what difference these tweaks make...
I know some of the compressor programs come with the lookahead enabled by default, maybe that's related to this suggestion? On that I'm not sure. Not sure if that's a suggested tweak, though, or if he's confirming that it's being run in standard configuration (as opposed to one of the many popular tweaks going around). Hard to tell from the context there.
because of highvoltage's analysis of my own program i just released, i think i just discovered a weird quirk to nebula comps. out of the things he mentioned, the thing that stood out most for me was when he said my comp was 'so slow', because i 'knew' it wasn't. so i went to see what he was talking about and, he was actually right, sort of. and i've already replied back earlier in the thread about it, but since then i've looked a little closer.
what i noticed is that if you set threshold just a bit below the level of the audio, then set a ratio so that you do get compression, you do get a slow attack even in the fastest setting. you get a slightly slower one at the slowest setting. but then if you take thresh down, the range of the attack gets faster and faster, until you can only get a pretty fast attack. it's almost as if the threshold control is actually shifting the 'range' of the attack control, and that that range is limited to a small portion of the full range.
i went to one of my unfinished programs from the set, where i can tweak some of those things, and i removed all attack settings above 10ms, leaving only 1-10ms. now if i set thresh just below the level, i CAN get fast attacks, and the issue isn't as noticeable because the overall range is now only about 10ms instead of 100. i have a few other comps (not mine) and they have the issue also, but it isn't as bad. i think it's because they don't have as wide of a range of timings with the control as my program does. so it isn't quite as noticeable. but i'm thinking it's probably always there.
so now i'm stuck trying to figure out how or if i can deal with this issue acceptably before releasing the set. anyone can see for themselves what i'm talking about with my 'community version', but like i said i doubt it's the only place you'll see it. i think it's just more noticeable on mine because of the wider range. it probably explains why highvoltage is seeing time values 'off' from their supposed length with these other comps too. try adjusting thresh and see if it doesn't change.
highvoltage wrote:I see a lot of developers releasing compressors with preset attack and release times. Maybe this is the reason. That way they can tweak it behave right under a certain setting. Dunno.
Michael's Drum Compressors for example doesn't have attack and release settings, that's why there are hell of a lot programs.
this is what i was thinking.
i wouldn't think it would be difficult to fix this issue, but i think it would need to be done on acustica's end (in other words, a 3rd party dev couldn't do it), because i've looked through the compressor template and i don't see anything 'wired wrong' that i could fix myself. if thresh is really somehow shifting the allowed range of attack control (and maybe release too), i wouldn't think that would be too difficult to fix (not compared to the other issues with comps). since i would like to release a program set trying to recreate a specific comp, including it's full range of attack/release controls, and since i think the ability to do that would be good for nebula if comps are ever going to be thought of more highly, this is going to be my personal request that this issue be resolved. it seems like one improvement that should be possible.
Cupwise wrote:but can you confirm that you're noticing/seeing this too? threshold is influencing attack time. ?
Yes, i can confirm this. Loaded up 4 different compressors, and they all acted the same. Its like the attack is clipped heavily, and as you lower the threshold, the blockiness off the attack is getting smaller and smaller. Its like an unwanted "hold" function.
And the part where the compressor does nothing in the "hold" part is pretty HUGE if you use only slight compression, it can be 50-60ms long.
This happens on compressors with FIXED attack and release times too. So thats not a solution...
I just looked at the CDSoundmaster demo mp3s in a wave editor and it appears they dont have so much choking of the transients...there is some variation but the examples are wil live drums that naturally vary anyway...
yeah. so i'm kind of surprised nobody had noticed this earlier. heck, i was pretty sure i was about to release this comp set, and only discovered the issue because of your analysis of my demo. i had used the comps in my set for testing and stuff, and i had a feeling that something was a little weird about the attack but i think i just kept adjusting all controls, including thresh, until i got something like the behavior i wanted. i remember that it did strike me as odd that i had to adjust so much, but i chalked it up to my being out of practice with comps (haven't been able to work on my own 'music' since i don't even remember). personally i haven't used neb comps much up until i did this set, and i never would have looked at the envelopes under an oscilloscope without this thread.
the problem is that you have to adjust threshold to get what kind of attack you want, and attack should be adjustable totally independently of thresh, and vice versa (and i still haven't checked to see if release is also somehow 'connected' to thresh yet). and i'm sure this must have contributed a lot to people's negative feelings towards these programs in general, when they use/test them. it means that you won't get the attack/release you expect unless you just coincidentally happen to have thresh in a position to allow it. and since nobody seems to have been aware of this up to now, the chances of that would be pretty slim (it would be the result of pure coincidence or lots and lots of trial and error tweaking/randomly stumbling on the right combination).
but knowing this, you can kind of get what you want a *little* better. so, if you want a really fast attack, you have to drop thresh down drastically. then you could use a lower ratio to get less compression if you don't want as much as the low thresh will give you (this won't be possible with any comp with a fixed ratio, like my recent community release, and others out there). if you want a slow attack, you need to only drop thresh a little, and then you are limited in how much compression you can actually get. this is just a wacky way of using controls, and even knowing this you are limited in what you can do (no deep compression with slow attacks for example). threshold shouldn't be tethered to attack. it makes adjusting to get something like what you want take a lot longer, what you get might not be as good as what you could get otherwise, and some things you just can't ever get.
i was wondering about 'fixed' programs, if it would influence them also. interesting to hear that it does. i've been messing around with some stuff and i think i've made some progress sniffing out the bug... but i doubt there is much i could do on my end.