Satin's internal precision.

[sleepcircle]

I notice that Satin (and Twangström and, really, a few other u-he plugins) output their signals in 32-bit. I assume that the calculations are performed—within the plugin itself—in 64-bit precision, though, am I right?

[Urs]

I notice that Satin (and Twangström and, really, a few other u-he plugins) output their signals in 32-bit. I assume that the calculations are performed—within the plugin itself—in 64-bit precision, though, am I right?

Some of it, but not all of it. I think most of it is done in 32 bit. Why?

[sleepcircle]

Oh, partly academic interest and partly idle curiosity, hahah. Thank you for your prompt response.

[Urs]

Yeah, I'm not much of a fan of 64 bit precision when it isn't needed. We do a lot of SSE optimization which really only pays of in 32 bit, and why not when the difference is absolutely inaudible.

Maybe in a few years when AVX is everywhere and 4 double precision operations can be done at once. But as long as my development machine doesn't fully support AVX2 with FMA, not on my priority list

[sleepcircle]

Quite understandable—thanks again

[EvilDragon]

AVX is in a loooooooot of devices. I mean it was introduced 7 years ago...

[Urs]

AVX is in a loooooooot of devices. I mean it was introduced 7 years ago...

In various different flavours... one kind of has to query the CPU as to which features it supports... or so.

[EvilDragon]

Ah. That makes it trickier, I see. Gotcha.

[sleepcircle]

that's part of the programmer's dream, isn't it? "hardware manufacturers adhering to a standard instead of all feeling obligated to put their own special twist on it."