Coming Soon: The Relab 176 (Retro 175) Tube Compressor/ Limiter

[vitocorleone123]

The Windows CPU usage in the current state makes it impractical. So get that. But the sound is something else. Let's see how these optimizations go.

It’s clearly designed to sell to Apple users more. They coded it as a single thread rather than adding some latency and designing it for multithreaded CPUs (which, then, could penalize Apple users).

[Touch The Universe]

Maybe I'll actually try demoing this one

[Touch The Universe]

I ended up parting with the cash today and buying. Even after a week with some brutal home repair bills. But there's no way I'm not buying this.

How do you think Funkybot is going to take this news?

The good one would have waited until he could afford it.

[Ploki]

The Windows CPU usage in the current state makes it impractical. So get that. But the sound is something else. Let's see how these optimizations go.

It’s clearly designed to sell to Apple users more. They coded it as a single thread rather than adding some latency and designing it for multithreaded CPUs (which, then, could penalize Apple users).

Bruh you’re twisting what i wrote


Multithreading doesnt magically reduce CPU usage and is not as simple as “more latency” - more complex scheduler means more overhead.
U-He synths on M chips smoke many intel offerings and u-he synths were coded before M chips were out

They’re not favoring M chips, apple just made better chips for the job.

I was trying to explain to you why making an audio process multi threaded isn’t as simple as “make multithreaded” and that it adds complexity and latency, and now you’re twisting the reality of what i said. I didn’t say that it would reduce CPU usage, if anything it adds overhead.

This wasn’t designed to sell more to apple users, ever since M chips came out people have been touting how good they are for audio processing.

All in all, multithreaded design would very likely make CPU performance WORSE.

[kraster]

Multithreading a compressor plug-in would be a weird thing to do. By their nature compressors are sequential since each sample needs to be “state aware” ie. It must know what the previous sample was for things like attack smoothing or feedback loops.

Audio buffers are small so distributing each buffer across multiple threads would be enormously complex and really inefficient.

Certain things like the gui could be run on a different thread but there wouldn’t be much of a benefit.

Multithreading is great for parallel tasks like running different instances of a plug-in but that would be handled by the daw.

M chips are known for their single threaded performance due to specific design factors and integration with the OS.

AFAIK the 176 was designed on PC exclusively so there’s little evidence of a deliberate ploy to cripple performance on PC to appease Mac owners.

[bmanic]

I mean, isn't the mojo part the crux of Analog vs Digital usually?

No, not when it comes to compressors. There's some "magic" in how the compression itself works, not just the harmonic fingerprint but the dynamics control itself. Though it could very well be that some of the control is actually a by product of the mojo (soft clipping within the circuit).

There are some truly impressive analogue compressors out there that just compress stuff extremely effortlessly in a way that mostly eludes digital equivalents.

[Ploki]

I mean, isn't the mojo part the crux of Analog vs Digital usually?

No, not when it comes to compressors. There's some "magic" in how the compression itself works, not just the harmonic fingerprint but the dynamics control itself. Though it could very well be that some of the control is actually a by product of the mojo (soft clipping within the circuit).

There are some truly impressive analogue compressors out there that just compress stuff extremely effortlessly in a way that mostly eludes digital equivalents.

Fair.

Which ones are you thinking of?
Btw do you mix/master ITB or hybrid?

I still think that the 176 is one of the most (if not the most) detailed analog emu tho

[vitocorleone123]

The Windows CPU usage in the current state makes it impractical. So get that. But the sound is something else. Let's see how these optimizations go.

It’s clearly designed to sell to Apple users more. They coded it as a single thread rather than adding some latency and designing it for multithreaded CPUs (which, then, could penalize Apple users).

Bruh you’re twisting what i wrote


Multithreading doesnt magically reduce CPU usage and is not as simple as “more latency” - more complex scheduler means more overhead.
U-He synths on M chips smoke many intel offerings and u-he synths were coded before M chips were out

They’re not favoring M chips, apple just made better chips for the job.

I was trying to explain to you why making an audio process multi threaded isn’t as simple as “make multithreaded” and that it adds complexity and latency, and now you’re twisting the reality of what i said. I didn’t say that it would reduce CPU usage, if anything it adds overhead.

This wasn’t designed to sell more to apple users, ever since M chips came out people have been touting how good they are for audio processing.

All in all, multithreaded design would very likely make CPU performance WORSE.

I wasn’t replying to you here, but thanks for jumping in.

With your expertise, can you explain how Audiogridder makes it so that the same compressor (Relab 176) can have a lot more instances running - more than just increasing the ASIO buffer, and seems to be having the load spread across cores on the same machine? Genuine question.

[Aloysius]

I think when a product is so expensive, many of us do not want to give it a fair chance, in case we fall in love with it and decide that we can't live without it. It may or may be great. I don't know. I'm not going to test it, just in case.

[Ploki]

The Windows CPU usage in the current state makes it impractical. So get that. But the sound is something else. Let's see how these optimizations go.

It’s clearly designed to sell to Apple users more. They coded it as a single thread rather than adding some latency and designing it for multithreaded CPUs (which, then, could penalize Apple users).

Bruh you’re twisting what i wrote


Multithreading doesnt magically reduce CPU usage and is not as simple as “more latency” - more complex scheduler means more overhead.
U-He synths on M chips smoke many intel offerings and u-he synths were coded before M chips were out

They’re not favoring M chips, apple just made better chips for the job.

I was trying to explain to you why making an audio process multi threaded isn’t as simple as “make multithreaded” and that it adds complexity and latency, and now you’re twisting the reality of what i said. I didn’t say that it would reduce CPU usage, if anything it adds overhead.

This wasn’t designed to sell more to apple users, ever since M chips came out people have been touting how good they are for audio processing.

All in all, multithreaded design would very likely make CPU performance WORSE.

I wasn’t replying to you here, but thanks for jumping in.

With your expertise, can you explain how Audiogridder makes it so that the same compressor (Relab 176) can have a lot more instances running - more than just increasing the ASIO buffer, and seems to be having the load spread across cores on the same machine? Genuine question.

(You did, crossforum).
Have you tested with audiogridder?
I haven’t seen any meaningful post about it, just that it reduces DAWs cpu meter (duh).

I have limited knowledge of audio gridder, but if it adds enough latency (supposedly it adds about 130ms by default) it can effectively work as “offline” processing with small intermittent droputs if it gets enough time within that 130ms to reconstruct the signal. The processing is done outside the DAW and can do thread scheduling differently and can split audio into chunks. I bet my ass it works at higher buffers than 128/256 of your DAW, hence the huge latency.

That isn’t feasible for a playback audio engine because it runs on DAWs processing clock. (Think of it as realtime vs offline bounce).

This is speculation.
Would have to try it tho but i doubt i’ll get meaningful results on an M1.

The jist of why it works better on M vs intel:
- Memory latency (many people think apple’s practice of soldering RAM is greed / it is, but it also reduces memory latency by a lot)

- L2/L3 cache (M chips have a lot)

[VitaminD]

I ended up parting with the cash today and buying. Even after a week with some brutal home repair bills. But there's no way I'm not buying this.

How do you think Funkybot is going to take this news?

The good one would have waited until he could afford it.

That makes sense to me. Whenever I want something, I save until I have the full amount and do lots of research. I've found sometimes my desire has waned by the time I am ready to buy.

But I was mostly making a joke about his account names (there is a Funkybot on another forum, seemingly him too).

[Funkybot's Evil Twin]

Trust me, as his evil twin, or even the man himself in disguise on KVR*, Funkybot isn't buying anything he can't afford. Discretionary spending just mentally hurts a bit more after a big non-discretionary outlay like home repair bills. I'm not going into debt for plugins. I just hate paying bills.

*My original "Funkybot" KVR account got locked years ago and was tied to an old email address so I created the Evil Twin account here.

[kperry]

iLok so no go here.

[martinjuenke]

iLok so no go here.

Why?

[kperry]

It won't install on my machine (no idea why) and it's always been a bit of a PITA anyway.