After today's Capricon meeting, I had some free time that I used to take the Behringer X-Touch Extender down to the basement so I could try hooking it up. Naturally, I read the manual first. It was not of as much help as I might have hoped it would be, as it showed two setups. One connected the X-Touch Universal to the computer via USB and cascaded the X-Touch Extender through the first X-Touch; the other connected both units to a network hub.

Of course, my X-Touch Universal is connected via a couple of MIDI cables that run through my Midisport 4x4, because I was never able to get the USB connection to work. Well, let's see what happens.

I connected the Extender to the Universal via USB. Nothing recognized it.

Well, let's try updating the firmware on the Universal. That took a while, but when I was done, it still didn't recognize the USB connection to the Extender.

Ok, let's put them both on the network.

Yeah, that took a while to configure. I couldn't get it to work either.

Maybe I can get the USB connection to work if I connect the Universal to the computer directly. Of course, it still doesn't recognize it.

Let's open Device Manager and see what's going on. Oh, look! There's the old Tranzport remote. I guess I should uninstall that. The computer still doesn't see the X-Touch.

Oh, to heck with this. I'm running out of USB ports on the computer. I've got two of the Steinberg dongles, so I'll move all of the licenses to one of them and that'll free up a port. That didn't take long.

Now, let's unplug everything and start plugging it back in. You there! Midisport! You are the weakest link. I only needed you to talk to the ADATs anyway.

Look at that! Suddenly the computer sees the X-Touch.

And when I go into Cubase, it sees both the X-Touch and the cascaded extender.

I think I'm going to declare victory.

I hate hardware/software conflicts...

Yes, apparently once I start upgrading bits of hardware, it's hard to get me to stop. This is a well-known phenomenon, at least to Gretchen.

In today's upgrade, the wireless access point that we have upstairs and which most of our computers, tablets, and the like connect to has become increasingly crochety with old age. I frequently have to reboot the beast to get it to deign to provide Internet service. This, of course, is unacceptable under our Household Service-level Agreement -- which pretty much consists of "Daddy! Make it work!"

The obvious solution was to replace the wireless access point. I had noticed while browsing the Micro Center website that they had a suitable WAP device. Of course, I had driven down there enough times by now. Oh, look! The same device is available on Amazon with Prime delivery and for the same price.

And then I stopped to think about it. The WAP was actually an older generation of equipment. If I ever do get fiber-level service here, it doesn't even have a fast wired network connection to run over the network wire to the router in the basement. It would be a shame to buy this beast and then have to replace it.

More browsing followed. Oh, look! Here is a router from the same manufacturer as my current fancy router. It is just as fast as my current router. It just lacks the fancy touchscreen interface. And it is not actually very expensive, as it is only twice the price of the WAP that I am looking at. It can be configured as a WAP and provide redundancy in case the router in the basement decides to fail, because I can pull it out of service, carry it downstairs, and reconfigure it as a router.

And I can have it delivered the next day at no additional charge.

So I bought a router. It arrived today. Configuration was a bit more annoying than it had to be, mostly because I didn't want to fiddle with plugging my desktop computer into it directly, so the initial configuration was done via my cellphone and a wireless connection, at least until I could get the router functions neutered and the new router onto the network as a WAP. But a few hiccups later, we ended up with a nice new WAP.

I think I will stop buying hardware for a while now. :)

So it was like this:

During yesterday's round of "Get 'Er Done!", I wandered into the studio and discovered that the main monitor was severely static-ridden. Several rounds of reboots, cable tightening, and card reseating later, I decided that the monitor was probably shot and needed to be replaced. The question then became: With what?

Well, there are some lovely 27 inch UHD monitors out there now for not too much money. But the video card in the studio computer is old enough that it doesn't support UHD resolutions. Of course, I could replace the video card too. And I realized that this was not only turning into a project, but into a relatively expensive project. Better to buy a cheaper, decent monitor as a stop gap.

I had pulled up the Micro Center webpage and saw a Dell monitor there on substantial sale. Heck! That was the 16 x 10 monitor that I had been wanting to replace the monitors in my office with. And that sale price was much lower than I had ever seen for this particular monitor. If I bought two matching monitors for the office, I could swap the old 4 x 3 monitor out as a spare, send the widescreen monitor down to the studio for the rest of its life, and declare victory for not too much money.

I discussed this quickly with Gretchen who allowed that I could go ahead and do this. I then dove into the car and started driving, because it was 5:20 PM, Micro Center closes at 6 PM on Sunday, and it is a good half-hour drive to get there -- more if traffic is uncooperative.

Traffic was only moderately uncooperative -- I made it to the store just before 5:55 PM. I had already reserved the monitors on line, so I just had to pick them up at the front desk, pay for them, and head out. I made it back home by 6:30 PM, which allowed us to bundle the girls into the van and head over to the softball league season-ending pool party.

When we got home, Gretchen started making dinner and I started setting up monitors. And once I had the two monitors set up, I looked at them and realized that this was not a matched pair of monitors. One of the monitors had a distinct yellow tinge that I couldn't eliminate with any amount of calibration. Looking at things on line, I discovered that this is endemic with these monitors.

So I packed up the offending monitor. This morning, I drove back to Micro Center, returned the yellow-tinged monitor, got a replacement, and brought it home and hooked it up.

It had a very light yellow tinge. After reading a lot of webpages and a lot of tweaking, the yellow has now been tamed and the monitors are a reasonable match.

Meanwhile, down in the studio, my old office monitor is plugged in and operating nicely with no static. Thus, it appears that the problem was that the studio monitor was getting ready to completely give up the ghost, so I actually replaced the right part.

Overall, this was more of an adventure than it should have been. :)

In any case, I have managed to log into Gretchen's email and extract, print, and fill out (the last by hand) the forms that we need to have for Katie and Julie's dance camp that starts tomorrow morning. There are still a couple of items that need to be added, because for one reason or another, I don't have things like the phone number for the girls' pediatrician.

Because that is not a computer thing. That is apparently a Mom thing. :)

In other news, I think that I have figured out how to solve my computation problem at work. Now, I just need to spend a day or so coding it and testing it out to see if the algorithm that I have in my head actually produces the right results when reduced to electronic impulses.

But I think I have an impulse to wait until later -- like tomorrow -- to sort this out...

One of the problems of having a program that is complex enough to have what I refer to as "behaviors" is when you're trying to figure out why a particular behavior has changed from one version to the next. This problem is worse when you've had major changes between the two releases.

You are in a maze of twisty passages, all alike.

Well, actually, upgrading Gretchen's laptop.

Nearly two years ago, I bought Gretchen an HP Stream. Never again. It is now in the process of failing in all sorts of interesting ways. I may open it up and see if a cable is badly seated or something like that, but since the stupid machine will reboot itself when you have booted into the BIOS settings, I'm fairly sure that this is not a Windows problem.

And being an HP Stream, unless the problem is a badly seated cable, the machine is nigh unto unrepairable. For example, if this is a RAM error, you are out of luck, because the RAM is soldered to the motherboard.

But I will take a look at it. Eventually. (I have a litany of complaints about the machine, not the least of which is having to plug in an external hard drive in order to update Windows 10, because the Microsoft-size-mandated built-in flash drive is too small to allow for it.)

In the meantime, I have bought a nice little lightweight Acer laptop for Gretchen on heavy sale. It's only a dual core, but I've now upgraded the not-soldered-in RAM to 8 GB, which should give Windows 10 plenty of room to operate. I have also purged Firefox and McAfee and installed Chrome, Avira, and Alpine.

All of this only took about two hours, the largest single item being installing Avira.

I am sure that the machine will shortly busy itself downloading Windows 10 updates. But it can do that without me.

I have spent the last three days working through the calculations in both C++ and Java with one of our large test files. As nearly as I can tell, everything now matches.

I am very tired.

Well, it only took three of us to sort this particular bug out.

I had a glitch when I was converting files. This caused reports to send out bad data. The bad data then caused the Excel plugin to fall down and crash.

So first, we got the Excel plugin fixed so that it didn't fall down and crash.

Then we fixed one of the methods in the reports to be a bit more bulletproof than it had been before.

Then I fixed the conversion.

Because you have to be able to see what's broken before you can fix it...

I figured out the source of yesterday's problem.

I had put in a forward definition for a class in a header file so that I could declare a pointer to an object of that type inside the class that was defined in the header file. Like this:

class AnotherClass;

class ThisClass
{
...
  AnotherClass*   anotherClassInstance;
};

When I destroy ThisClass, I want to destroy the instance of AnotherClass that it contains. No problem. I'll just call delete on the pointer like this:

delete anotherClassInstance;

That should work just fine.

Except it didn't. Because I hadn't actually included the header file for AnotherClass in the .cpp file for ThisClass. What I would have expected was that this should have produced a compile error telling me that I was operating on a class that hadn't been completely defined.

But there was no compile error. Instead, the Visual Studio compiler just called delete on anotherClassInstance like it was a pointer to a random chunk of memory with no destructor.

Hilarity ensued.

Well, at least I should remember what caused me to waste so much time the next time I run into this problem...

*grumble*

When I execute the destructor on this particular class -- a class that we have destroyed before, I am quite sure -- I am getting a big fat error. I have been starting at the destructor for half an hour and the solution to the mystery of why it is failing continues to elude me.

This is pretty much a sure sign that I should go to bed.

Well, I added caching for another couple of classes today, which should reduce the memory footprint a bit further. Unfortunately, I am getting close to the point of diminishing returns.

The thing that's the real killer is a big doubly-linked list. Unfortunately, it's a big doubly-linked list that I really need.

*sigh*

Here I am, in the maze of twisty passages, all alike. Again.

When we open one of our models on the Java side, the memory usage in the JVM goes up by 200 MB. The heap dump says that the data associated with the model is only about nine MB.

Where the heck is the other 191 MB coming from? You'd think it would be easy to figure this out, but so far, not so much.

*sigh*

So we're studying heap dumps for our Java app to try to determine why our models are taking up as much space as they are. After staring down some of the models, I dropped in a bit of new code.

The model that I was working with -- one of the smaller ones, admittedly! -- shrank by almost 10% in its memory footprint. Larger models probably won't shrink quite as much, but it was a gratifying result.

Now to see if I can use this trick in some other places. :)

Yesterday, I discovered that someone had (in error) created a new session object and left it to hang around forever.

Further investigation showed that had happened more than once, sometimes with big blocks of memory left attached to the session.

I have now exterminated those cases.

I also did a massive cut-and-paste operation to insert code that would throw an exception every time that an attempt to assert a transient lock failed. (Normally, it should wait a short period of time, the other lock should clear, and the operation should complete.) This was frustrating, but in the defense of the folks who wrote the code that wasn't throwing the exception, I hadn't added the quick-and-easy method of throwing the exception with all of the error information in it when they first started using the locks, so...

(Now, it's just call the constructor for the exception and pass in the lock object so that it can load up from the failure info. One line, nice and easy does it. This is because I am lazy and don't want to write this code more than once. :) )

All of this fell into the category of "more fun than human programmers should be allowed to have".

I'm working on downloading the particular Linux version that I'm planning on installing on the laptop. I'm a stunning third of the way through it. Chrome claims it will be another hour. We'll see how that goes.

I have an old Toshiba laptop running Windows Vista that has become increasingly crochety about it. I've decided to try loading one variant or another of Linux on it and see if it becomes more useful.

Having seen a similar old Toshiba laptop doing so earlier this evening at the girls' school encourages me. :)

There is nothing like finding a really old bug in the code.

Today, someone sent me a file and said, "This won't open. It doesn't open in the older version either."

I tried opening the file and discovered that they were correct. Hmm. I opened up the file in an editor just to check and make sure that it was, in general, correctly formatted, which it was. Of course, there could be something more subtle wrong.

Nope, nothing subtle about it at all.

Someone had once -- and against my advice -- put in a check for the specific file extension that we use for our files to solve a particular problem that they were dealing with. That obviously wasn't the problem here, because the file had the correct extension.

In ALL CAPS. Darned shame that whoever was checking for the extension had written code that checked for the extension in all lower case.

The comparison is now case-insensitive.

And the very old bug has gone away.

The second of the two Asus M32CD desktop computers that I bought for the family has developed the same failure mode around the power switch that the first one did. This is a pretty annoying design flaw, because the actual switch is held into a plastic bracket by two flimsy catches that break with usage so that the switch no longer makes contact with the big round button on the front. You can press the button, but the switch, not so much.

I fixed the previous break with some hot glue and help from Gretchen; I plan to do the same here.

But really! This is a stupid design.

I'm continuing to break in the new studio monitors. I yanked some more sample tracks from my music collection down to listen to on the new monitors and they sounded really good, so this is all encouraging.

In other news, I may have sorted out some more of the nasty little buglets that are creeping around my code at work. I'll know more in the morning once this compile is done...

I am in a maze of twisty Java generics, all alike.

It's not so much Minecraft that I hate.

I hate Minecraft mods. These are additional JARs that you can load into your Minecraft environment to add cool features and new things to play with. As a concept, this is a wonderful thing.

In practice, it is a steaming pile of poo.

The way Minecraft is structured, all of the mods need to be loaded into a single mods directory. But not all of the mods are available for all of the versions of Minecraft. Some of the mods will refuse to run if you don't fire up the correct version of Minecraft and will prevent Minecraft from loading at all. You can flip between versions of Minecraft that you intend to use, which is a wonderful, easy-to-use feature, but pick the wrong version and some mod will shut you down.

And did I mention that all of the mods seem to be hosted on websites that desperately attempt to download malware onto your computer? Or, as I encountered today, give you the "You need to call Microsoft!" screen with a bogus phone number for bogus tech support?

Of course, little girls love mods and beg me to download them. Three out of four times, the mod fails to work after I have run the gauntlet. And then is much sadness and "Can I have a different mod?"

I hate Minecraft for having a design this stupid. I just Googled and there are some marvelously complex ways to try to work around the problem.

But it all falls into the category of "What idiot designed this system?"

One of the changes that I made managed to break someone else's build. However, that was easily fixed by adding one more JAR to the version of the build that they were using.

Someone else checked in a mismatched code change that broke the build. And yet another person fixed that.

Today, I found that I needed to do a different version of one of my changes or else the Integrated WebLogic Server in JDeveloper wouldn't start up. I certainly hope that everyone installed their "installed" version of our products on the C: drive, else we're going to have yet another build problem.

And we spent a substantial amount of time discussing WorkManager configuration, which is way more of a black art than it ought to be.

After all that, I was finally able to start running my unit tests. (Actually, these are unit tests that someone else wrote, but I have now beaten them into a condition where I can use them. I intend to add more later.)

And I have:

Found and fixed bugs in my code. (And observed that there are some more bugs there that need to be rooted out.)

Found and fixed bugs in other people's code.

Found and fixed bugs where people have inaccurately modified my code.

Found bugs where I have told other people that they need to go fix their code.

Bugs, Mr. Rico! Zillions of 'em!

*sigh*

It would be nice if we could figure out a configuration for our build process so that all of the different build methods and test modes that we use could work at the same time for the various people using them.

I have now fixed it so that it works for me. I wonder if someone else's process just broke. I don't think so, but...

My current NAS box has reached the point of being choked full of backup data and it cannot hold any more or be expanded. This has caused me to spend some substantial time researching new NAS boxes.

Today, Amazon offered a special price on Enterprise NAS hard drives. The prospect of saving some money and having an initial 5 TB of mirrored storage has caused me to take the plunge, so I bought a pair of drives and a new Synology NAS. This will use up a chunk of the profits from selling Cubs playoff tickets, but it is in a good cause. :)

Backup.

I bought Gretchen an HP Stream laptop for her birthday last year. She likes it a lot. So do Katie and Julie, who keep "borrowing" it. I was even considering the possibility of getting similar machines for the girls for Christmas.

Until yesterday.

That was when Gretchen brought to my attention a persistent error message that she'd been getting on the machine. It turns out that the flash storage on this machine is so small that it has become impossible to install the latest Windows 10 updates directly.

I have cleaned off everything that I can remove from the storage. This brought the free space up to 3 GB, which is still not enough to install a Windows update.

I now have the updates installing (maybe!) by grabbing the now-empty 32 GB SD card from Gretchen's dead camera, plugging it into a card reader, and using that as an auxiliary drive. There is a word for this procedure: insane.

My understanding is that the effective maximum configuration for these machines is prescribed by Microsoft, in the sense that anything more robust has to pay a much higher fee for a Windows license. So HP has built a machine to Microsoft's specification that cannot actually run Windows in a reasonable fashion, given that you have to believe that installing the damned updates is a vital function of Windows.

Somebody here needs to get their act together.