Swanky Amp (release 1.4.0)

[garrinm]

Garrin - I hope you don't mind these little side discussions. They *are* related to amp sims - but we can take them elsewhere if you prefer

Quite the opposite in fact. There's some good information being surfaced, I'm learning about potential future directions, all good stuff.

I've got my head down right now getting preset management into the plugin and revising the power sag model. Modelling the transformer's contribution to power sag certainly could be interesting. Spice is already capturing some of the effects described in the discussions above related to the resistance of the coil. So that would be incorporated in the model as-is since, among other things, I'm fitting the change in signal through the OT.

However spice is not simulating saturation or hysteresis (though I'm sure it's possible with the right directives). That could be an interesting effect to try to chase down, but Dave's expose is doing a great job of keeping me focused on other issues I need to nail down before embarking on such a wild goose chase.

I use WOS but use many free IRs and RedWirez. I also own Ownhammer etc. But Kathellan and God's Cabs are free I do believe and many could be sank into the IR section of Resonant Amp

I plan to include an IR loader, and maybe I'll just put links for users to find these IRs online. I can't just put them into the repository or redistribute them with the code because, in spite of being free, that would be a copyright violation (the free IRs I've looked into have non-redistribution stipulations). Might look into it some more though if the need for IRs packaged becomes really pressing.

EDIT: reading a bit more carefully over the Aiken article, I see it was about the power transformer, not the OT. That's a direction I hadn't considered and wouldn't be that hard to emulate. Well... not including saturation and hysteresis. I still think I'll get more mileage out of focusing on making sure the model correctly accounts for general plate voltage changes, rather than focusing on nailing down the sources of plate voltage drop. So for now this is going to have to take a backseat.

EDIT2: the power transformer *as well as* the output transformer, as has been brought to my attention.

[garrinm]

I tried it out Reaper on Windows 10. The little amount I spent with the settings I had no issues. The interesting thing is its sounds and feeling it gave me. I am so impressed. This is a sound palette that I will cherish. It being open source is also impressing me.

I guess Linux is possible since it is Faust and JUCE or am I wrong? A PayPal account to donate to?

Hey, thanks for dropping a line in here, I'm glad you're enjoying the plugin in its current state.

You know, when I started doing this I had eyes towards linux support. I'd love to throw this on a raspberry pi someday. Sadly it would've been a completely different effort to set up this project to build LV2 plugins. JUCE makes it so much quicker to get to a decent level of quality for Windows and Mac.

Anyway, it is open source, I made sure to keep the DSP fairly well separated from the UI so that it can be stripped apart and repurposed. If not me then hopefully someone will get around to making some kind of linux port for it. You could just strip out all the FAUST code and use something like faust2lv2 to get an linux plugin, but of course you'd get a completely generic UI (and some of those parameters are rather fickle without proper scaling).

I'm tinkering with the idea of making a paid version of the plugin, so no donation link for the time being (and don't worry, I won't be stripping down the current version or anything like that, I mean it's open source so it can already be forked and whatnot). If I change those plans I might add a donation link, but for now I'm just happy to give something back to the open source community.

[Kott]

Hi,

I've build Linux version (need micro patching), Standalone, VST and LV2 too. Packages for openSUSE may be obtained here:
https://software.opensuse.org//download ... esonantAmp
https://software.opensuse.org//download ... esonantAmp
https://software.opensuse.org//download ... esonantAmp

for other distros you can extract binaries or build by self

[garrinm]

Hi,

I've build Linux version (need micro patching), Standalone, VST and LV2 too. Packages for openSUSE may be obtained here:
https://software.opensuse.org//download ... esonantAmp
https://software.opensuse.org//download ... esonantAmp
https://software.opensuse.org//download ... esonantAmp

for other distros you can extract binaries or build by self

I was not expecting this! That's fantastic news. I dug around the RPM a bit and I'm not too sure what's going on here, seems there's some software out there to port JUCE to LV2? I did find on Google some leads pointing to the LV2 porting project.

Unfortunately I don't have a Linux box setup for audio at the moment so I can't test. But I'm really excited to see this ported to LV2.

I can definitely fix the powf hickup so you don't have to patch that if you re-build for future releases.

Thanks,
Garrin

[Kott]

Yes, there is LV2 support made by falkTX but it wasn't accepted in main tree https://github.com/DISTRHO/juce

I can definitely fix the powf hickup so you don't have to patch that if you re-build for future releases.

Thank you

I can submit PR for ResonantAm.jucer and Linux Makefile, so others can compile plugin more easily.

[kvraudio38]

Amazing that you made a Linux LV2 build. Can I request a VST or VST3 build, please?

[garrinm]

Amazing that you made a Linux LV2 build. Can I request a VST or VST3 build, please?

I think Kott did build a VST, at this link:

https://software.opensuse.org//download ... esonantAmp

[garrinm]

Yes, there is LV2 support made by falkTX but it wasn't accepted in main tree https://github.com/DISTRHO/juce

I can definitely fix the powf hickup so you don't have to patch that if you re-build for future releases.

Thank you

I can submit PR for ResonantAm.jucer and Linux Makefile, so others can compile plugin more easily.

Probably it'll be fine to put the linux makefile in the repo. I don't want to claim official linux support since it's a bit out of scope for me, but I'll be happy to make it as easy as possible.

I would be just a bit concerned about the jucer file though. Every time I change the version number or add files to the project I use pro-jucer to automatically update the relevant build files etc. I don't know if it'll play nice with those custom tags introduced in that jucer file. I'll play around with it and see if there are any consequences.

[guitarzan]

We may be already be past all this, but a current thread here on KVR explains a lot of what I was trying to get across about compression but in a far more comprehensive and technically informed way:

viewtopic.php?f=33&t=547791

Your average compressor would typically use some sort of envelope follower that essentially computes the desired gain reduction, then if we are currently compressing less we adjust the current gain reduction towards the target using attack dynamics and if we are currently compressing more we use release dynamics to gradually reduce the compression. So in a sense, you are never actually compressing by the computed amount, but rather you are constantly (ie. every sample) adjusting the gain reduction towards the current desired amount with the speed (or more generally dynamics) depending on whether we should be compressing more (use attack) or less (use release).

So most of the time when you see "attack time" and "release time" on a compressor, those are not really the times that the compressor spends on attack and release phase, but rather just the times that it would theoretically take to perform an attack or release (or in many cases some percentage of it, when IIR dynamics are used) if we had an input signal that suddently went from 0 to 1 and then after the attack is finished from 1 to 0 again; they don't really control the attack and release "times" as much as just the speeds at which you track the signal.

One thing that I'd like to make clear is that the attack phase starts as soon as the peak or RMS value crosses the threshold and the release phase starts as soon as it falls beneath the threshold. The attack time is the time that it takes until the full compression is applied. From your post I get the impression that you might think that the attack time is a delay after which we go in one fast jump from no compression to full compression: "and remembers that the reduction will be applied in the near future (the attack time)."

Another important thing is that you cannot compute one attenuation factor from the ratio that you then just apply for all samples. Instead the attenuation factor has to be calculated individually for each sample. I think this insight might help with your question "But what happens if the signal goes above the threshold AGAIN, at a higher level, before the attack time comes?". There is no "recomputation" because it needs to be computed per sample (peak/RMS) value anyway.

So this is why I was questioning predetermined baked-in attack and release times, but as I now understand it, you are getting envelope follower-like results with the method you are currently using?

I know it works, whatever you are doing, but as-is it seems to work fully as intendended only with the amp set very specifically right at the sweet spot between clean and overdrive, not so much when set fully overdriving.

I understand that you are still working on sag and making progress, so this info may be totally irrelevant at this point.

[garrinm]

I know it works, whatever you are doing, but as-is it seems to work fully as intendended only with the amp set very specifically right at the sweet spot between clean and overdrive, not so much when set fully overdriving.

I understand that you are still working on sag and making progress, so this info may be totally irrelevant at this point.

Hi guitarzan,

That discussion seems spot on. In the plugin I use a formulation of compression related to the dynamics of capacitors. In effect it does what is described: when the signal is over some level, some "bank" charges up with some rate proportional to the signal. When the signal drops below the level it discharges with some rate which can be different. These two rates work as attack and release times. And that bank is what is then used to calculate what is effectively the compression factor. This should behave like what was described there for the most part, with some subtle differences.

You'll be glad to know that, at great expense to my sanity, I've reworked the sag model. It started with tweaking, and trying to address the issue I identified, and many hours later, it's basically a new sag model, and I think it's much more true to what I had in mind for the behaviour. The key here is that the signal that causes compression is not the same as the output signal to the speaker. The compression is caused by any part of the amp which is drawing power. It's not only the audible signal reaching the speaker that draws power. It's a super interesting effect and I think it's very satisfying to listen to.

I'll find some time to document this a bit more. But for now I've got an update out, so give it a shot, trust your ears, and I'll see what improvements I can make. I feel like this time around though I have the right foundation to get a sound truer to what was expected.

[garrinm]

Update 0.5.0 is out! This is a big one. The main two three features are: preset management (and factory presets), better high gain support (with staging going up to 7), and a re-worked sag model. Beyond that there are a variety of small improvements throughout.

As usual you can find the download links, instructions, and change log on the github page:

https://github.com/resonantdsp/ResonantAmp

This is meant to be the penultimate update before beta. I'll post future plans here soon. Looking forward to hearing about this patch.

[prodigal_sounds]

Update 0.5.0 is out! This is a big one.

Who's awesome? You are. You're awesome.

Downloading now. Feedback to follow at some point.

[guitarzan]

I got a chance to check it out for just a few minutes…

THAT'S SAG MAN!!

Can't wait to get into it more later, but I think you're pretty much there dynamics-wise.

[garrinm]

Minor patch 0.5.1 incoming. Tweaked the tone stack to cut out some of the mud / boom that seems to always pile up. I also revisited the approach for separating the mids from the lows to get a bit more audible separation there.

https://github.com/resonantdsp/ResonantAmp

[garrinm]

I got a chance to check it out for just a few minutes…

THAT'S SAG MAN!!

Can't wait to get into it more later, but I think you're pretty much there dynamics-wise.

Who's awesome? You are. You're awesome.

Downloading now. Feedback to follow at some point.

Very much appreciated xD. Thanks for the comments.