Klanghelm MJUC and MJUC jr. released

[jens]

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.

That Argument lacks any coherent logic...

jens at his best role again. Second time in this thread even.
I still await a PM from you, you know?


But whatever... apparently a 50 track project NEEDS one compressor each per track. And this is a benchmark for everyone else. Now THIS is what I call coherent logic. And I'm not saying that as Klanghelm user, I say that as an Audio Engineer.

Nope, there is no logic at all, sorry - like totally NOT

ALL plugins use CPU cycles, not just compressors - so your argument really makes NO sense at all.

[jens]

aber dafür fehlt wahrscheinlich auch wieder der Schneid.

Was soll das mit Schneid zu tun haben? Es braucht sehr viel eher Zeit und Energie.

[Compyfox]

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.

That Argument lacks any coherent logic...

jens at his best role again. Second time in this thread even.
I still await a PM from you, you know?


But whatever... apparently a 50 track project NEEDS one compressor each per track. And this is a benchmark for everyone else. Now THIS is what I call coherent logic. And I'm not saying that as Klanghelm user, I say that as an Audio Engineer.

Nope, there is no logic at all, sorry - like totally NOT

ALL plugins use CPU cycles, not just compressors - so your argument really makes NO sense at all.

The original argument was, which you're currently twisting, that 50 instances in Ayorinde's 50-track project break the CPU. And yes, I can confirm that. With Cubase 7.x's ASIO Guard I can run 20 instances in 48kHz, HQ mode on, before the playback starts to barf.

I never said anything against the use of CPU cycles, or rather, played it down. I said that using 50 compressors on 50 channels each don't make sense. To me, in my opinion (emphasis!). Especially a Vari Mu, which is not necessarily your typical channel compressor (I'd use it more on a bus, or if I'm really after a specific - dare I say - "vintage" sound). Unless you're in a certain British recording studio near a cross-walk.

Tony did not hide the fact that this plugin is a more CPU hungry this time around.

And the main concern seemed to have been "it breaks my rig, it's unusable". So I commented on this with a comparison to other VariMu comps that I had on my HDD (Sknote, Slate, IKM, plus the beloved Kotelnikov which is not even a Vari Mu). I further commented on this with an old quote by Mister C.Budde, and mentioned that barely anybody blamed other independent devs if the CPU cycles were too high. Yet the only comment you got to hear around that time was "your CPU is outdated - stay with the times!".

I did not do that in this thread - I gave a suitable reason why this is happening (again: quote by C.Budde).
Compared to other third party devs that tackled Vari Mu comps so far (i.e. Gates limiter), Tony's tool is heavily optimized.


There is your logic, jens.
But again - so much easier to point fingers and say "oh, there goes Mister Compyfox again, talking nonsense".

*now why the heck did I imagine this in Patrick Starfish's voice?!*

aber dafür fehlt wahrscheinlich auch wieder der Schneid.

Was soll das mit Schneid zu tun haben? Es braucht sehr viel eher Zeit und Energie.

But you still have enough energy to constantly derail a thread if certain users pop up. I think this is what the definition "trolling" is all about? Could be wrong though.

But that's cool - as you were!

[jens]

The original argument was, which you're currently twisting, that 50 instances in Ayorinde's 50-track project break the CPU. And yes, I can confirm that. With Cubase 7.x's ASIO Guard I can run 20 instances in 48kHz, HQ mode on, before the playback starts to barf.

I never said anything against the use of CPU cycles, or rather, played it down. I said that using 50 compressors on 50 channels each don't make sense. To me, in my opinion (emphasis!). Especially a Vari Mu, which is not necessarily your typical channel compressor (I'd use it more on a bus, or if I'm really after a specific - dare I say - "vintage" sound). Unless you're in a certain British recording studio near a cross-walk.

Tony did not hide the fact that this plugin is a more CPU hungry this time around.

And the main concern seemed to have been "it breaks my rig, it's unusable". So I commented on this with a comparison to other VariMu comps that I had on my HDD (Sknote, Slate, IKM, plus the beloved Kotelnikov which is not even a Vari Mu). I further commented on this with an old quote by Mister C.Budde, and mentioned that barely anybody blamed other independent devs if the CPU cycles were too high. Yet the only comment you got to hear around that time was "your CPU is outdated - stay with the times!".

I did not do that in this thread - I gave a suitable reason why this is happening (again: quote by C.Budde).
Compared to other third party devs that tackled Vari Mu comps so far (i.e. Gates limiter), Tony's tool is heavily optimized.


There is your logic, jens.
But again - so much easier to point fingers and say "oh, there goes Mister Compyfox again, talking nonsense".

*now why the heck did I imagine this in Patrick Starfish's voice?!*

The more you post the less you make sense - the argument was, that - unlike your original claim - VST3 has other benefits besides sidechaining, the main one being that the the plugins stop using CPU while they are not processing anything.

The "50 tracks with 50 compressors" was of course just AN EXAMPLE and the way you keep going about this show how nicely you misunderstood it all. It is a FACT, that they more of the plugins you use in any give project are VST3, the less your total CPU consumption will be - except ALL of these plugins are processing ALL THE TIME. And the diffrence between VST2 and VST3 will be the bigger, the more CPU hungry the VST3 plugins are. And since Mjuc is pretty CPU intensive - as you just said yourself - the benefit of having it as a VST3 plugin with of course be quite significant -(except for those who only work on projects where all instances of Mjuc are processing all the time) - regardless of how Long and how much you keep arguing against it.

So: what about writing less and thinking more? That will make it a lot less likely that people Point at you and say "there goes Mr. Compyfox again"

You really have a strong tendency to post bloated and conceited nonsense - which is why I called you "Mr. Toad" once.

[jens]

aber dafür fehlt wahrscheinlich auch wieder der Schneid.

Was soll das mit Schneid zu tun haben? Es braucht sehr viel eher Zeit und Energie.

But you still have enough energy to constantly derail a thread if certain users pop up. I think this is what the definition "trolling" is all about? Could be wrong though.

But that's cool - as you were!

I am not derailing threads - I tend to post admittedly snide and pointed yet accurate ON TOPIC one-liners. Quite unlike you, I hasten to add.

[stardustmedia]

aber dafür fehlt wahrscheinlich auch wieder der Schneid.

Was soll das mit Schneid zu tun haben? Es braucht sehr viel eher Zeit und Energie.

But you still have enough energy to constantly derail a thread if certain users pop up. I think this is what the definition "trolling" is all about? Could be wrong though.

But that's cool - as you were!

I am not derailing threads - I tend to post admittedly snide and pointed yet accurate ON TOPIC one-liners. Quite unlike you, I hasten to add.

For me the one without logic are your replies. I totally understood compyfox, but your replies didnt even go into his points.

I also don't get why someone should use 50 compressors in one song. Especially a character compressor. But that's ok for if the producer/engineer likes it. I recommend them to get a better computer then.

[Turello]

Thanks a lot Compyfox...
I escape soon by this thread, all write in German language... And i tempted to start write in Sick-cilian!!!

[jens]

I also don't get why someone should use 50 compressors in one song. Especially a character compressor. But that's ok for if the producer/engineer likes it. I recommend them to get a better computer then.

I can't help you guys - if you don't get it then you don't get it. Can't steel from the pocket of a naked man.

[3ee]

guys, please, let's just get back to the topic!

[Aiynzahev]

guys, please, let's just get back to the topic!

Yes, back on topic and WOW what an amazing release. The quality and price as incredible. I love the drive in the 3 different modes, and I agree about Mk3 sounding more like an SSL than a 670. Awesome times we live in for this kind of thing.

[Googly Smythe]

... I also don't get why someone should use 50 compressors in one song. Especially a character compressor. But that's ok for if the producer/engineer likes it. I recommend them to get a better computer then.

It was just an extreme example situation, not a description of my personal workflow. And anyway, if 50 compressors in one song sounds good, it is good, yes? There are no rules in music production.

On topic:
I like Tony's stuff enough to have bought MJUC on day one. Having messed with it for a couple of days it will definitely appear on all my buses - all 50 of them!

[tonhelm]

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

This is actually one of the greatest comments, I've read so far since the MJUC release.
A lot of people were skeptical about "meh, another compressor, just what the world needs". And that it took soo long with all the changes, tweaks and such didn't help either. You can't imagine what a relief it is to read comments like the one from you, bungle, now And that last sentence about doing an EQ made me smile...

Tony

[3ee]

Hey guys, just made a test to check out the tube distortion flavors for each MK:
The tones I dialed in aren't particularly aesthetic... but take it as information on how the tubes react if driven pretty hot with this bass seq.

1 - dry loop
2 - MK1
3 - MK2
4 - MK3

https://app.box.com/s/wfc05f7jm9ooin7ab8r2dfzovxp5bvy2

I recommend you download the file since the online preview should sound kinda lo-fi.

[tonhelm]

First off, sorry for my absence here. I'm literally answering mails all day long right now. The response is fantastic.
Thank you, Compyfox for your help and infos here.

To answer a few things that came up in this thread:

CPU-usage:
I've spent a lot of time getting the CPU-load down to where it is now, so I am afraid further optimizing isn't possible at this point. Variable-mu comps are the most organic compressors. They are not just automatic volume reducers. There are so many sound nuances with this type of comp, so many important little things, that if you really want to get it right, it'll eat some CPU cycles. The models in MJUC take care of the whole signal path with various transformers and tube stages. That IS expensive, not so much money wise in this case, but CPU-wise. All these little fluctuations, interactions, physics are part of the beauty and want be modeled. I wanted MJUC to be a non compromise solution, and reducing the CPU-load even further won't work without sacrificing quality.
One reason, why I chose mostly Mk1 for the free MJUC jr., was to include the most demanding of all models, so that you're able to test, if your system can handle the cpu consumption of the big brother. With the big brother, there are a few possibilities to reduce the demands quite a bit. For instance Mk2 only uses half the processing power of Mk1 here, turning Drive to 0 will reduce it further. Mk3 is also far less demanding than Mk1.

Oversampling in MJUC jr.:
no. just a very detailed model. The HQ in the big version uses more accurate models and oversampling but increase CPU load by a gator of approx. 2.2 here. Though in most situations it's not really needed to use that IMO, as I am not a fan of oversampling and try to avoid it as much as possible and worked hard to make oversampling less necessary. That said, there are quite a few user, who feel that the HQ in MJUC sets the comp to another level.

VST3:
not yet, too much work for a single format, too many workarounds needed External sidechaining would be the only reason to provide a VST3 version at his point. I see the advantage of "no processing at idle". AAX does that too. During beta I was thinking about implementing my own "no processing on idle" to make this available in older formats too. IIRC a few other devs offer something like this in their plugin. But this needs a bit more time a lot of care, since it's easy that such thing does more harm that any good.

the name MJUC:
as Compyfox said, it was MUCO in the beginning (blandly for "mu-compressor"). Until beta testers told me of very unfavorable meaning of this word. Now it's just [mew-c ]. In some scientific papers the "mu" is also written as "mju".

Mk3 on idle in FL-Studio bug:
I think I can start working on this by next monday. It should be a simple fix, I already know where to look at, it just takes a bit of time.

Tony

[Compyfox]

>snip<

The more you post the less you make sense - the argument was, that - unlike your original claim - VST3 has other benefits besides sidechaining, the main one being that the the plugins stop using CPU while they are not processing anything.

That argument came later by Ayorinde as a "you forgot one of the essential features of VST3".
And I answered why this may not work in modern days. I now see this "feature" as a relict of the past where CPU power was not affordable.

It is also part of a bigger problem that a lot of devs face lately, especially those that like to enable native side-chaining in Steinberg hosts (where it only works via VST3). I already commented on it (random plugin behavior, crashes, etc). Tony made it also clear again with his "too many workarounds needed" comment.

The "50 tracks with 50 compressors" was of course just AN EXAMPLE and the way you keep going about this show how nicely you misunderstood it all.

Since normal users (unlike beta testers) didn't have access to the VST3 version, the focus (and therefore the made comment) on the CPU usage with (fictional or not) 50 instances were based upon VST2.

You seem to have over-read that little detail, but saw a chance to show me my place. Sorry - didn't work out this time.

It is a FACT, that they more of the plugins you use in any give project are VST3, the less your total CPU consumption will be - except ALL of these plugins are processing ALL THE TIME. And the diffrence between VST2 and VST3 will be the bigger, the more CPU hungry the VST3 plugins are. And since Mjuc is pretty CPU intensive - as you just said yourself - the benefit of having it as a VST3 plugin with of course be quite significant -(except for those who only work on projects where all instances of Mjuc are processing all the time) - regardless of how Long and how much you keep arguing against it.

Can't confirm that with MJUC, sorry. Neither a couple of other selected VST3 versions I have on my HDD - especially those that need(!) the VST3 engine in order to properly use external side chaining (Steinberg's "workaround", remember?)

Furthermore, in order to really "benefit" from the VST3 RAM unload function, you need to have tracks that do not constantly overlap. Meaning: small clips here and there. The most recent projects I worked with, did use 80% of the track's song length however.

CPU saving, plus/minus 10%. Not counting possible issues once the plugin kicks in and kicks out of the CPU/RAM cycles (which is another known VST3 issue in certain hosts). Real benefits: barely anymore. At least not if you're on more modern i5's and i7's in general already.

So: what about writing less and thinking more?

There... A one liner, just for you.

You really have a strong tendency to post bloated and conceited nonsense - which is why I called you "Mr. Toad" once.

I am not derailing threads - I tend to post admittedly snide and pointed yet accurate ON TOPIC one-liners. Quite unlike you, I hasten to add.

Both derailing and insulting again. Jackpot, jens.

Since you don't respond via PM, I ask in public. What did I ever do to you to constantly bark up my tree? I don't even know you. Oh wait, I'm a forum user - and I don't agree with with the mass majority. I also find bugs that others don't (good beta tester traits btw), which in turn is all in my head. But hey - at least I don't hide behind an avatar.

Sorry, can't think of a clever Guitarist joke/insult to add here. Heck, not even a bassist one. Care to send me a couple?

Thanks a lot Compyfox...

Appreciated.

I escape soon by this thread, all write in German language... And i tempted to start write in Sick-cilian!!!

Hahaha - great catch!

And anyway, if 50 compressors in one song sounds good, it is good, yes? There are no rules in music production.

No rules, but common sense.






And thanks to Tony for sparing some time to answer and confirming certain comments.