Kazrog Mhb green

[Michael Sage]

Interesting.
For me, the reliability and fault tolerance of software are far more important than sound quality.

[DCrown]

no need to make it look like hardware imo.

I disagree. if a software models a hardware unit, it should (imo) also look like it. Especially if it tries to replicate one exact piece of hardware.

in this special case things could be more legible (especially at lower sizes) and improvements could be made here and there but apart from that....

honestly though.... I didn't even purchase it, so why am I still talking? I'm quite happy using Kazrog's True Dynamics (which are way more generic - apart from a slight low-cut there's no apparent EQ change at all) and IF I want EQ changes I simply use the True 252.

It's not about the look, it's bad responsiveness and I am obviously not tge only one being faced with this issue.
Maybe you by coincidence have a similar computer like dev, but it takes way more to be a good dev. Plugins of other devs don't cause this issue

[Kazrog]

Hey everyone,

I don't come to these forums as often as I used to, but I'm noticing several reports here of UI sluggishness that are not at all representative of anything we're receiving on the support ticketing side.

If you're having issues, please know that you are entitled to support for the software you buy, and that we are working on maintenance updates to our entire plugin lineup as we speak. If issues turn out to be bugs rather than user error or misconfiguration, chances are they can be resolved in this update cycle, so please open a support ticket so we can help you.

Dismissing issues as "bad code" is unhelpful to everyone. Stability and clean, efficient code are my absolute top priorities as a developer, and always have been, so if you're experiencing anything less than that, it's very important to me that these issues get investigated and resolved.

More broadly, one mistake I see many audio plugin users make is to assume that the issues they experience on their personal setup are common/universal, or even known by the developer, so they don't bother reaching out for support even though that's part of what they're paying for. Every other audio plugin developer I've spoken with has shared this same sentiment as well.

The reality is that audio plugins coexist in a complex patchwork of SDKs, frameworks, hosts, CPU architectures, audio interface drivers, and operating systems. Ultimately, there is no such thing as an audio plugin from any developer that works perfectly with every conceivable configuration. Dialogue between users and developers is essential in order to improve the reliability of software.

In any case, thank you all for your feedback on MHB Green. This is a 1.0 product and our first product with Michael Brauer. We've got a lot more planned, and we're always listening to user feedback!

[bmanic]

@Kazrog

Shane, my quip about "bad code" comes from simple experience. I've been in contact with you over the years of numerous bugs and things (last time it was the Avalon emulation) and you NEVER actually solved some of the issues. For instance the oversampling bugs.. instead you removed the option and called it "a fix". Not sure if that has changed ever. Don't really care though as I didn't end up buying it due to the buggyness of the demo.

My point is: If you truly stood by what you just said, I wouldn't have experienced the neglect of bug reports over the many years. There is a pattern to this. I don't lightly call things "bad".. it's not like I'm taking things out of thin air here, I'm reacting to a pattern of behavior and a pattern of things happening with your plugins. At some point you just have to call a spade a spade if it keeps looking like a spade for years on end.

Sorry for the negativity on this but yeah, saying that Kazrog code hasn't been all that reliable over the years with numerous small(ish), sometimes annoying issues, isn't exaggerating it.

[escalona]

[Kazrog]

@Kazrog

Shane, my quip about "bad code" comes from simple experience. I've been in contact with you over the years of numerous bugs and things (last time it was the Avalon emulation) and you NEVER actually solved some of the issues. For instance the oversampling bugs.. instead you removed the option and called it "a fix". Not sure if that has changed ever. Don't really care though as I didn't end up buying it due to the buggyness of the demo.

Kazrog plugins have always included oversampling, and that option has never been "removed." Nor have there been any bugs related to the oversampling itself. Additionally, there has never been an instance of a bug or issue that has been left unresolved once discovered, either.

My point is: If you truly stood by what you just said, I wouldn't have experienced the neglect of bug reports over the many years. There is a pattern to this. I don't lightly call things "bad".. it's not like I'm taking things out of thin air here, I'm reacting to a pattern of behavior and a pattern of things happening with your plugins. At some point you just have to call a spade a spade if it keeps looking like a spade for years on end.

This is simply untrue. There has never been any neglect of bug reports here. I'm honestly shocked and baffled by this feedback. Are you sure you're thinking of the correct developer?

EDIT: Alright, definitely not a case of mistaken identity after all. And now I'm putting the pieces together and realizing you're the same @bmanic from GearSpace, and what you're referring to above has to do with the 1.0.0 issues in the Avalon VT-747SP plugin that were resolved shortly after release. Definitely not neglected - quite the opposite - addressed promptly.

Since this thread is about MHB Green, I won't derail this thread further with discussion of a different plugin entirely. So, @bmanic, if there's anything I can do to help you with any of our products, please open a support ticket and ask for me specifically. Thanks!

[Kazrog]

The GUI kinda supports higher cpu usage and quite long loading times and value changes.
As soon as I change to Reaper UI everything is fine.
It's sad that gui is making plugin worse.
A simple, less ressource eating gui would be appreciated, no need to make it look like hardware imo.

The UI itself shouldn't impact CPU usage in any notable way, nor should there be long loading times. Of course, if you're experiencing issues, please open a support ticket.

That being said, for workflow reasons, by popular demand, we will be adding a minimalist UI option to this and all of our other analog modeled plugins in a forthcoming free update.

[bmanic]

Kazrog plugins have always included oversampling, and that option has never been "removed." Nor have there been any bugs related to the oversampling itself. Additionally, there has never been an instance of a bug or issue that has been left unresolved once discovered, either.

That is an absolute blatant LIE. Sorry but what the hell man??

When the Avalon vt-747sp plugin was released it had HUGE issues with it's oversampling. It was capable of going to really high levels of oversampling (32 times OS if I recall correctly) but it caused crashes and incorrect frequency response problems.. and it could also result in massive audio spikes and sudden "death" of the plugin (meaning you had to remove the plugin from the host and open it up again).

Your solution? You removed the ability to use high rates of oversampling. You could still crash the plugin and cause all kinds of issue by setting the DAW to 192kHz or 384kHz and then enabling 8x oversampling from within the plugin.

Sorry but seriously, what the hell man?

ALL the evidence and reporting is still in my inbox. Also ALL the evidence is plainly there for all to see on Gearspace. .. and I quote:

BUG: Oversampling at 32x is 100% broken. Plugin creates a huge sudden "plop!!" sound and dies (tested in latest version of Reaper, using VST3 plugin version on Mac M1 Mini running Big Sur last update). It's also noteworthy that 2x oversampling in the plugin + 16x oversampling within Reaper also kills the plugin.

BUG: Huge EQ curve changes happen when going through the different oversampling options. 1x sounds nothing like 4x for instance. Also, Low-Shelf causes massive DC offset/blows out the speakers if you have the plugin set to 16x oversampling. This is "danger" levels of subs/DC offset.

EDIT: I can also add that the compression behavior changes a tiny bit with different sampling rates, perhaps a tiny bit more than would be expected.

Annoyance: Meter is very laggy and seems to be operating at very low frame rate. Needless to say, the real thing has a silky smooth almost intoxicating GR needle.

Annoyance: There's no digital headroom/volume control post main output gain so if you want to actually abuse the thing, you need a separate plugin to tame the gain. Please Kazrog, this is one idea you could happily steal from Plugin Alliance and other developers.

Annoyance: Graphics get a bit blurry when resizing the plugin, though this is to be expected with sprites. No biggie.

That is what I WROTE there back in August 2023. Also sent you an email with detailed bug report. I can also dig out the followup once you had removed the high oversampling options but I rather not spend time throwing mud in your face.

Shane, this is not a good look for you. At the very least, DO NOT LIE.

EDIT: Alright, definitely not a case of mistaken identity after all. And now I'm putting the pieces together and realizing you're the same @bmanic from GearSpace, and what you're referring to above has to do with the 1.0.0 issues in the Avalon VT-747SP plugin that were resolved shortly after release. Definitely not neglected - quite the opposite - addressed promptly.

.. and like I said, it was "addressed" by removing the option completely. And like I said, I was still able to crash it and cause ALL the problems associated with 16 and 32 times oversampling simply by "forcing it" by using the built in DAW sample rate combined with the maximum available once it was "fixed".

So yeah, absolutely everything I said here was true. What the heck, lemme download the demo of the Avalon and check if it still holds true.

[Kazrog]

No matter how complex it looks, it shouldn't take any extra CPU cycles (or at the most a tiny minimal fraction of a %) just because it looks pretty.

I completely agree!

For instance, switching the over sampling from 2x to 8x totally stops my computer in it's tracks. I get the spinning beach ball for up to 30 seconds before it switches.. so I just set it, save it as default, and forget it.

That isn't normal, and you shouldn't have to do that!

Again, if you would contact us for support we can get to the bottom of what might be causing that on your specific setup.

[bmanic]

EDIT: Alright, definitely not a case of mistaken identity after all. And now I'm putting the pieces together and realizing you're the same @bmanic from GearSpace, and what you're referring to above has to do with the 1.0.0 issues in the Avalon VT-747SP plugin that were resolved shortly after release. Definitely not neglected - quite the opposite - addressed promptly.

.. and like I said, it was "addressed" by removing the option completely. And like I said, I was still able to crash it and cause ALL the problems associated with 16 and 32 times oversampling simply by "forcing it" by using the built in DAW sample rate combined with the maximum available once it was "fixed".

So yeah, absolutely everything I said here was true. What the heck, lemme download the demo of the Avalon and check if it still holds true.

.. and I just downloaded Avalon v1.0.5, the latest available, and it's still broken EXACTLY the way I described (and had sent a bug report in late 2023).

And indeed the higher oversampling modes are still missing. I rest my case.

[Kazrog]

That is an absolute blatant LIE. Sorry but what the hell man??

This is not a lie. I think we have different interpretations of the same discussion. Both of us are telling the truth, but from different perspectives. Let's get into it...

When the Avalon vt-747sp plugin was released it had HUGE issues with it's oversampling.

The issues weren't actually with the oversampling itself, but rather the normal CPU load consequences of intensive processing at high audio sample rates. Nothing has changed in the way in which the oversampling works under the hood. That is a misconception that I can clear up here.

It was capable of going to really high levels of oversampling (32 times OS if I recall correctly) but it caused crashes and incorrect frequency response problems.. and it could also result in massive audio spikes and sudden "death" of the plugin (meaning you had to remove the plugin from the host and open it up again).

There are multiple different behaviors here to unpack, actually.

1. 32x oversampling requires a high amount of single core speed, and may be unstable on a wide variety of configurations for realtime processing due to buffer underrun. To mitigate this, more CPU intensive plugins have been moved to an adaptive oversampling implementation, and realtime CPU monitoring and buffer underrun prevention have been implemented in all of our plugins.
2. Frequency response issues with filter banks in the Avalon VT-747SP 1.0.0 plugin were a side effect of extreme anti-cramping at high oversampling settings that were subsequently resolved by implementing adaptive oversampling.
3. Massive audio spikes and sudden crashes were caused by insufficient CPU resources when using extremely high oversampling settings (see 1 above) and again, were resolved shortly after release.

Your solution? You removed the ability to use high rates of oversampling. You could still crash the plugin and cause all kinds of issue by setting the DAW to 192kHz or 384kHz and then enabling 8x oversampling from within the plugin.

This was, again, resolved by utilizing adaptive oversampling. If you've been able to intentionally push the plugin into a crash condition in a 192 kHz or 384 kHz session since this was implemented, I'm surprised, but that's something that can be looked into. FWIW, we don't test at rates above 192 kHz as it's not a common use case, and I personally don't even have hardware capable of going above that in-house.

ALL the evidence and reporting is still in my inbox. Also ALL the evidence is plainly there for all to see on Gearspace.

We're looking at exactly the same information from different perspectives, and I feel we've had a misunderstanding here.

[Kazrog]

.. and I just downloaded Avalon v1.0.5, the latest available, and it's still broken EXACTLY the way I described (and had sent a bug report in late 2023).

I'm really surprised to hear this!

I was under the impression that any issues like this had long since been resolved, since the plugin has been rock solid for our team and colleagues, and we have had no support tickets related to any issues with the plugin in well over a year.

That said, we're in a maintenance update cycle right now and I'd be happy to revisit this and take a look at what, specifically, you're experiencing in Avalon VT-747 SP 1.0.5.

Thanks!

[bmanic]

I don't know if I have the patience. We've been down this road before and considering your opinion that "it's just a matter of perspective" is incredibly super frustrating considering all the time I put into trying to get you to acknowledge the problems last time around. Suffice it to say, just run higher sample rate projects through the Avalon while it's on it's own highest oversampling, check the delta, mess around with the internal sidechain and you should be able to make it go "poof!" in a matter of minutes. You'll also notice it causes some big DC offset differences in the emulation depending on sample rate and thus slight variations in how the compression happens (delta of about -15dBFS if you take the DC offset into account. Remove the DC offset and it's down to about -40dBFS.)

I'll leave it at that. But I'll send you an email and hopefully a video next time MHB is acting up. That one I actually purchased so it's in my own best interest to get it sorted. The gist of it is that the more instances you have in a project, the slower the UI opens and the easier it freezes, especially if changing oversampling on an instance. Sometimes you also get a false CPU OVERLOAD banner on top that can completely kill the plugin from working at all, even though the DAW runs just fine and no audio drop outs are heard.

[Kazrog]

I'm surprised (and sorry) to hear that you've felt that you had to try to get me to acknowledge issues with the Avalon VT-747SP plugin. I had honestly believed that any and all of those issues were resolved long ago, as they'd been cleared off the bug tracker and we'd received no further reports of any similar issues since (until now.)

Just so you know, CPU OVERLOAD banners appear in recent Kazrog plugin versions when samples are dropped, and are just a warning. However, it is possible for samples to be dropped inaudibly, so whether we can hear that really is dependent on the number of actual dropped samples. And yes, the DAW can continue to run "just fine" under those circumstances, because it's running the session across multiple CPU cores. However, a given plugin instance can itself max out the CPU load of the single core that its DSP thread is actively running on, and can thus drop samples if that core is unable to keep up, even if the rest of the session runs as expected.

In any case, I've added this entire report to the tracker and will be looking into this during this current maintenance update cycle. Thanks for the report, and again, sorry for any misunderstanding here!

[DCrown]

The GUI kinda supports higher cpu usage and quite long loading times and value changes.
As soon as I change to Reaper UI everything is fine.
It's sad that gui is making plugin worse.
A simple, less ressource eating gui would be appreciated, no need to make it look like hardware imo.

The UI itself shouldn't impact CPU usage in any notable way, nor should there be long loading times. Of course, if you're experiencing issues, please open a support ticket.

That being said, for workflow reasons, by popular demand, we will be adding a minimalist UI option to this and all of our other analog modeled plugins in a forthcoming free update.

I know three more people plus two more people posted issues with ui in this thread.
There's definetely something wrong with your gui, when I switch to simple Reaper gui everything is fine. No other dev that I know has plugins with gui causing issues.
Don't be too proud to admit you are not an accomplished professional plugin dev or that there are devs who do their job better, you still can improve, so you you still have tasks and challenges and that's a good thing, I think.

I hope your simple ui option will be without these issues.

I am not referring to the look, even though it's awful, too, you can't hardly read anything, also in preset browser, it's about responsiveness that slows down work flow drastically.

Your reaction is kinda surprising tho'