Action Packed Weekend

I did a lot this weekend to protect the user from doing damage to my application. For example, while performing a measurement, it's usually not a good idea to muck around in the preferences and change the length of the MLS sequence. That length value is used for calculating the result of the measurement, and bad things could happen. I changed things now so that preferences are disabled during a measurement. :) In performing the work to clean up the "UI issues"¹, I had to introduce a lot of multithreading and locking to be safe. This was initially done in order to calculate the MLS excitation signal in the background so that the user doesn't have to look at a spinning wheel upon starting the application. After that thread was broken out, all hell broke loose (as expected). Most of those issues are cleared up now, and I break out threads for all sorts of processing. The UI is getting more refined each day. Another section of work focused entirely on making the evaluation version of my software. I had to put appropriate buttons and dialogs where they belong, and I started integrating the eSellerate system into my code. So far, that's a very smooth thing to set up. I just have a few issues relating to the registration integration to clear up. One example is that I have to put in a feature to allow the entry of serial numbers that were not obtained electronically, and ensure that a registered version of the software stays registered. :) This morning at around 7:30, I noticed a broken build email in my inbox. Sure enough, the build had broken in a way that I had not earlier anticipated. What happened was that the eSellerate library needed to have ranlib run on it, and hence the deployment build broke. What's odd is that the development build I was using never failed. So I guess my daily build process paid off. :) There were a lot of smaller bugs fixed this weekend as well. One in particular was a "bug" relating to the quality of measurements done with an order 19 MLS. An order 17 MLS measurement would be okay (quality-wise), 18 would be better, 19 was worse than 18, and 20 was far better than 18. This is bad, since getting higher-quality MLS measurements is supposed to be a feature that differentiates FuzzMeasure from other packages.² Sure enough, the polynomial I was using was to blame. It was a perfectly valid primitive polynomial, but for some reason my Fast Hadamard transform turned it into a crappy impulse response. I chose a different characteristic polynomial for order 19, and it was perfectly fine. ¹ More specifically, I was working on cleaning up any UI glitches that would allow the user to shoot themselves in the foot. Most of the stuff I did to reproduce the problems was quite ridiculous, but I had to close them all out anyway.
² Actually, FuzzMeasure can produce arbitrarily large MLS sequences, as long as I let the software do it. Right now, an order 23 MLS will take a good chunk of time to calculate, and it will take over 3 minutes to play back! I plan to limit my software at 19 for the standard edition, and I may offer a professional edition in the future that allows for longer sequences. If people need more than that, they can let me know! ;)