msteries

I took a day off from studio work today, because I went to the Cubs vs. Cards game down at Wrigley, which was scheduled to start at 5:10 and was only delayed by an hour. But all of that meant that there really wasn't time to get down there, even to record a single vocal track.

Recording is back on the schedule for tomorrow, along with work, where I hope to make some good progress.

Back to the studio again and just about to start recording. We'll see how much I get done.

A note about the new computer. The previous computer, which is still on the network and which needs to keep its unique name, is "Thunderbolt", although the Thunderbolt card that prompted the name has been removed.

The *new* computer is named "Cei-u".

If you know why, you will know exactly why that is appropriate.

It is clearly time for me to take some vacation days. Most everyone else is at work. :)

We use Gradle for our builds and to automate a number of tasks. One of those tasks is fetching the project files for JDeveloper from our Artifactory, which has the advantage of keeping developers who are less familiar with how things *ought* to work from accidentally checking in changes. Unfortunately, this gave me a problem over the last few days, because I am working on a big, ugly merge. I had loaded the JDeveloper files for the combined project, but the merge had left me with a ton of compile errors and JDeveloper was doing its little trick of "I can't see this perfectly good code over here" during the compile, even after I fixed things.

I decided that the right thing to do was to switch to the JDeveloper files that just look at my group's source code, get that fixed, and then go back to the integrated project. It was a great idea.

Except that Gradle would insist on compiling the code on the branch before it would let me download the JDeveloper files. That would fail (which was not a surprise; it was why I was trying to get the JDev files downloaded) and when that failed the process was done and the JDeveloper files were not downloaded.

Swearing ensued. Asking the build team for a fix ensued, but our U.S. guy is on vacation in India and the rest of the build team is in India as well and didn't seem to grasp the problem. I eventually sent one guy a screenshot of the directory listing showing that I did not actually *have* the JDeveloper files on my machine in this directory. This didn't get me a solution to the problem, but it made me feel better.

I figured I would take most of today off if I didn't get a solution. And I didn't. I answered some emails, went out for a nice lunch with Gretchen, came home, and went upstairs to take care of a few things.

And then I started researching Gradle, because I really know very little about it.

I figured out that what I needed to do was to tell Gradle to pretty please, don't run a compile when running this particular task. I still haven't figured out how to put this in the build.gradle file, but I did figure out how to get the files downloaded by changing my command line options. To wit:

"gradlew loadJDevFiles -x compileJava"

And look! I got my files.

I sent an email with the solution and went off to spend the rest of the day in the studio, because I deserve a vacation.

Starting now. :)

(More about the studio later...)

The optical drive arrived today on schedule. It only took a few minutes to get it installed, the new computer buttoned up, and then I was able to take it to the basement.

It took a while to work through the Windows 11 install, because it kept wanting drivers that needed to be downloaded and there was no computer here to do it with, the old machine having been disconnected. Eventually, I got bright enough to bring my laptop to the basement for the driver downloads which allowed me to stop going up to the second floor. :)

Anyway, the good news is that I got the Universal Audio software installed and it promptly detected the Apollo interface on the other end of the Thunderbolt cable. I am now in the process of reinstalling all of the other software that makes things run down here.

And then there is the copying of the audio files. I had intended to bring them across from the old machine, but I think the BIOS battery there has given up the ghost, so it is not going to be booting up until I replace that, hook it back up to a monitor and keyboard, and fix those problems. But everything is backed up to the NAS in the office, so I am now entering the second quarter of a projected twelve hours of copying files down.

Whee!

But I should be able to get things up and running again tomorrow -- depending on how much software still needs to be installed. :)

Once I finally got the studio computer to behave again, I went back to working over tracks for "Crosstime Bus" and laying down more guitar tracks and replacement scratch vocals that wouldn't be contaminated with the original scratch guitar. The first song wasn't much of a challenge.

And then I was off into "It's All Right". I have been practicing this song. It shouldn't be a problem.

Except I can hear that the second chord that I'm playing in the song is *clearly* not the same chord that is on the scratch tracks. It's labeled on the lyric sheet as "Bm7/A". Right...

Ok, I can hear the high A on the first string clearly. What are the other notes that are in this thing?

Eventually, I realize that this is a D7sus moved up to the third fret. The guitar chord analyzer tells me that it is (among other things) "Bm7/A". Uh huh.

It's amazing how much easier it is to play the guitar when you know what you are playing.

We've been running the Fortify app against our source code and the section that I'm responsible for has been pretty clean for the most part. But there was one set of routines (that I did not write) that was being stubbornly difficult in being changed to avoid an unreleased resource leak. I tried one approach (a poor one, as it turned out) that just broke everything in the area, so I backed it out and went after it again.

This time, I refactored the code to avoid the particular construct that causes Fortify to lose its mind as it scans our code. Once I did that, the code still worked, which was good.

And it passed the Fortify scan that just finished.

Yay, me.

I have pulled CDs to ship for Baycon, so they should be able to leave the house tomorrow if anything goes according to plan. Yay!

I have two weekends left to finish going over the scratch tracks for "Crosstime Bus" which means that it is going to be a busy time in the studio in and around laundry. In the meantime, I should practice some more.

Part of what makes this more fun is that when I *wrote* the songs on this album, I wasn't using a pick. Internal evidence tells me that I picked a pick back up between 2005 and 2010. This means that I have new and interesting learning experiences as I pick them up again, although all but the very oldest scratch tracks use a pick. And, well, I've played *most* of them in the meantime...

Practice, practice, practice!