Recently released, Henry has made available the 'Klaritizer - AIR' library for NEBULA. [a unique, parallel shelving EQ].
Quoting from various reviews [still maintain 'cloaking']
[this] Parallel EQ falls into the general category of broad, tone‑shaping analogue EQ, it is unlike any other EQ that I know of. It has no bells or filters, just boost‑only high shelves, and it has a parallel signal‑path topology, about which I’ll say more in a moment. It’s not the only parallel EQ on the market, and it’s not the only one that predominantly uses shelves for sonic enhancement... but as far as I know it’s the only one that does both, and whose shelves have quite the shape and high reach that they do.
With the basic working premise outlined above, there are questions raised implementing this 'process' using the 'AIR' library that I would like to discuss and/or 'Klarify'
Let's also stay mindfull, in this discussion, to maintain discression to the actual hardware named.
I hope that with Henry's busy scheduale, that he'd be able to provide extended details to the sampling concept and how to impliment this particular library as designed.
Here's the original working concept:
Signals coming into the [Klaritizer] are split into mindfuldiscretionscheduleimplementsix paths to allow for the parallel processing that lies at the heart of this design. Two, which form the FF path, go direct to a summing bus, and remain untouched. The other four go to the Focus and Klarity ‘engines’, where they’re processed before being sent to the same output bus as the FF signal. If that sounds confusing, the signal flow diagram overleaf should make this much clearer! In short, the design means that at the output the summed stereo signal is made up of one element which is entirely unprocessed, one that has passed only through the Focus engine, and another that has passed only through the Klarity engine.
The only graphic signal flow diagram I have would violate are 'discreet' rule ... so for the moment, I have no diagram to post. If OK, I can post a link that reviews said unit from the 'SOS' site.
If I understand [correctly], the 'AIR' library presets are straight out of the summed output from the unit. If this is, indeed, true ... then, inserting more than one preset [which would be most likely with this unit] will NOT duplicate the unique parallel processing this unit exhibits.
Again ... for a single instance, we would not have issue ... however, the second instance would be processing the preceding effected audio in full. This is not how the true signal flow is designed.
Each preset would need to work off of the 'original', unaffected signal, and THEN be combined.
Again ... If this is what we have, there are routing options that would need to be considered to recreate the intended signal path.
I look to DAW's, such as REAPER, that provide flexible routing architecture. There are also various VST 'patch bay' plugs, like 'MetaPlugin', or Plogue Biddle, that can also allow custom routing.
Anyway ... just wanted to get this out there for discussion and analysis, making sure that we understand how to use this library properly.
Thanks for reading ... look forward to discussion!
Testing/ experimenting continues ... but we seem to have discovered a problem !
I've been testing 2 instances of the AIR library within Plogue's Biddle VST, that allow custom routing of the audio signal.
Running the FOCUS and the Shimmer [for example], I'm getting near complete PHASE CANCELLATION with certain combinations ... but not all of them !?!?
This does not seem to be correct !!
Very strange. I've not been able to compile a list, but I can say that only certain combinations will go to near complete NULL.
This would only show up in parallel routing of 2 instances. If the plugs were routed 'Serially', which would be the case in a normal FX chain ... the output would be 'Phase Reversed'. Again, this is not something expected, nor desired.
I hope Henry sees this post and can address what it is I'm finding.
I'd be cautious using this until we get this looked at.
Any questions, I'll try to better explain. I'm posting this shortly after running a test.
Thanks for picking this up RJ, In light of this I doubt that using the AIR package in series is best as is. Probably best to use the AIR series in conjunction with the plugin or an EQ if you want to add or subtract. I think there is enough scope in the library that one does not need more than one instance no? I sampled every other preset on the opposite channel to get it done in my hire time. So for example - Min was recorded on channel 1, setting 2 on Channel 2. Setting 4 on channel 1, setting 6 on channel 2 and son and so forth. May explain to you why it flips every other preset. On the to do list for when things settle but a simple workaround of course is to use a phase plugin if you must build in serial. Best wishes Henry
Henry Olonga wrote:Thanks for picking this up RJ, In light of this I doubt that using the AIR package in series is best as is. Probably best to use the AIR series in conjunction with the plugin or an EQ if you want to add or subtract. I think there is enough scope in the library that one does not need more than one instance no? I sampled every other preset on the opposite channel to get it done in my hire time. So for example - Min was recorded on channel 1, setting 2 on Channel 2. Setting 4 on channel 1, setting 6 on channel 2 and son and so forth. May explain to you why it flips every other preset. On the to do list for when things settle but a simple workaround of course is to use a phase plugin if you must build in serial. Best wishes Henry
Further testing, along with description of 'sampling order' seems to indicate that a 'out-of-phase' cable inadvertently got into the process.
As to the work flow of the actual unit ... there are 2 'engines' that are more often used at the same time. This means 2 instances of NEBULA would be routine. They would draw from the 2 main engine categories: FOCUS and Klarity.
Within 'those' 2 categories, each have their own sub-category:
1. FOCUS --- LIFT or OPEN
2. KLARITY --- PRESENCE or SHEEN or SHIMMER or SILK
Each engine works on the ORIGINAL signal ONLY ... thus a very important signal flow process. The signal flow chart makes this very easy to follow how this unit uniquely works ... adding to an additional reason why the unit performs the way it does. This cannot be ignored.
Serial order of 2 presets will NOT produce the correct processing. This was the original intent of this thread, how to properly route audio ... until this phase issue derailed
It should be mentioned that the units EQ curves are also very special. In fact, they are probably the single most important design next to the internal audio routing. A substitute algo EQ would not have a chance
Another specific question I originally wanted to ask ... was the 'Full Frequency' signal put in 'BYPASS' during the sampling session ? I would assume so ... thereby each engines sub - sub category was discreet sampled.
For those following along ... I have worked out a routing configuration using 'BIDDLE'. I was then going to look deeper in Reapers routing to do the same thing [as Biddle has its own issues that I'd prefer not to deal with.]
This phase problem needs correcting. Could this be fixed within NAT ??? or would this require re-sampling ?
Hey RJ. Didn't Henry already answer? He suggested a quick solution of adding a phase plugin in front of the second (and presumably reverse phase) instance. Wouldn't this solve at least the phasing issues? And if you are using Reaper, couldn't you split your source track (using Reapers awesome routing) and send it to multiple tracks, each with their own instance of an "Air" preset? And if one is reverse phases, merely reverse the phase right on the Reaper track, no plugin needed. Unless I am missing some logic, this seems very simple and would do what you are wanting.
Although adding a phase correction plug is only a minor inconvenience ... the problem becomes this.
First, this is not a 'standard' equalizer [not speaking of the particular nature on how it achieves that, nor the very special curves it has.
The 'design' is as a 2 part approach, with each tapping the original signal independently ... only to be sum at the end. Again, thanks to either routing within Reaper, or setting up patches with Biddle or Metaplugin ... not a problem.
The hardware consist of 2 engines. Each draws from a sub group.
The 1st [Focus Engine] calls the 'Lift' or the 'Open' sub-category, and the Klarity Engine draws from either Presence, Sheen, Shimmer, or Silk sub-cats.
The way the NEB library is laid out are basically in snap shots through the available gains.
It seems that every other gain preset is 180 out. [I don't recall the precise order of the switch, and whether it holds absolute within each sub-category.
What happens is EACH time a preset gain is auditioned, in either of the 2 engines, we'll have an inverted signal. Not the end of 'life as we know it' should you happen to be working a stereo file.
I have a mono restoration project ... in fact, several more have booked in. So the current project ends up in a highly NULL state.
Then we have to recall which preset is indeed flipped. OR, to keep it fun, if BOTH presets happen to be reversed.
Whether it matters to anyone else ... I prefer NOT inverting the phase of my final output. Call me picky It may only be a technical issue, but one that I could never justify, along with a remote possibility to come back and bite me. So ... not allowed.
What we have are 2 conditions interacting with each other.
This is a pure distraction from what it is I'm focusing on. The music.
I started this thread on a completely different intent ... which lead to the discovery of a fundamental flaw [unfortunately].
My hope, in bring this attention, was to first make the Nebula community aware of the power this unit brings to both tracking and mastering.
Having purchased many libraries [happily], this library is unique in what it can accomplished ... some others come kinda close, but this is special.
But it does require a parallel routing with 2 NEBs ... very UNLIKE any previous EQ library. This is key.
Not for a moment do I believe that Henry would allow this flaw to stand once discovered. Hopefully this can be corrected inside NAT with the raw sample session, or corrected before NAT rendering. [Fingers crossed].
I would be happy to re buy the corrected library ... or if I can correct this with my version of NAT [would need instructions on how to actually do that ].
Thanks for reading this ... and very much hope that this can be fixed without too much grief.
Maybe I am the wrong person to be contributing to this thread RJ. I think you and I have very similar analog pasts, and I imagine that we are relatively the same age (40's-50's....?). And we probably both have a similar feeling of awe in the way that this amazing Nebula technology has brought digital audio so much closer to that analog sound, complete with the things that back then we felt that we "had to accept", like signal degradation from circuitry and transformers, tube "noise" (lol!!), etc. But I feel like while you are trying to get as close as you can to actual realistic emulations of some of our favorite hardware pieces, I accept this stuff as-is and enjoy what it does well and move past what it doesn't. Nebula will always be an emulation, thus never quite right no matter how close it gets. So in the spirit of this thread, and how you originally started it, I am suggesting that we not worry if this wonderful library of Henry's is "accurate" or not, but instead we use it to it's highest capabilities and listen as it helps us achieve better audio. I am not trying to insult you in any way. You are a very intelligent and talented person, I have benefited GREATLY from your presence on the forums that I encounter you on. And because of my great respect for you, I am trying to word this as eloquently as possible. You are very correct that these tools are awesome on mixes and mastering, so let's maybe engage this inquisitive Nebula community in discussing how we all can maximize the use of these tools,and even leaving the collection as-is. Maybe the "fix" is a simple task, something that Henry just "ooops"ed. Maybe it is near impossible and not cost effective. Obviously, only Henry can decide this, but whatever it is he decides is ok with me. So what do you think RJ?