The problem as others have pointed out is that most musicians in the west already know some degree of western notation, so if you're collaborating, you'll have to translate back to western notation at some point. Even if you invent the perfect notation, it's like asking everyone to switch to esperanto because english grammar is flawed. And you'll still get people defending english "well actually, it's like that because the greeks blah blah blah".

My favorite music notation flaw is C flat. It's a hack. It's an ugly fucking hack and anyone who defends it is defending an ugly hack. The only reason it and double flats exist is because there are some key signatures (this happens with hungarian minor sometimes) where you end up needing to define 3 notes in the span of one space and one line on the staff, and you can't, so you have to borrow from an adjacent space or line. And so sometimes that C is actually a B. It's super annoying but uncommon enough that it's not worth everyone learning a new notation.

Anyway, don't let the nay sayers stop you from learning music however makes the most sense to you. Have fun

I wrote a longer replay to alterom but it looks buried for some reason.

https://news.ycombinator.com/item?id=48365800

[1] https://news.ycombinator.com/item?id=48365800

Taking a step back, remember we're ultimately mapping these discrete numbers to some real world continuous variable like the saturation of red, frequency, mass on a scale, whatever. And our digital device can only represent a finite amount of numbers. For 2 bit data, we can represent 0-3, and for 3 bit data we can represent 0-7.

The important part is that 0 represents the minimum and 1,3, and 7 all represent the same maximum real value, and everything that can be measured by the device will fall within those ranges. So comparing 1, 2 and 3 bit data on a linear number line looks like this:

  0                    1
  0      1      2      3
  0  1  2  3  4  5  6  7

The question is about how to normalize the data. 1 bit data is already normalized. If you normalize 2 bit data by 3 you get [0, 1/3, 2/3, 1]. LGTM. If you normalize it by 4, you get [0, 1/4, 2/4, 3/4] and you're effectively throwing away some of the range of the ADC. You can try to get it back by offsetting by 0.5 then normalizing but now you get [1/8, 3/8, 5/8, 7/8]. And you could stretch that with some clever formula to fill from 0 to 1, but if you do it right then it's the equivalent to normalizing by 3, so why not normalize by 3?

So the answer is, if you have N bit data, you normalize by 2^N-1.

You can see this confusion again in the histogram example. There are only 255 bins, not 256. If you fix that mistake and remove the 0.5 offset, then the histogram is distributed correctly at both ends.

https://www.jefflowenfels.com/