hmm that might be a good idea. here's the thing- the price is going to be higher this time. closer to 40$. if you consider that in the past my compressor releases have been split in two parts/releases which combined would come to at least 30$, it's not really that much more. with rayphlex & slick the split was between hard and soft knee versions, and with smooth it was between the comp and limiter.
but with this one i don't see any logical way of splitting the stuff that's in it, and i really don't want to split it anyway. besides i think my prices have been pretty low in general, maybe TOO low. and this one, i think, is special (not THE 660 but a highly regarded recreation). i've accomplished some things with it that i don't think have been done yet, and i may have put more work into this one than any of the previous ones. so price goes up a bit. but i might do a sale with the price closer to 30 for the first few days..
Generaly speaking, I've lot of success with your compressors which cancel totaly, in my point of view, Nebula's reputation regarding compressor in general. I mean, for EQ, it's commonly accepted that Nebula is THE way and that it's a little more difficult for comp. Love your SHQ versions also.
What about your tests on 'program dependent" attack/release you were talking about in the past ? Did you include part of this work in this release ?
kels wrote:What about your tests on 'program dependent" attack/release you were talking about in the past ? Did you include part of this work in this release ?
yes. the attack, from all the tones i used to analyze it in various ways (different compression amounts, different frequencies, etc) was pretty much always the same with the hardware. it's always just very fast. the release varies depending on the amount of compression there is. this part i feel like i've nailed, and i might show a few pics showing the tones with comparisons between the hardware and these programs.
that type of program dependence is always there (with the hardware), no matter what release setting you use (although it does scale/change a bit depending on the time you use, and i have recreated that also). but there's also the two 'auto release' settings, which give a different type of what can also be called program dependence. it's where the release adjusts depending on how long there has been compression (typically with longer compression durations increasing the time it takes to release). i've been struggling with this, because there isn't anything built into Nebula specifically to accomplish this, so it comes down to figuring out some kind of trickery with the FUNs and connecting things in various ways. i've THOUGHT that i had it a FEW times, but then i always realize that it only works perfectly for the particular amount of compression that i was testing with. more or less compression throws it off. and that's the problem, and it's a HUGE problem, because it means that the programming side of it that i was using need to be a lot more complicated.
so i sat that aside for the moment and decided to release without that aspect. i'm HOPING that i can get it figured out (i've tried multiple different approaches with the FUN formulas and various elements, to try to accomplish this, over the past year now) and add it as an update, and it will be what i focus on after the release. if i can figure that out then i could incorporate that into the rayplex and smooth 609 releases (when i have time, and it would be a good way down the road because even though i like to update older things, i also need to keep moving forward). the type of program dependence that i have figured out already, i'm pretty sure is used by the smooth609 and slick hardware if not also the rayphlex, and i thought ahead and sent all the tones through those that i would need to analyze and compare and fine tune it (again those updates would be well down the road).
anyway i think it was always kind of assumed (even by myself when i first started doing comps) that that first type (release dependent on compression amount) was automatically handled by NAT when sampling, and i can say that that's NOT the case. it took some tricky rewiring of the programs to get it to work, and then a day or so comparing tones with vst oscilloscopes, between the hardware and my programs, and making tiny adjustments, reloading the program, etc. and doing that for various amounts of compression and for every sampled release time. it was pretty nuts. but i think the result is something unique.
It does and I understand all the work behind which explain perhaps why I'am so happy with your lib. Thanks for the infos - I knew this part of sampling was tricky after seeing people of UAD working on it. If we could figure a way to include it in NAT to handle it automaticaly, that would be a big step forward - almost a paradigm change which is what Nebula is anyway.