Klanghelm MJUC and MJUC jr. released
- KVRAF
- 7791 posts since 20 Jul, 2004 from Clearwater
Anyone have AA CL1? How does this fair up against it?
Wavsen.com - Professional mix delivery platform with client approval, watermarking, and portfolio page builder.
-
- KVRist
- 410 posts since 9 Oct, 2013 from uk
@Compyfox - thanks for your input regarding (lack of) VST3 support; I indeed was thinking about 'easy' sidechaining when I was writing the query... Oh well... I do know that the others you quoted have also had their own 'issues/concerns' when trying to provide good/working/stable VST3 solutions.
Though, Tony did do well with DC8C2, IVGI and SDRR editions...
Not to worry; have bought MJUC anyway - didn't bother with the demo, I just know its going to be fab..!
Glad to read all the great and positive posts from folk here; roll on Sunday, when I will be installing...
(I hope Steinberg are informed of these 'issues' with whats seeming like, generally problematical development of VST3 products...)
thebutler
Though, Tony did do well with DC8C2, IVGI and SDRR editions...
Not to worry; have bought MJUC anyway - didn't bother with the demo, I just know its going to be fab..!
(I hope Steinberg are informed of these 'issues' with whats seeming like, generally problematical development of VST3 products...)
thebutler
System 1 - Win11; i9 13900HK miniPC; 64Gb; Iris XE graphics; Cubase 15.0.10; Studio Pro v8.0.3;UR44 i/o
System 2 - Win10; i7 4790; 16Gb; GTX750Ti; Cubase v14.0.41; WLab Pro v12.0.51; StudioOne v6.6.4
System 2 - Win10; i7 4790; 16Gb; GTX750Ti; Cubase v14.0.41; WLab Pro v12.0.51; StudioOne v6.6.4
- KVRian
- 1369 posts since 29 Apr, 2012 from Paris
They're different beasts, no comparison can fairly be done. I love the CL1 but MJUC is based on a different topology (Vari-mu). CL1 is an interpretation of many compressors cicuitry into one unit. MJUC is based on particular compressors units apart of the Mk3 which is Klanghelm's personal vision of Vari-mu topology.djanthonyw wrote:Anyone have AA CL1? How does this fair up against it?
The color impacted by CL1 on the signal sounds more artificial than MJUC which gives that tube vibe and bite (only my opinion here !). To me MJUC sounds more natural and more colored at the same time than CL1. Doesn't necessarly means CL1 is not as useful as MJUC, just a very different taste. To me the MJUC is nearly a game changer in my comp arsenal (and as a KVRian, I have a lot of comps...). You have to hear it/try it to believe how good it can sound.
Just download the freebie and put it against CL1 and make your own mind about this !
-
- KVRian
- 508 posts since 15 Nov, 2012 from Arkansas, USA
Yes. Tony told me that himself in an e-mail (not that it really matters)3ee wrote:are you sure about that? I remember it as Saturation Distortion Rock and Roll... but who knows?!clintmartin wrote:.with Sex, drugs and rock & roll being SDRR
I just thought he may be having fun with the name again, and it seems he tried, but I was too stupid and it went over my head. Hahaha!
- KVRAF
- 43964 posts since 11 Aug, 2008 from clown world
No way. It's gotta be ''Multi'' ... something or other.
Tried the demo. Bought the payware. Sounds great and not too difficult to use. I actually like the sound without the High Quality setting. Just as well since my Laptop is a bit underpowered.
Tried the demo. Bought the payware. Sounds great and not too difficult to use. I actually like the sound without the High Quality setting. Just as well since my Laptop is a bit underpowered.
Anyone who can make you believe absurdities can make you commit atrocities.
-
- KVRist
- 156 posts since 24 Jul, 2012
Hi,I own AA compressors.djanthonyw wrote:Anyone have AA CL1? How does this fair up against it?
MJUC is very different design compared to CL series, both can complement ech other very well. Personnaly I prefer MJUC sound in HQ mode especially the mk3 one. It's one of the best coloring compressors "if not the best" software compressor I everer eard! Very musical you can push it very hard on drums or bass for example and still sounding. Mk3 can be a great complement to kotelnikof or sonoris mastering comp for mastering. The junior version is good but dont pay justice to paid one, HQ mode and both mk models are amazing. If you can, go for it!
- KVRAF
- 3362 posts since 31 Dec, 2004 from People's Republic of Minnesota
I would've picked up the AA compressor by now but the company's defunct appearance has prevented it.Chandran wrote:Hi,I own AA compressors.djanthonyw wrote:Anyone have AA CL1? How does this fair up against it?
MJUC is very different design compared to CL series, both can complement ech other very well. Personnaly I prefer MJUC sound in HQ mode especially the mk3 one. It's one of the best coloring compressors "if not the best" software compressor I everer eard! Very musical you can push it very hard on drums or bass for example and still sounding. Mk3 can be a great complement to kotelnikof or sonoris mastering comp for mastering. The junior version is good but dont pay justice to paid one, HQ mode and both mk models are amazing. If you can, go for it!
Though MJUC is greatly different in design...I find that it has a similar sound to NI Superchrager GT. NI really did a great job on that one. However, playing around with MJUC I can honestly say it's the smoothest compressor I've ever heard in my life. Can Presswerk get this smooth? I've been trying to match it closely as I can but I'm unable to do it.
-Sam
-
- KVRAF
- 14739 posts since 19 Oct, 2003 from Berlin, Germany
Again, MJUC doesn't have side chaining (was not in the concept), so there is no need for a VST3 version.thebutler wrote:@Compyfox - thanks for your input regarding (lack of) VST3 support; I indeed was thinking about 'easy' sidechaining when I was writing the query... Oh well...
Different framework, different solutions for VST3.thebutler wrote:Though, Tony did do well with DC8C2, IVGI and SDRR editions...
I fear the that a port of DC8C2 will not run smooth for VST3 right out of the box. IVGI and SDRR doesn't use side chaining. So chances are that the VST3 version will be dropped as well.
Trust me, they are MORE THAN AWARE of that by this point... how they respond to that, lies on a whole different ballpark.thebutler wrote:(I hope Steinberg are informed of these 'issues' with whats seeming like, generally problematical development of VST3 products...)
-
- KVRist
- 156 posts since 24 Jul, 2012
masterhiggins wrote:I would've picked up the AA compressor by now but the company's defunct appearance has prevented it.Chandran wrote:Hi,I own AA compressors.djanthonyw wrote:Anyone have AA CL1? How does this fair up against it?
MJUC is very different design compared to CL series, both can complement ech other very well. Personnaly I prefer MJUC sound in HQ mode especially the mk3 one. It's one of the best coloring compressors "if not the best" software compressor I everer eard! Very musical you can push it very hard on drums or bass for example and still sounding. Mk3 can be a great complement to kotelnikof or sonoris mastering comp for mastering. The junior version is good but dont pay justice to paid one, HQ mode and both mk models are amazing. If you can, go for it!
Though MJUC is greatly different in design...I find that it has a similar sound to NI Superchrager GT. NI really did a great job on that one. However, playing around with MJUC I can honestly say it's the smoothest compressor I've ever heard in my life. Can Presswerk get this smooth? I've been trying to match it closely as I can but I'm unable to do it.
-Sam
Yep! I agree this think is incredibly smooth!
When I bought the AA Cl series the compagny apparence looked defunt, tough I received my licence very quickly! And the VST work well on every DAW I own.
-
- KVRAF
- 5200 posts since 17 Aug, 2004
Little MJUC while seriously impressive is a bit pain on the CPU. I am reading manual and they say that CPU usage of big brother is similar.
Yes i do have Haswell 6 core and yes it is overclocked to 4ghz but i am working at 96khz permanently.
As i understand it big brother have switch to "off" for oversampling but then there is supposedly less accurate emulation switched off as well. Why that? Or they call oversampling "more accurate emulation" in general or something?
Is it possible to make switch to disable oversampling (so to get few cycles back for people which are already on high sample rate) but keep more accurate emulation as well.
Anyway congrats on release. Sound of this plugin is really cool...
Yes i do have Haswell 6 core and yes it is overclocked to 4ghz but i am working at 96khz permanently.
As i understand it big brother have switch to "off" for oversampling but then there is supposedly less accurate emulation switched off as well. Why that? Or they call oversampling "more accurate emulation" in general or something?
Is it possible to make switch to disable oversampling (so to get few cycles back for people which are already on high sample rate) but keep more accurate emulation as well.
Anyway congrats on release. Sound of this plugin is really cool...
-
- KVRist
- 156 posts since 24 Jul, 2012
I think HQ is something more than oversampling, drop a line to the dev about that.
The quality you get with this comp is worth the cpu usage IMO. Im using mainly on Busses, so enought cpu to run enought instances here (i7 quadcore 2.2 on laptop) and I can always freeze the track if needed.
The quality you get with this comp is worth the cpu usage IMO. Im using mainly on Busses, so enought cpu to run enought instances here (i7 quadcore 2.2 on laptop) and I can always freeze the track if needed.
-
- KVRAF
- 1991 posts since 12 Mar, 2004
This was always going to be bought here to support Tony, I found DC8C a bit tiresome to use compared to other comps and wasn't looking forward to this that much to be honest, but would buy to support based on how much SDRR gets used in the studio here (On every mix) so i was in no rush to buy it like you guys, just tried jr and i am totally gobsmacked, this free version is already the best comp i have for heavy rap and metal vocals, considering the lack of interest i had in this plugin, it is possible the payware version may replace most of my comps (Including hardware) !!!
I am very much a "Oh no not another compressor plugin" person, and find most of them just overlap with what i already have and have had for a few years now, this is the next step up, the fact that it is 24 euros is absolutely amazing, Tony is now THE developer in my book
I was in the "I hope he doesnt waste his time doing another EQ" camp, but now i want him to hahaha
I am very much a "Oh no not another compressor plugin" person, and find most of them just overlap with what i already have and have had for a few years now, this is the next step up, the fact that it is 24 euros is absolutely amazing, Tony is now THE developer in my book
I was in the "I hope he doesnt waste his time doing another EQ" camp, but now i want him to hahaha
Duh
-
- KVRAF
- 3506 posts since 12 May, 2011
VST3 is not just about side chaining. In Cubase, at least, it's useful for turning off plugins when not actually processing. eg, a fifty track project may only ever have 15 tracks playing at any one time. 50 instances of MJUC brings my machine to a standstill (it's the only piece of software that can cause my fans to go into overdrive mode!), but it could mange 15.Compyfox wrote:thebutler wrote:...MJUC doesn't have side chaining (was not in the concept), so there is no need for a VST3 version...
-
- KVRAF
- 14739 posts since 19 Oct, 2003 from Berlin, Germany
Aaaaah, the "unloading from RAM" argument which only efficiently works if the clips in the tracks are not running in parallel, but are properly spread out. Else, your CPU/RAM/ASIO engine is overloaded just as much. (wrong quote pyramid btw)
And to be honest... do you really process every track of your 50 track project with a compressor?
If the answer is a silent yes, then maybe you should rethink your workflow, because I'm sure that half of these track would not need dynamic processing at all.
Look, I am a Steinberg user and I do beta testing for various companies, so I know the pro's and con's. And every time I get a VST3 version to test (doesn't matter which company, or in whatever framework the tool was written in), it's constant nightmares. What works in Cubase, doesn't work in Wavelab and Studio One. What works in Studio One, might work in Wavelab but not in Cubase. What might work for both Studio One and Cubase, might definitely not work for Wavelab. Vary as you like, rinse and repeat.
And it's not like it's Klanghelm only, that ran into this snake-pit.
Look at the recent TDL/VoS collaborations (withdrawn VST3 at the last minute), Slate Digital (VST3 versions of older plugins still cause sporadic issues in WL), Eiosis (took nearly 2 years to fix(!) the problem - and Eiosis was in constant touch with Steinberg), Nyrv Systems (VST3 version on hold - too many random crashes during development, external side chaining not implemented yet), U-HE (just take a dive at the blog posts by the main programming team - SATIN was the last VST3 release with a sh*tload of workarounds, Presswerk was never released in VST3!), Hornet Plugins (could be fixed over time), Melda Production (was fixed over time - I think by v7, most issues were gone), Admiral Quality (take a look at the backlogs), old TeamDNR's Channel Strip (IIRC), the list goes on and on and on.
Additional to that, the framework that Tony is currently using can not pull off certain features of the VST3 SDK, since the framework (in this case JUCE) and the SDK don't play along nicely on certain ends (the JUCE creators are on that for months now). For example: ever wondered why plugins coded in the JUCE framework don't have a bypass button in Steinberg hosts? Yeah, this is one of the major issues which goes even as far as completely nuking the host (bypass via the mix console is not possible, in sporadic occasions, the host crashes if you try to turn off the plugin). Sometimes the VU can hang or doesn't properly reset. It's getting even worse in Wavelab. Even more graphic issues, random rendering issues where internal modules are turned off out of nowhere, random crashes, etc.
So Tony did the only logical thing: drop VST3 as it caused him more work to fix things. VST2, RTAS/AAX (with certain minor issues reported at GS) and AU on the other hand runs fairly smooth, and that nearly out of the box.
And to be honest, Steinberg was the only company that never really ported VST2's already(!) possible side chaining capabilities. Other hosts handled this nicely - with the press of a button even (Sonar comes to mind). They (Steinberg) created VST3 as (ultimate?) workaround in the first place - else they would have needed to completely code their hosts from scratch. And look how that turned out. Now they say "it's the only logical route to go" (see drop of the VST2 SDK). But go ahead, take a look around at how many companies still refuse to go that route, with more and more revolting! Especially the independent ones. With no collaboration of so called "third party developers" and the SDK coders in near sight to create a VST SDK v4 which fixes all known VST SDK v3.x issues!
I've met up with Tony in late Summer last year, and the initial concept of MJUC already came up during that chat. IIRC, the official beta started in February 2015. And even then I already heard of a lot of behind-the-scenes reports on the VST3 version - especially after I read during a casual chat via mail: "I may go with the JUCE framework in the future" - I already knew what was coming.
Now, if Klanghelm would be a team of 10-20 programmers, this could be easily addressed with workarounds in a timely manner (and probably a higher plugin size). The coders could also devote dedicated time to the VST3 version only, get in touch with VST SDK team to sort out issues - unless the creators of the SDK in question can't help due to reasons beyond our comprehension. But Tony is a one-man-army. And he opted for actually releasing a working version "sooner" (interested users already got impatient), while ignoring the version that is causing too many issues. This cuts the need to spend an extra half year for the VST3 version alone.
Also, for the next couple of weeks, Tony will probably be knee deep in bugfixing again before he will even be able to respond properly. And then he will start to port his other tools to the new framework.
Again, I do understand the pro's and con's of VST3. I do understand the concerns with high ASIO/CPU load (I run an i7 1st Gen myself - and once more, who actually criticized the competition with way less optimized code?!).
But unlike x64, it is just not worth the trouble going the extra route. VST2 is definitely not inferior in any way.
And to be honest... do you really process every track of your 50 track project with a compressor?
If the answer is a silent yes, then maybe you should rethink your workflow, because I'm sure that half of these track would not need dynamic processing at all.
Look, I am a Steinberg user and I do beta testing for various companies, so I know the pro's and con's. And every time I get a VST3 version to test (doesn't matter which company, or in whatever framework the tool was written in), it's constant nightmares. What works in Cubase, doesn't work in Wavelab and Studio One. What works in Studio One, might work in Wavelab but not in Cubase. What might work for both Studio One and Cubase, might definitely not work for Wavelab. Vary as you like, rinse and repeat.
And it's not like it's Klanghelm only, that ran into this snake-pit.
Look at the recent TDL/VoS collaborations (withdrawn VST3 at the last minute), Slate Digital (VST3 versions of older plugins still cause sporadic issues in WL), Eiosis (took nearly 2 years to fix(!) the problem - and Eiosis was in constant touch with Steinberg), Nyrv Systems (VST3 version on hold - too many random crashes during development, external side chaining not implemented yet), U-HE (just take a dive at the blog posts by the main programming team - SATIN was the last VST3 release with a sh*tload of workarounds, Presswerk was never released in VST3!), Hornet Plugins (could be fixed over time), Melda Production (was fixed over time - I think by v7, most issues were gone), Admiral Quality (take a look at the backlogs), old TeamDNR's Channel Strip (IIRC), the list goes on and on and on.
Additional to that, the framework that Tony is currently using can not pull off certain features of the VST3 SDK, since the framework (in this case JUCE) and the SDK don't play along nicely on certain ends (the JUCE creators are on that for months now). For example: ever wondered why plugins coded in the JUCE framework don't have a bypass button in Steinberg hosts? Yeah, this is one of the major issues which goes even as far as completely nuking the host (bypass via the mix console is not possible, in sporadic occasions, the host crashes if you try to turn off the plugin). Sometimes the VU can hang or doesn't properly reset. It's getting even worse in Wavelab. Even more graphic issues, random rendering issues where internal modules are turned off out of nowhere, random crashes, etc.
So Tony did the only logical thing: drop VST3 as it caused him more work to fix things. VST2, RTAS/AAX (with certain minor issues reported at GS) and AU on the other hand runs fairly smooth, and that nearly out of the box.
And to be honest, Steinberg was the only company that never really ported VST2's already(!) possible side chaining capabilities. Other hosts handled this nicely - with the press of a button even (Sonar comes to mind). They (Steinberg) created VST3 as (ultimate?) workaround in the first place - else they would have needed to completely code their hosts from scratch. And look how that turned out. Now they say "it's the only logical route to go" (see drop of the VST2 SDK). But go ahead, take a look around at how many companies still refuse to go that route, with more and more revolting! Especially the independent ones. With no collaboration of so called "third party developers" and the SDK coders in near sight to create a VST SDK v4 which fixes all known VST SDK v3.x issues!
I've met up with Tony in late Summer last year, and the initial concept of MJUC already came up during that chat. IIRC, the official beta started in February 2015. And even then I already heard of a lot of behind-the-scenes reports on the VST3 version - especially after I read during a casual chat via mail: "I may go with the JUCE framework in the future" - I already knew what was coming.
Now, if Klanghelm would be a team of 10-20 programmers, this could be easily addressed with workarounds in a timely manner (and probably a higher plugin size). The coders could also devote dedicated time to the VST3 version only, get in touch with VST SDK team to sort out issues - unless the creators of the SDK in question can't help due to reasons beyond our comprehension. But Tony is a one-man-army. And he opted for actually releasing a working version "sooner" (interested users already got impatient), while ignoring the version that is causing too many issues. This cuts the need to spend an extra half year for the VST3 version alone.
Also, for the next couple of weeks, Tony will probably be knee deep in bugfixing again before he will even be able to respond properly. And then he will start to port his other tools to the new framework.
Again, I do understand the pro's and con's of VST3. I do understand the concerns with high ASIO/CPU load (I run an i7 1st Gen myself - and once more, who actually criticized the competition with way less optimized code?!).
But unlike x64, it is just not worth the trouble going the extra route. VST2 is definitely not inferior in any way.
