Login

Nebula Compressors

Officially Licensed 3rd Party Developer Libraries
Free 3rd Party Programs

Re: Nebula Compressors

Postby Cupwise » Sat Sep 08, 2012 5:26 pm

highvoltage wrote:Its not the amount of Gain reduction that matters. Its the program rate versus the actual tempo of the beats.
Nebula will hit and miss the Attack part, based on the program rate.

I have posted these images a few times already. This happens with all the compressors in nebula. The reason people say you should apply less reduction, because the artifacts wont be that prominent that way, and nebula will impart the characteristics.


You can see that each consecutive hit has different shape depending of the timing. You get some sort of interference between the prog rate and the tempo.
Maybe on smoother applications you wont notice anything, but on transient heavy material, it will be very inconsistent. Too bad, cause the vibe is there.


1st i don't know how much i agree that it has to do with the prog rate vs tempo. maybe it does but i'm just not sure. are you making sure that the consecutive tones aren't falling within the release times of the previous one when you adjust the tempo, where they weren't before you did?

2nd, i hate to look like i'm trying to derail this thread to promote my own stuff, but i don't know if i think it's fair to say that all neb compressors do this. i just tried this myself with the free comp i released the other day, and the attacks all come out pretty much the same. i did get one case where they came out different, but it was with a fast tempo and i removed every other tone, then they went back to being the same. so i don't think it's so much the tempo itself, as it is that when you adjust it to go faster, the tones are now still affected by the previous tone's release envelope. and if the tones aren't the exact same distance from each other, then the release from the previous tone will affect each next tone's attack differently. and what i'm describing here will happen with a real hardware comp or even a basic software one.
Cupwise
Expert
Expert
 
Posts: 773
Joined: Tue Nov 23, 2010 2:03 am

Re: Nebula Compressors

Postby Cupwise » Sat Sep 08, 2012 5:36 pm

SWAN wrote:

Cupwise - ok what is the usual prog rate for compressor programs?


it's 2ms by default because of the templates. so probably every comp program from any dev is going to be 2ms, but some might be different. the thing is that, you might have noticed that if you try to lower prog rate yourself, it only goes down so far. the main thing that limits how far it will go is the length of the longest kern. so you have to lower the kern lengths on kern page, then you can lower the prog rate. comps have a default kern length of 10ms, which allows ~2ms prog rate. preamp style stuff defaults at 50ms lengths which causes prog rate to be at i think around 20ms? i forget.
Cupwise
Expert
Expert
 
Posts: 773
Joined: Tue Nov 23, 2010 2:03 am

Re: Nebula Compressors

Postby SWAN » Sat Sep 08, 2012 8:09 pm

Cupwise...thanks for the input...as a developer your understanding will be on point...I think Im starting to get clearer on this...

Highvoltage - is your test from an older version of Nebula compressors? I could be wrong but I remember some tests being done on STN D*x 165 showing something like this-but it was due to inaccurate attack and release values...and issue that has been worked on and developed...

Also - ok prog rate is often 2ms...I looked at my daw and realise that is 2/1000 of a second and not much time - but it can make up a chunk of transient and looks like quite a lot of samples @ 44.1. I assume developers will be adjusting this prog rate depending on their unit? Can anyone see what the prog rate is set for example with FENIX or the 1176 programs?
Mac Mini i7 quad 2.6

Logic X
Live 9
Reaper
SWAN
Expert
Expert
 
Posts: 775
Joined: Fri Mar 26, 2010 11:16 pm

Re: Nebula Compressors

Postby Cupwise » Sun Sep 09, 2012 6:26 am

if by 'adjusting it' you mean 'set it to be faster', no. they can't. i just explained that prog rate is tied to kern length. 2ms is about as fast as you can get. i think you can get a faster one if you edit nebula xml, but the thing is that 10ms kern length is already on the short side. that length is dictating an actual impulse. preamp programs default at 50ms length for a reason, which is because impulses can be that long. so going down to 10 may already be trimming some of the impulse tail off (which isn't necessarily as bad as you might think, but it might mean that some of the 'tone' is lost). so to go below 10ms is, in a lot of cases, just going to be trimming too much. this isn't always going to be true, but to put a lower limit on kern length, i would say around 3ms. and i don't know if lowering kern length down to 3ms allows the prog rate to go any lower than 2ms.
basically i think 2ms is kind of a practical lower limit with prog rate, as things stand.

also keep in mind that with a 1.5ms lookahead that 2ms is only 'behind' by .5, theoretically. i say theoretically because i haven't done lots of testing to see if that's actually the case, and i've never noticed lookahead having much influence over anything..
Cupwise
Expert
Expert
 
Posts: 773
Joined: Tue Nov 23, 2010 2:03 am

Re: Nebula Compressors

Postby SWAN » Sun Sep 09, 2012 12:06 pm

cool yes in your first explanation it seemed like it was default 2ms with the option to change it...

Cupwise wrote:also keep in mind that with a 1.5ms lookahead that 2ms is only 'behind' by .5, theoretically. i say theoretically because i haven't done lots of testing to see if that's actually the case, and i've never noticed lookahead having much influence over anything..


yes this seems an important point because 0.5ms is a short amount of time - although you could argue that if the prog rate could be decreased to 1.5ms then there would be no lag? Or the look-ahead could be increased to 2ms?

I also heard a while back that some people were making Prog rate adjustments for compressor programs (in the XML?) having special 'mastering' versions - which processed at very high CPU cost....its odd because my understanding now is that even in this event - I thought if you do this there is resultant ringing and aliasing when trying to run Nebula in this way - because the kernals are switching too fast...also the harmonics are less accurate...
Mac Mini i7 quad 2.6

Logic X
Live 9
Reaper
SWAN
Expert
Expert
 
Posts: 775
Joined: Fri Mar 26, 2010 11:16 pm

Re: Nebula Compressors

Postby sfunk » Sun Sep 09, 2012 12:37 pm

ngarjuna wrote:
Formbank wrote: the 76D. The old revA blue stripe is nice but Alex's set is pretty great. The behavior is not identical to an 1176 but these programs consistently get me much closer than any others I've ever tried (Waves CLA, UAD, etc).


I am seriously perplexed here. I have a real 1176, the original UAD emulations and 76D, and 76D behaves nothing at all like an 1176; the attack and release behavior is not even close. Can you post some examples please. How are you setting this to get it sounding better than UAD?
sfunk
Member
Member
 
Posts: 226
Joined: Sun Oct 17, 2010 5:59 pm

Re: Nebula Compressors

Postby ngarjuna » Sun Sep 09, 2012 2:51 pm

sfunk wrote:I am seriously perplexed here. I have a real 1176, the original UAD emulations and 76D, and 76D behaves nothing at all like an 1176; the attack and release behavior is not even close. Can you post some examples please. How are you setting this to get it sounding better than UAD?

The old UAD is the exact polar opposite of the Nebula programs: nails the attack/release behavior, doesn't sound anywhere close. I haven't had a chance to play with the UAD revisions much but considering some people swear they're better than the CLA1176 and others swear that the CLA1176 is still better I won't break my ankle running to run and try them.

It's pretty simple, really; when you need attack faster than a Nebula compressor you use something else. When you don't, the Nebula compressors are great. Not everything you slap a compressor on (or even an 1176) is meant to have the transients utterly choked out of it.
User avatar
ngarjuna
Expert
Expert
 
Posts: 778
Joined: Tue Mar 30, 2010 5:04 pm
Location: Miami

Re: Nebula Compressors

Postby highvoltage » Sun Sep 09, 2012 3:04 pm

Cupwise wrote:1st i don't know how much i agree that it has to do with the prog rate vs tempo. maybe it does but i'm just not sure. are you making sure that the consecutive tones aren't falling within the release times of the previous one when you adjust the tempo, where they weren't before you did?

Yes, im very sure i got the release time out of the equation.

2nd, i hate to look like i'm trying to derail this thread to promote my own stuff, but i don't know if i think it's fair to say that all neb compressors do this. i just tried this myself with the free comp i released the other day, and the attacks all come out pretty much the same. i did get one case where they came out different, but it was with a fast tempo and i removed every other tone, then they went back to being the same. so i don't think it's so much the tempo itself, as it is that when you adjust it to go faster, the tones are now still affected by the previous tone's release envelope. and if the tones aren't the exact same distance from each other, then the release from the previous tone will affect each next tone's attack differently. and what i'm describing here will happen with a real hardware comp or even a basic software one.


I have downloaded your program, and will test it soon.
But youre right, some programs don't act this strange, but they all have artifacts. Its mostly with fast attack programs.

I will do some deeper testings and get back.
highvoltage
Member
Member
 
Posts: 235
Joined: Tue Mar 30, 2010 9:44 pm

Re: Nebula Compressors

Postby highvoltage » Sun Sep 09, 2012 3:32 pm

Ok, this is a test with 76D Demo.
Attack, Release both on 7.

Upper side (left channel) Nebula 76D
Lower side (right channel) Waves 76 just for comparison.

http://prntscr.com/f8yq6
Check out the inconsistency of the peaks. Its jumping -3dB sometimes.

Here is a zoom i just cut out manually the release part
after the recording, for closer look.
http://prntscr.com/f8yri
highvoltage
Member
Member
 
Posts: 235
Joined: Tue Mar 30, 2010 9:44 pm

Re: Nebula Compressors

Postby Cupwise » Sun Sep 09, 2012 4:13 pm

SWAN wrote:cool yes in your first explanation it seemed like it was default 2ms with the option to change it...


well.. you CAN always increase it, but that's going in the opposite direction from getting more accurate compression. as things are i really don't see any developers decreasing that, and releasing a comp program that has a faster than 2ms prog rate. like i said, a 10ms length is getting pretty short, especially if you had to trim some impulse to get down to that length. i don't know how short the kerns would have to be to get a faster prog rate than 2ms, but i think at that point you may have lost the 'tone' which is the part that nebula nails. so you would be trading off one for the other... at that point, as enrique said, nebula might act like a run of the mill 'software comp', but that's all it would be. the impulses would be so short that the tone of the unit wouldn't be there anymore.
SWAN wrote:I also heard a while back that some people were making Prog rate adjustments for compressor programs (in the XML?) having special 'mastering' versions - which processed at very high CPU cost....its odd because my understanding now is that even in this event - I thought if you do this there is resultant ringing and aliasing when trying to run Nebula in this way - because the kernals are switching too fast...also the harmonics are less accurate...

the most ideal situation would be if you could have LONGER kern lengths (up to 30-50ms maybe), with FASTER prog rates. then you would have the best of both. so really, the 'default' compressor 'templates' that devs have, which result in 10ms kern lengths, and 2ms prog rates, is a sort of middle ground which was obviously thought about and decided upon by giancarlo/acustica because it is the best compromise. it's the best it can be at the moment. you can tweak xmls and experiment on your end and you might get a really cool sounding result that works well for you in some situation, but it will almost surely represent the hardware less in some aspect, than the program would have before you tweaked it.
Cupwise
Expert
Expert
 
Posts: 773
Joined: Tue Nov 23, 2010 2:03 am

PreviousNext

Return to 3rd party libraries

Who is online

Users browsing this forum: No registered users and 16 guests