Rule of thumb for ranking resource hogging parameters in MTReverb? Should I burn impulses?

[Annabanna]

For whatever reason, I'm having difficulty when just looking at basic diagnostics in Logic seeing exactly which features in mTurboReverb are using the most resources. I'm stuck on an old version of Logic, and it seems maybe the meters are lagging or something. Going to restart in a minute to see if that improves.

In any case, I've developed some reverbs I like in isolation, but now that I'm dropping them into a session, I'm getting audio glitches, CPU spikes, etc.

I'm not suprised given how extreme some of my settings are, but I'm trying to make a list in order of rough priority as to which need to be dialed back so I can keep as much of the sound as possible.

Specifically, I've found I really like the sound of plate algos with with max 64 complexity and insanely long RT's (like max 60,000) where the decay is instead coming from the high and low dampening.

I understand the complexity increases CPU cycles, my "sparse" factor of 1 for the dampening uses more resources than higher values, etc. and perhaps it all depends heavily on the algo, but I'm wondering if there is some rough rule of thumb as to HOW important, for instance the complexity is vs length or some other parameter in terms of resource consumption.

Does anyone have a rule of thumb like that, or a rough ranking of the biggest resource hogging parameters?

Also, I haven't used the generate impulse feature yet. Is that a better option? If I just really want those extreme settings, could I burn an impulse, then maybe load it into an IR verb that can then add the modulation afterward? I haven't used SpaceDesigner in a while, so not sure if it can do the modulation, or what my best option would be for that on a Mac. Would that method sound the same without the resource drain?

If it matters, most of I'm working on now is based on the following algo:

2a;fa;fa;cc[#b[a];#[fh;fl]]

I haven't had time to dig into creating custom algos yet, but mention this just in case it's immediately obvious to anyone that this might have some sort of inefficient recursion or feature I may not be fully utilizing that could possibly be stripped out or modified to be more resource friendly at those extreme settings.

[jmg8]

I would say complexity (in the late reflections) has the most impact, followed by modulation, number of taps in early reflections and sparse (in dampening filters). Complexity (in most cases) multiplies everything. For example if the algorithm uses 2x allpass filters, 4x comb filters and 2x dampening filters, then you have complexity set to 20, you will have 40x allpass 80x comb and 40x dampening filters.

[Annabanna]

I would say complexity (in the late reflections) has the most impact, followed by modulation, number of taps in early reflections and sparse (in dampening filters). ...

OK, thanks. I'll keep that in mind. I notice you didn't mention length. I ask about that one because it reminds me of how it hadn't occurred to me until someone on here pointed it out that I was chewing up resources by having my MSF default global envelope parameters dragged all the way out because I was using other envelopes per voice within the plug.

Is there anything like that going on with the length where having it dragged all the way to max 60k is problematic in ways I may have missed?

Also, do I understand correctly that if I were to burn the impulse, is there a way to do that so I can use it in some IR verb that then adds it's own modulation? Is the result the same as running through the original convolution patch? I'm assuming the modulation isn't baked into the impulse, but not sure whether other things are like the damping, EQ, dynamics section.

[jmg8]

You could load the IR into MConvolution, it has modulation options built in.
As for length, it will not affect CPU. In MSF it does because as you play you will be stacking up hundreds of voices. Even if the filter makes the voice not audible (using a filter envelope) the global envelope makes it play for a long time and when you play other notes they get stacked. You can easily get to 100s of voices and the CPU is high. You can set the release hight at the start while you design the sound and then when you see how long the filter envelope will be, go and shorten the release to something similar. In reverb it is different, length and size are controlling the go in the algorithm such as delay times and feedback amounts, but this will not use more CPU.

[jmg8]

You could load the IR into MConvolution, it has modulation options built in.
As for length, it will not affect CPU. In MSF it does because as you play you will be stacking up hundreds of voices. Even if the filter makes the voice not audible (using a filter envelope) the global envelope makes it play for a long time and when you play other notes they get stacked. You can easily get to 100s of voices and the CPU is high. You can set the release high at first while you design the sound and then when you see how long the filter envelope will be, go and shorten the global release to something similar. In reverb it is different, length and size are controlling things in the algorithm such as delay times and feedback amounts, but this will not use more CPU.

[jmg8]

Hehe, I tried to edit a few typos but ended up quoting myself.

[Annabanna]

Hehe, I tried to edit a few typos but ended up quoting myself.

I've done the same more than a few times.

Very helpful, thanks.

[Starship Krupa]

This is a general answer to your more specific inquiry: I've found that in Meldaproduction plug-ins that support oversampling, using even 2x with the "High Quality Oversampling" option (which is enabled by default) has a detectable impact on resource usage. It also induces latency. 2x without it has less impact.

As Meldaproduction say in the documentation, "use this feature ONLY if you can actually hear the difference." I typically set my oversampling to 1x for Normal (playback) and 2x for rendering.

This may or may not be relevant to what you're doing with MTurboReverb, but if you're trying to shave CPU cycles it might help.

[MeldaProduction]

That's quite impossible to predict really. Obviously the mentioned oversampling will literally multiply the CPU consumption. But when it comes to algorithm - thing about MTR like "a reverb, that can do anything". It can be as simple as a single echo, but it also wouldn't be hard to put modules inside various feedback paths and at the end... you'd need a supercomputer