Hi,
thank you all for the interesting discussion posts on denorms and
fixed-point/floating-point processing.
I have a problem that is very much related to the arguments posted by B.J.,
mentioning the lack of saturation arithmetics on x86/x64 processors.
I need to convert a batch of 32 bit float
Moin,
Seems the problem only exists for positive numbers where some lower bits are
zero instead of one.
I would suggest to clip and convert first, then construct a mask to be or-ed to
the result using the original float.
Positive comparison value should have 24 bits (23 + implicit) to match flo
Without time to listen to your example Yisheng I'm just voicing a
theoretical/academic take; When it comes to LTI (linear time
invariant) systems order doesn't matter. With time variant systems it
does.
As a very concrete practical example, I made some "rain" weather FX
patches that employ short e
Hello,
I'm no SSE expert either but I would exploit IEEE 754r single precision
floating point representation.
Essentially you have that 0x4f00 represents 2147483648.f while
0x4eff represents 2147483520.f. OTOH, in 2's complement 32 bits,
0x7fff is 2147483647 and 0x8000 is -21
Stefano’s solution is elegant because it exploits the fact that values outside
the range are all set to 0x8000.
But the implementation is a bit overcomplicated, this works as well with less
instructions, same result:
int main()
{
const __m128 sseFloatInput = _mm_set_ps(1000.f, -1000.f, 3
I'm also very much emjoying this thread and realise that the focus is
on microprocesor ALU behaviour.
But to widen it a little, let's remember that compilers and languages
are in many senses inseperable from silicon in modern computing.
Returning to the spirit of the OP - that surely in 2023 we s
Sorry for spamming, but I am obsessive about optimisations and cannot spare you
the version with one less instruction:
int main()
{
const __m128 sseFloatInput = _mm_set_ps(1000.f, -1000.f, 30.f,
-30.f);
const __m128 fcmp=
_mm_set_ps(0x0FFp3f,0x0FFp3f,0x0F
Yeah, Stefan's version is easier/better.
It only needs an extra _mm_castps_si128() to compute m, which costs nothing.
Best,
Stefano D'Angelo
Il 26/04/23 10:42, Stefan Stenzel ha scritto:
Sorry for spamming, but I am obsessive about optimisations and cannot spare you
the version with one less
That code snippet would be a good addition to the musicdsp source code archive:
https://www.musicdsp.org/en/latest/Other/index.html
Best,
Steffan
> On 26. Apr 2023, at 10:50, Stefano D'Angelo
> wrote:
>
> Yeah, Stefan's version is easier/better.
>
> It only needs an extra _mm_castps_si12
OK, but first needs some bug fixing, here a corrected version with the proper
constant for comparison:
//src/dst must be aligned
void float2intx4(__m128 *src, __m128i *dst)
{
const __m128 fcmp = _mm_set_ps1(0x00FFp7f);
const __m128 sseFloatInput = *src;
__m128i x = _mm_cvtp
Sorry, one more fix, I’ll keep silent now.
//src/dst must be aligned
void float2intx4(__m128 *src, __m128i *dst)
{
const __m128 fcmp = _mm_set_ps1(0x00FFp7f);
const __m128 sseFloatInput = *src;
__m128i x = _mm_cvtps_epi32(sseFloatInput);
__m128i m = _mm_cmpgt_ps(sseFloat
Thank you very much for the quick answers, Stefan, Stefano and Steffan (what a
coincidental match... :-)). That was very helpful.
I had to add one more (no-op) instruction to get the types correctly (may be
related to the Microsoft compiler, not sure):
void float2intx4(__m128 *src, __m128i *dst
Hey thanks for the feedback. I was worried it might not be the same effect..
By recalc the transform function I meant computing the a0, a1, b0 etc, which
takes a large chunk of my rendering cycle..
In any case I will generate some wav files and see what the outcome is..
Sent from my iPhone
> O
Sorry I was unclear in my original email. This is separate from the amplitude
envelope.. I’m talking about a modulating envelope that’s only connected to the
resonant frequency of the filter.. it shifts it by about 1-semitone over the
course of 1 second or so..
Sent from my iPhone
> On Apr 26
A less mathematical way to show why this doesn't quite work: If you have a
resonant filter and you want to modulate it from frequency A to frequency
B, you would expect that resonant peak to "sweep" from one frequency to the
next. If you instead use two filters/streams and crossfade between them,
y
Yeah that’s a good way to look at it.Sent from my iPhoneOn Apr 26, 2023, at 11:16 AM, N G wrote:A less mathematical way to show why this doesn't quite work: If you have a resonant filter and you want to modulate it from frequency A to frequency B, you would expect that resonant peak to "sweep" fr
The only place I’ve seen arbitrary precision arithmetic used in audio is in
coding. If you’re doing arithmetic coding or FPC or similar, you need to do
arithmetic operations on words of large, potentially variable size (hundreds of
bits, say). This is still fixed point, and is not really in the
17 matches
Mail list logo