(deleted a message where I posted some incorrect test results)
I don't see any serious bugs in the %exx eq routine. Just in case there's some weird bug that I'm not seeing, you could try emailing me a copy of your mpxttsr.cfg file.
MpXT and MPXF use the first 28 columns of MPXPlay's 32 column specrum analyzer display. If you use â0 MpXT takes 28/20, which is 1.4 It starts at column 1 then increments by 1.4, then keeps going till it gets to column 28. So for â0, starting at column 1, incrementing by 1.4 and dropping the decimal points, it ends up reading the following columns from MPXPlay's spectrum analyser display:
1, 2, 3, 5, 6, 8, 9, 10, 12, 13, 15, 16, 17, 19, 20, 22, 23, 24, 26, 27
For â2 it would take 28/22 which is 1.27 So starting at 1, and incrementing by 1.27:
1, 2, 3, 4, 6, 7, 8, 9, 11, 12, 13, 14, 16, 17, 18, 20, 21, 22, 23, 25, 26, 27
For whatever %exx value one chooses, MpXT tries to poll MPXPlay's spectrum analyser as evenly as possible.
MPXF had a bug in it, which caused it to always increment by 1, for á5 and higher. For example, with â0 it would just use columns 1 through 20 on MPXPlay's specrum analyzer and drop the rest.
But because of this little quirk in MPXF, it actually produced better looking eq's. Here's why:
MPXPlay's specrum analyser is kind of strange. It starts out at 639hz, then continues in a linear fashion to 1378,2067,3445,...,22050. Basically all of the bass gets ignored. Most people can't hear frequencies above above 16khz, but MPXPlay has 9 eq bands that are above 16khz. In the end one ends up with a really weird looking display.
I could go back to the MPXF way of picking which frequecies to display, but what if a new version of MPXPlay came with a nicer looking logrithmic specrum analyzer?
Better yet, I could implement both. Perhaps make %e mean "MpXT-style eq", and %f mean "MPXF-style eq".