EQ seems to give odd results?

[saridnour]

I am just trying to include a small EQ on my display (a bit of flash) and this config does work, it just doesn’t follow what an EQ really should be displaying on the last few bars with the music being played. I set up the EQ on the last line of my 4x40 and am seeing some odd results. The last few bars seem to be active at odd times (like it’s reading the incorrect bar values). I was wondering if this was maybe due to the EQ values changing in MPXplay and the tsr is not grabbing the correct lines?  

I have tried a number of different EQ configs from the list provided, but none seemed to correctly produce the effect of an EQ with the exception of “â2”. I currently have my LCD set with these parms:

[Line1]
LineAValue=1
LineATime=0
LineAScroll=True

[Line2]
LineAValue=Time %ftm  Playlist:%m3u
LineATime=0
LineAScroll=False

[Line3]
LineAValue=%brt %y68
LineATime=0
LineAScroll=False

[Line4]
LineAValue=â2                 <--------------  EQ  
LineATime=0
LineAScroll=False

Any ideas as to what might be going on here?

Thanks in advance…

[admin]

Many of the eq routines were rewritten for MPXT.  So, there's a good chance that I could've missed something while I was testing it.  When I update MPXT for Beta 2, I'll take a look at it.

[admin]

(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".

[admin]

I decided to go back to the MPXF way of displaying the EQ/Spectrum Analyzer.  It may be less "correct" but it does look a lot better.