When I bought the Lincoln MKX, I decided to use a ceramic nano coating to protect the finish. I settled on Feynlab and had the work done shortly after I had purchased the car in January of 2018.
The detailer that I had used back then, The Clean-up Shop, had brought some new product in for top dressing tires. A long-lasting product, the tires should stay freshly dressed a year from now.
Whenever I dress tires, I’m lucky to have the treatment last for more than a few weeks.
I picked the car up a few days ago and it looks great even under the unforgiving glair of those detailing lights. The coating looks like new and the car’s finish is free of swirl marks — I hand wash only. The coating on the tires presents a semi-gloss look and it is smooth to the touch.
Normally, the Tacx Neo is a very quiet trainer. But not today. Today it made these sounds:
I reached out to my friends on the Tacx Neo Owner’s Facebook Group. Very helpful feedback from everyone there.
I had the following suggestions: index the rear derailleur, tighten the rear cassette, and contact Tacx support. I did send Tacx support a note along with the above video. This was their response:
We’re sorry to hear that.
This is a very strange sound.
Do you hear this sound as well if you stop pedaling and let the flywheel run out? If you do not hear this sound while not pedaling then we suspect the sound may be caused by your chain or cassette. Please make sure that the cassette is locked tight and maybe do some maintenance.
If the sound still persists even when not pedaling then the noise might come from inside the NEO. Could you then send us a new video (<20 mb) of the sound?
We will then want to investigate your NEO further at our factory.
The trainer is relatively new. I put it into service in June of this year. I ride about 8-10 hours a week on the trainer. My bike’s drivetrain is basically new as well — as in new chain and cassette — and very quiet out on the road.
I don’t mind doing the maintenance check on the rear cassette although I do not have the tools for tightening the cassette. But I suppose I can at least check for any potential slippage. It seems a bit early to have to worry about lubrication for the cassette area but who knows. Worth a try. The chain? Well, it is new and tight and I keep it well maintained. I don’t see a need to swap it out.
The last thing I want to do is send it back to the factory with just a few weeks to go before we head out in our coach.
I trained for many years with wheel-on trainers. Never any issues.
Seems like the direct drive trainers are a bit fussy.
Hopefully I can get this resolved locally.
In a few weeks time I will be doing some work on a live recording project.
I think part of this work includes me doing the actual recording on site. Which I am fine to do. Except that I have no remote recording equipment.
I had sent a note out earlier to clarify whether I was expected to bring a remote recording rig — which I would rent for the event — and I have not yet heard back from the event itself. I guess I’d better get busy on that one. Enough of being retired and sleeping all the time.
I’m doing an audio training session the next day in the same city. Fortunately, for that session, I don’t require a recording rig.
I will require a bit of help though. A lot of material to cover in a couple of hours and trying to teach audio engineering without doing any audio engineering is very challenging. The best approach is hands on with a live band. But it will just be me. I might try doing a few things with my laptop as a proxy.
Getting ready for the upcoming work gave me a chance to look back on some of my material, doing before and after passes and the difference that a mix can bring to recorded tracks.
This is a high resolution scan of a print from a shot that I took at a family vacation in Walt Disney World. Based on the age of my children from the other prints of the vacation, this was about 20 years ago.
I’m not sure what camera I was using at the time. Cameras that most families could afford back then were not all that great. Film was expensive as were prints. You could capture a memory but my, oh my. Not much in the way of sharpness. And the colour? Well it has a certain vintage feel to it. A bit like an Instagram filter gone wild.
Here is a shot taken of the same hotel just last year with a good quality DSLR and a 35mm prime lens. Although, in this light, most any smartphone would have produced a similar result.
I do have some film presets in my digital darkroom. Tried my best to get a vintage look from the same shot. Looks like it is twenty years old now.
In just a few weeks we will be moving into our home on wheels. The picture above was taken when we last had our coach out back in September of 2017. It has been just about a year of waiting since then.
The coach becomes home for us late September. We’ll be in Canada for about six weeks or so and then we will head south for the winter months, from November to April, travelling down to Florida and across to California. We will cover roughly 7,000 miles or more during that time.
Really looking forward to this adventure.
After years of planning, we are almost ready to go.
You can follow us on that journey at our travel blog: rvcastaways.com
I have a couple more amps up for sale on Reverb. And, as it happens every time I post photos on Reverb, I get messaged by someone asking me if these are the “real” photos of the amp or if are they stock photos.
Reverb won’t upload stock images if the listing is for a used item. They check the EXIF data of the images. Amongst other things, the EXIF data of an image includes information that can determine whether a photo is stock or not.
What do I do to take a great product photo?
A sheet of white paper.
The paper was taped to a wall and rolled out. The amp was placed on the sheet of paper. I used my Olympus EM1 camera mounted on a tripod. I shot the image at 1/60th of a second, f2.8 with a 50mm equivalent lens (25mm f1.8) and ISO 1600. I did not use any studio lighting for the shot. I used the existing halogen lighting that was in the room.
Brought the image into Lightroom. A little bit of colour correction. Boosted the whites. Exported it out to Pixelmator where I brushed out the remaining shadows and then I cropped out the background clutter.
This is a stock photo from the Mesa Boogie website.
And my front-facing shot again:
Maybe I take too good care of my gear? My Lone Star Special is over 12 years old and still looks like new. Perhaps that is why I get people asking me if the photos of the amp are real or not. I need to rough things up a bit. Rip out some tolex. Throw some dirt on the grill cloth. Smear the control panel with grease.
Rock ‘n roll!
This was one of the last photos I took of Norway, just as we were leaving Flam.
I would have to say that Norway was one of the most stunning places I have ever visited. The landscapes were truly amazing.
I came across this video highlighting a very large scale infrastructure project to connect the coastal communities of Norway.
If implemented successfully, this would be an impressive achievement.
Most will credit Grace Hopper with establishing the use of the word “bug” to describe a problem with computers. A dead moth had been found in Harvard’s Mark II computer and Hopper used the term to identify the issue. Literally, a bug was found inside the computer.
However, the use of the word “bug” goes back over 140 years to Thomas Edison. He used that phrase when working on telegraph systems back in the late 1800s.
You can read all about it here.
I received an email earlier this week asking for some help on a website that was exhibiting very slow page loads, in excess of 2 minutes or more. Very few people have the patience to wait a couple of minutes for a page to load.
When I was teaching computer science many years ago, I remember telling my students that the process of debugging required three fundamental steps:
Step 1: identify the problem
Step 2: isolate the problem
Step 3: resolve the problem
The steps are not often easy as some bugs can be very difficult to track down. There is also the tendency to repeat the same approach to problem resolution. Expecting a different outcome from the same approach can lead to lengthy debugging sessions.
My first reaction, upon taking a closer look at the website, was to attribute the issue to outdated themes and plugins, this being a WordPress site.
I was careful to make a full backup of the site and the WordPress database, create a local instance on my desktop, and ensure that all components of the site were using current versions.
Although all good actions to take, that did not resolve the issue. I had yet to identify the problem.
Debugging on the web is fairly good relative to the old days when I was debugging C and Assembler code.
Browsers provide pretty good tools to step through a website and find the issue.
I am quite used to working through complex websites with the development view.
Bringing up my friend’s website allowed me to identify the problem almost immediately with the console trace. Upon loading certain areas of the site, the code failed when attempting to load a resource.
The reason? A bad link to an image file.
It happens with WordPress.
The code was unable to load the resource with the following snippet: <img src=”http://123.45.678.910/~userid/domain.com/wp-content/uploads/2018/08/image.jpg”…
It would eventually timeout and recover without loading the resource hence the lengthy page loads.
I had successfully completed step 1. I had identified the error. I then jumped right to step 3. After all, the problem was pretty obvious to me. And it was obvious. I just forgot to isolate it in the code.
These snippets with bad links were everywhere in the code. And the code was literally just a glob of unformatted text. Thousands of lines of dense code. Very hard to isolate in the WordPress admin panel as most of the pages were created using a visual composer plugin. Fixing the bad links in the WordPress admin panel is not the most fun way to spend your time. Tedious to go in and bring up isolated sections of the code.
After a few hours though, I had found them all and promoted the changes back up to the server.
I asked my friend to walk through the site to make sure I hadn’t missed anything. So far, so good.
Loading images from a hard-coded IP address instead of a domain name is not typically a good thing to do. Fortunately I did not have to go into the WordPress database to update link details. The issue was limited to bad links in the code itself.
I don’t know why it happened. Very few people have changelogs for their websites. I suspect someone was doing something on localhost and uploaded the code through FTP with client-side references. I was just happy to be able to resolve the problem in a timely fashion.
Not too bad for an old, retired CIO.