Parameter input range

[BertKoor]

What I meant was, if you only count to 8388607 in unsigned 32bit int, the top 9 MSB will never change in value.

So you really meant to say that 9 of the 32 bits are being wasted? I don't think there's a viable alternative. Word misalignments in memory is also very expensive (in CPU cycles).

[juha_p]

What I meant was, if you only count to 8388607 in unsigned 32bit int, the top 9 MSB will never change in value.

So you really meant to say that 9 of the 32 bits are being wasted? I don't think there's a viable alternative. Word misalignments in memory is also very expensive (in CPU cycles).

https://www.binaryconvert.com/result_un ... 6054048055

[BertKoor]

https://www.binaryconvert.com/result_un ... 6054048055

No need for mansplaining...

[Music Engineer]

If you need to work with a normalized range, then 0..1 seems the most natural and most convenient choice.

...but that is actually a big "if". We have taken that for granted for 25 years because it was the VST way of doing it. CLAP actually does away with that and communicates parameter changes to the plugin as plain values (...and in double precision, ...and as events on the audio-thread). The decision for plain values transfers a bit of the computation of the automation lanes from the plugin to the host. Since there are far more plugins than hosts, that seems to be a good thing from a utilitarian point of view - here: minimizing the amount work for the greatest number of programmers, i.e. centralizing the work. Ah - and the decision to communicate them on the audio-thread also transfers the thread-sync handling for parameter changes to the host - same story with centralization of work. And it's less susceptible to bugs, too. Just the host needs to get it right once and for all. Not every plugin needs to get it right individually.

[mystran]

What I meant was, if you only count to 8388607 in unsigned 32bit int, the top 9 MSB will never change in value.

If we have a 32 bit integer, then as long as there are at least 8 leading zeroes, there are at most 24 bits that can have any value (ie. either one or zero). If the first bit after the 8 zeroes is one, then that's the "implied one" in the single-precision float and then we have exactly the remaining 23 bits available to store the rest of it. If there are more than 8 leading zeroes, then the exponent gets smaller and we have "too many" mantissa bits, so some LSBs will be zero if we're storing an integer.

It's also kinda fine if there are 7 leading zeroes, a one and then 24 zeroes. That's the value 2^24 (=16777216), the next value up from the range of 24 bit (unsigned) integers and we can kinda store that exactly too.. but we can't store 1+2^24, because we would need one more mantissa bit.. rather the next value up that we can store is 2+2^24.

So your "up to 8388607" is half the range of unsigned integers that we can store exactly.

[S0lo]

I didn't say mantissa is 23 bits. Sure there is 1 bit that is omitted because it's always one. And sure mantissa is normalized.

Well, in a sense the mantissa is 24 bits only 23 of which are stored (with the first one implied, unless the number is denormal, which we'd rather not exist at all when it comes to audio). In another sense the mantissa is 23 bits, because that's how many bits are actually allocated to store it. Depends on whether you think of values or bit patterns.

I'm willing to accept either or neither or both. Whatever you like. Not that any of that matters.

Either way, the important part is that a single precision float can store unsigned integers of up to 24 bits exactly.. and for signed we can actually store the equivalent of 25-bit(!) 2s complement integers exactly (because the integer loses one bit to sign and we don't), so really a single-precision float is strictly one bit better than a signed 24-bit fixed point over the whole range (and obviously a whole lot better at lower signal amplitudes).

Right. The increased density of representable float values around zero, be it because of the rapid exploitation of the exponent or because of the availability of the two states of the sign bit in the -1 to 1 (or any bipolar) range is all understandable. No questions about that. Yet I claim that it doesn't matter in about two thirds of the cases when it comes to parameters (explained above). And even for the remaining one third that it matters, it's like, "emmm, yyyyyeah right it's good enough already". But since no one seams to be interested. No need to explain further

So.. just in order to be controversial I'm going to count both the signbit and the implied leading one as being part of the mantissa, so that I can claim it's 25 bits. In doing so I have managed to pack 25+8=33 bits into a 32bit word, so clearly we have managed about 3% compression and if we perform this conversion about 23 times recursively, we can compress any file to less than 50% of it's original size. Please discuss.

I appreciate the effort to make things interesting. But I'll have to disappoint you, genuinely not interested.

[earlevel]

Hi earlevel

For single-precision float (assuming IEEE 754), the mantissa (or significand) uses 23 bits and the exponent uses 8 bits. Additionally, there is 1 bit reserved for the sign of the number, making a total of 32 bits used to represent a float.

So your basically playing with 23 bits for the 0 to 1 range...

Pardon the trivia, but the mantissa is normalized and the leading 1 is omitted, so you have 24-bits of mantissa, not counting sign.

But it works out better than plain 24-bit—overall ........

Thats why I said:

the mantissa (or significand) uses 23 bits

I didn't say mantissa is 23 bits. Sure there is 1 bit that is omitted because it's always one. And sure mantissa is normalized. References:
...

Um, not doing this to beat the point to death, but to clarify...there are 23 actual mantissa bits in float32. The implied bit from normalization makes 24. (For completeness: The sign bit makes 25-bit equivalent—relative to two's complement format—but didn't applicable for the 0..1 range we're discussing).

Back to the original comment I replied to:

So your basically playing with 23 bits for the 0 to 1 range...

It almost sounds like you're saying there are only 22 actual bits available plus the implied bit. Or I'm not reading you right. In any case, I think everyone here knows what's going on—24 bits of precision are available, in addition to the scaling as values get smaller.

[S0lo]

So your basically playing with 23 bits for the 0 to 1 range...

It almost sounds like you're saying there are only 22 actual bits available plus the implied bit. Or I'm not reading you right. In any case, I think everyone here knows what's going on—24 bits of precision are available, in addition to the scaling as values get smaller.

As I said above, later in the same post:

...Point is, the 23bit of float mantissa is not really the limiting factor when you think of it. Except for DAW originating automation.

[earlevel]

So your basically playing with 23 bits for the 0 to 1 range...

It almost sounds like you're saying there are only 22 actual bits available plus the implied bit. Or I'm not reading you right. In any case, I think everyone here knows what's going on—24 bits of precision are available, in addition to the scaling as values get smaller.

As I said above, later in the same post:

...Point is, the 23bit of float mantissa is not really the limiting factor when you think of it. Except for DAW originating automation.

Sorry, man, you've lost me. You keep saying there is one bit fewer than there is, no matter how you state it. There are 24 bits. 23 happen to be stored, but there are 24 bits plus sign.

It's not important. It's just that you dismissed my first comment as if I had made a mistake in understanding. So I was just clarifying why I made the comment. And maybe I have misunderstood your comments in some way, but you still haven't cleared them up, you seem to be saying the same thing.

Just to be clear for the casual reader, here's float32 with 23 bits; not shown is the implied 24th bit, which doesn't need to be stored due to the automatic normalization:

Screenshot 2024-04-04 at 5.40.26 PM.png

[S0lo]

Sorry man, but as you said above:

....Or I'm not reading you right. ....

Emphasis on the underlined above.

[earlevel]

Sorry man, but as you said above:

....Or I'm not reading you right. ....

Emphasis on the underlined above.

LOL. Let's quit while we're ahead. Believe me, I am reading every word you write. Two or three times.

OK, we have 24, so what's the point is saying that 23 aren't a limiting factor? I don't get it. The fact is, we could probably say 22 aren't a limiting factor as well. But...we still have 24...

Sorry, I understand your words, I don't understand your point. Telling me to re-read them, twice now, isn't getting anywhere.

[S0lo]

Isn't the 24th bit always 1 ?

(Edit: I mean the 24th bit of the mantissa)

[S0lo]

Isn't the 24th bit always 1 ?

(Edit: I mean the 24th bit of the mantissa)

Except for the case of value = 0 ofcourse. And I think denormals.

[earlevel]

Isn't the 24th bit always 1 ?

(Edit: I mean the 24th bit of the mantissa)

LOL—thank you, it's now clear what you meant. Appreciate it.

But there are always 24 bits in use, of significance (until we get denormalized, but that's not applicable here, it just lets us get super tiny around zero). I think you're not taking into account the effect the exponent has.

1.0 = (1)00000000000000000000000 x 2^0

The next smaller numbers are

(1)11111111111111111111111 x 2^-1
(1)11111111111111111111110 x 2^-1
(1)11111111111111111111101 x 2^-1

When we get to (1)00000000000000000000000 x 2^-1, the next smaller number is

(1)11111111111111111111111 x 2^-2

Normalizing the leading bit to 1 is the only way to ensure that we always have 24 significant bits. The fact that it also means we can omit storing it doesn't mean it's not significant.

The result is that we have increments of step size (using a binary point) 0.00000000000000000000001 x 2^-1 between 0.5 and 1.0. We can rewrite that as 1 x 2^-24. In other words, it's the same step size as if we'd used a 24-bit integer. (It gets better as we go lower, the step size cuts in half from 0.25 to 0.5, and so on towards 0.)

tl;dr: The important point being that the worst-case step size is 24-bit accurate, not 23.

I hope I explained that clearly. Does my explanation make sense to you?

[S0lo]

tl;dr: The important point being that the worst-case step size is 24-bit accurate, not 23.

I hope I explained that clearly. Does my explanation make sense to you?

Yes nice. But your first objection wasn't on step size. It was about that I seamed to claim that the mantissa is 23 bits. I claim I didn't.