hamm interesting- I offer controlled tests and provide the preset so that you could repeat them, while you provide no evidence of your claims- and you accuse me of hiding behind statements? doesn't add up.
Are you saying that the higher levels of non-harmonic distortion in the second test are also a coincidence? and what makes you think that non-harmonic distortion will be the same throughout the spectrum?- that's a nonfact (both Nebula and HW).
About "not liking" peak mode- I use what works best for my needs and have no attachment to Nebula's env modes. My first thought when I saw your original post was- "great! - I have to try this" and not "damn, this Cupwise and his creative solutions". I didn't like the sound though
But I understand your point, lets agree we have different needs/goals when using Nebula. I can't convince you that less digital artifacts is more important then trying to mimic (elements) of the HW response to transients, and you will have hard time showing the opposite. I've made enough tests for now (and need to actually work:)
Besides the important testing an observation that you are bringing to this important topic ... it would be most welcome if all parties kinda take a deep breath and let the BP drop to a beneficial 'Calm'.
We need to come to grips with how the Nebula works, both from an 'engine' perspective AND how the libraries are implemented.
Ideally, it could be most useful if the library 'variables' could be eliminated ... say with some 'engineered specific' test library that basically is without any distortion, phase issue,etc. Then maybe allowing a 'neutral ed' test source to examine the 'engine' output specs.
My thought along this line mirrors a multi-layered instrument sampling. If there was an issue in one of the 'layers', can we be certain of what we are analyzing?
Without a doubt, the concept of using 'PEAK' scaling seems too logical ... particularly with things like Preamps. If this utilizes the full spectrum of kernels via the input levels, then this would seem a no brainer.
I have been doing some listening test of my own, with no conclusion as yet. Honestly, I never thought that the 'metering' had anything to do with the playback response So this is quite educational.
To this end, please lets continue this in a not 'who's right who's wrong' mode ... no one is going to tell anyone what mode, or even what library to use.
Also .... where are the other Devs????!!! How about our chief Nebula programmer??? no opinions to share?
Anyway ... lets take a good, collective approach to help us all better understand these things. Hope to have more testing time when I complete several major projects in the works.
Again ... thanks for your research and observations.
Also .... where are the other Devs????!!! How about our chief Nebula programmer??? no opinions to share?
Anyway ... lets take a good, collective approach to help us all better understand these things...
Mr RJHollins beat me to it, and I would like to echo his sentiments quoted above.
It is FANTASTIC you guys are working on this, but its crazy that Giancarlo/Acustica Audio does not wade in here and sort FACTS out.
I feel bad I can't dedicate the time to joining in some listening tests, but I am totally stressed out with other jobs I need to do right now, arrgghh!
I want to light a peace pipe, take a massive hit (just cause I lit it and its good shit) and pass it to YR and Cupwise. You guys are amazing, but I think you are taking things a bit personally when it is a scientific test being undertaken. Everyone is friends here working towards the same goal
Great conversation and competition to get to the truth, no doubt. A great machine has been built, in my case at least it is controlled by folklore and ignorance, a combination of accidental global settings and whatever settings developers have chosen during their sampling and preset creation process.
While it may be a fact that the settings for nebula are explained in a reference spread across this website what isn't yet clear to me, Nebula3 Pro license holder, are the settings interactions and optimal settings for any particular preset I'm running. I had assumed up until this thread that the preset contained the optimal settings, now maybe that is not the case based on another set of variables (not the least of which includes the cpu resources available).
Obviously it's long past time for me to roll my sleeves up and go in and tweak and listen. Now that I have mostly gotten over the 'toggle' controls that indicate the opposite of their current state (clever for code or tester, not for an end user U.I.) and the fact that when I hit the save button it overwrites the current preset (without warning) I am beginning to think and live in 'nebula-land' a little better.
I'd like to understand how the playback engine operates under conditions specific to a certain preset in my environment and the options I have to play it back, sometimes maybe even to 'improve' the intended sound. Obviously that includes a lot of things under the cover maybe even going back to the notes (if supplied) from the original sampling. I do like the idea of control tests and examples so that end users at my minimal level can take a specified piece of audio, preset and nebula version and change settings and get expected outcomes. Some kind of tutorial in fact based on a specific version of nebula created by the nebula folks - if that is necessary. Otherwise if all that is needed is a developer to create a preset and the end user plug it in then who cares about understanding the engine (except devs and tweakers).
It's taken a few days to get thru this 22 page thread - thanks to all for doing a brain dump - there's a lot here!
Thanks RJHollins and david1103, I will tone down the sarcasm. The way I understand it, NAT does not sample the thd of the preamp's transients. So we don't really know (using NAT/Nebula only) how the transients are saturated differently then longer tones for instance (just as we don't know what are the slew rate, noise, non-harmonic distortion etc ). What we try to do is look for ways that produce the most convincing simulations.
The problem with testing how Nebula "behaves" is that it's very complex with lots of variables and actually demands specialized tools. For instance, I find that normally, presets with higher THD produce more artifacts with high levels of audio. But that's not always true. It's also common knowledge that smoothing decreases unwanted distortion, but I've found several cases where it actually increases them and the list goes on.
I think since developers have access to both HW and the sampled presets, they can match the sound more accurately and hopefully provide samples of both so that we can hear them. It's however plausible that since they have to make choices & compromises, you will end up with presets that could (subjectively) sound better when tweaked (timed mode, kernel length, env mode and so on ).
I wish that we had specialized tools to more easily quantify things in a more "scientific" way, but I'm sure that even if we had them we will still be debating about what sounds good and what doesn't. As long as we don't become the new "Gearslutz" it's all good.
sarcasm? you accused me of fabricating a flawed test on purpose. why should i want to go back and forth with this with you anymore? i might have been a little aggressive with my side of it but i never assumed you were intentionally rigging tests.
i may look into this further on my own, but right now here's where i stand- a) i know for a fact that RMS mode does not detect fast peaks/transients to get them to play louder samples from the hardware like they should. this is not just my opinion. b) there are tons of different variables that could be causing this or that test to show whatever results happen. i already proved this earlier when you were absolutely sure that what was left after a null between peak/rms was added inharmonic distortion, and i pointed out that you can't see it with any kind of analysis on the peak version, or see much if any difference between the peak and rms versions, so it's probably phase shifting causing what was left after null. that proved that different things can cause results and should be accounted for, that you shouldn't automatically assume that it's what you expected was causing them, and that you have misread results before. so you can keep coming up with more tests and making statements about them and i would be here forever sifting through all the variables that might come into play. c) your latest tests are just pictures, i can't do anything with that even if i cared to, but i couldn't get the same exact results with presets i tried. i already said that i had one where evf17 mode caused more 'inharmonic distortion' than peak, but i guess that doesn't matter. d) even IF there were proven to be a flaw that caused there to be a few more db of some kind of phase shift or whatever with peak, and it's still around 60db below the main audio, and it's actually always been there anyway even with RMS, i've had plenty of customers who work in studios and have said good things about stuff i've released in peak. so, for me, IF there is a slight increase in some phase artifact, i will take that tradeoff. i would rather have that slight additional artifact that can't be heard, than use RMS mode which ignores peaks. if you want to think that a tube amp program should behave in such a way that transients at a loud level should use dynamic samples taken from the lowest level in the amp, so be it.
and to be honest, there are other flaws with using peak. it isn't going to catch the whole transient, because of the fact that nebula isn't instant. a faster prog rate and some look ahead could maybe help with that. and obviously you'd have to set attack faster. and like i said in the beginning there definitely will be some programs that this causes artifacts with, maybe it actually is less rare than i originally thought.
another disclaimer- i think i already said earlier in this thread, maybe like a year ago, that end users probably shouldn't be looking at this thread and assuming that their nebula or libraries are set up improperly, and start panicking. i think only people willing to do some kind of tests themselves should look at anything in here and start applying it to their programs. and if they do that and something goes wrong, they can't blame whoever sold them those programs, or acustica. so the safest thing is just to leave stuff alone, especially if it already sounds good. so my comments about peak were for people who do have some understanding and are willing to think about and maybe even test it themselves. anyone else should definitely not go making those changes. if there were forum here where only devs went and could talk about this stuff, and everyone popped in to discuss, that'd be where i would have posted instead of here. but maybe there is a good reason some devs don't share their thoughts on this stuff at all, and i feel like this thread demonstrates it.
Cupwise, i don't want to blame you and anyone from devs, but just to understand things happen there. What you say is looks like, for example, AlexB 76D or any other compressors is "sucks" (truly - not), not working as it should, just because they don't use Peak mode? =) That's not true. I tried 76D demo and i like it. In peak mode it soundin similar to Waves. I don't wanna second Waves =)) Especially this shitty CLA76) I want normal, clean compression close to original hardware. Is 1176 is using REAL peak detection? I'm not strong in this kind enginnering stuf, but as far as i know, it has VU meter, and always thought that it's reacting to VU... Which is not PEAK..