Category: daily

Weechat on OSX

This is recording how I got weechat on OSX updated to 4.0.4, and how I fixed /script to work as well, thanks to some helpful folks on IRC.

One of the slight annoyances with using weechat on OSX is that the Homebrew version is still 3.8 or so. I have multiple systems, with weechat on all of them, and OSX is the outlier in being outdated.

The #weechat channel on libera was horribly useful, and got everything straightened out, with first updating to 4.0.4, and then fixing a problem with scripts. I’m writing up what I did here, so it’s easily searchable.

First, the upgrade to 4.0.4. It’s important to know that while I did all this, I didn’t originate any of it. I can’t claim credit, and don’t. I was doing things that others suggested. (The users in question were trygveaa and R2robot; I don’t know them outside of those names.)

The first thing I did was run brew edit weechat, to edit the weechat recipe file for Homebrew. The values I needed to change were the url and hash values for the downloaded file; they’re lines 4 and 5 for me, and this is what I changed them to:

url "https://weechat.org/files/src/weechat-4.0.4.tar.xz" sha256 "ae5f4979b5ada0339b84e741d5f7e481ee91e3fecd40a09907b64751829eb6f6"

After that, it’s a simple matter of running:
brew reinstall -s weechat
… which should download weechat from source (and thus get 4.0.4) and install it from there.

Now, running weechat gives me 4.0.4; that’s one problem down!

~ > weechat -v
4.0.4
~ >

The other problem was that /script didn’t work; it would tell me it was trying to download the scripts from an external server, and… that’s it. No progress. No scripts window, no nothing. That’s suboptimal, because there are a few scripts I find highly useful.

I got it working by setting an environment variable. I actually tried two of them, but only one turned out to be significant:

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

With that set, /script downloaded the list of scripts, and I could install, autoload, et cetera. I had also tried setting WEECHAT_HOME to a different location (also a suggestion), and that worked as long as I had the fork safety disabled – and removing WEECHAT_HOME left my configuration where it was “supposed to be” (the default) and /script still worked, so the OBJC_DISABLE_INITIALIZE_FORK_SAFETY is what made the difference.

I started a substack… and deleted it minutes later.

I deleted it because the main value in starting another site was that it could be faintly anonymous; I’m not worried about hiding as much as I don’t like putting my name near the front of anything I write.

I dislike cults of personality, and I recoil at the idea that I could be leveraging who I am, as opposed to what I create. I tried to remove my name from my publication, but it still was attached, and that meant substack was an inappropriate medium for me.

Such is life.

RC Flying, 2023 Feb 26

It was a good day of flying for the RC plane, despite the wind; we got the radio and the plane set up much better than it had been, and despite some issues and hiccups, it was a good day.

I made it back out to the RC field today, a little concerned about the winds (which were from 6-10 miles per hour, which is a little gusty for my plane), but I was going to give it a shot, because a lot of the other pilots tend to be there on Sunday afternoons.

It went okay. The biggest problem I had was that my plane needed to be set up more completely with my radio, especially after the catastrophic crash from two weeks ago; I’ve been up since the crash, but that day was cut short due to weather, and I was up in the air such a short time that I really couldn’t collect any data about the plane, and I was also alone, so I couldn’t share from the communal knowledge.

Sam – one of the club trainers, and the guy who got me in the air when I first went to the field – took some time with me and the plane today. He said that there was a lot set up wrong – the plane’s trim was awful (not a surprise, considering all the changes it’s endured lately), but the radio was also set up really strangely.

That’s an experience thing. I don’t know what to look for, so I had no idea what I was setting up improperly. He does know what to look for, so we rolled up our sleeves and went to work on the plane, reversing the prop for full power (whoa! I didn’t even know you could install it incorrectly and still fly!), aligning everything (some of the servos were not quite set up right), setting up dampening on the controls (a big one, and why my plane flew so badly!), and trimming it out in flight as well.

Flying itself went… okay, I guess. No catastrophic crashes; I had two, but they were both really minor. One was caused by my use of a battery that was already dead: I lost throttle in mid-flight, and glided down to the field. The other was caused by taking too shallow an approach on a landing; I caught a wind gust and then lost the plane. No damage was taken in either event, thank goodness, and in the second crash I managed to warn the other pilots this time.

My last flight, with a good battery and in the most advanced flight mode the plane had (more on this in a few paragraphs), went pretty well, easily the best flight of the day for me. The plane had by this point been set up about as well as we could do it, and the same for the radio, and the dampening helped me fly immensely – no longer were little adjustments causing giant changes in the flight. I even made a really smooth landing, which got a lot of clapping from the other pilots – it was a good landing, but I think they were also clapping for me, since I finally had a respectable flight after so much trouble over the last few weeks.

Other pilots were there, of course, and one had a P-38 – I was in awe of that thing! (The P-38 is my dream plane, and there’s no way I have the skill to fly it – but I was so excited to see one at the field!) Sadly, the wind fought that thing, too, and despite the skill of the pilot, it cracked up on a landing approach. He said the plane was easily repairable, and would be back.

One of the pilots’ daughters was there, too, and she was flying a glider – which I think is really, really cool. She’s been flying a shorter time than I have, and I think she’s better than I am already. It’s really neat seeing some of these young people advance in skill.

So: what takeaways did I have today?

The biggest one was the setup of the plane and the radio. We changed a lot about the configuration, and it was really unusual for me to experience the plane working the way it was supposed to. From that standpoint, today was a smashing success, despite the issues. However, there were issues.

First, my plane is still in some kind of safe mode. I don’t know how to get the receiver to stop correcting the flight; I can’t get it to roll or loop. I can get it to 90% angle, flying sideways, but that’s as far as I can get it to go. That’s not how it’s supposed to be; I checked the manual, and I think I have the radio doing the right thing to set the flight modes, but it clearly isn’t, for whatever reason.

Sam suggested that I replace the receiver altogether; with the radio set up properly, the features the receiver offers me aren’t as necessary. I’m certainly giving that some thought, because my last (and best) flight was with as few safety guards as I could get, and it was probably one of my best flights ever. (It wasn’t that much fun to watch, I think, unless you count the landing, but by golly, everything I tried to do I accomplished, and it went well.)

We’ll see. I also need to continue repairs for the lane from a few weeks ago; it’s airworthy, but could still use some fixes. I have most of the stuff I need, but one of the glues I got was too thick, so I’ll have to fix that.

Lastly, I still need to change how I react when the plane gets in trouble. I find that I invert the controls in my head once I lose track of the plane in the air, which means I might make an error by turning right, for example, but when that happens, I have a tendency to lean into the error, magnifying it, instead of correcting it. This needs to be fixed, and it will be fixed, but it’ll take time and practice and dedication.

It was a good day at the field. It was windy, and that made for some rough flying (for many pilots, not just me, but I definitely had a rough time with the wind), but we got the plane set up much better than it had been, and that last flight gives me hope.

Flying, Jan 28, 2023

I made it back to the airfield today, expecting everything to go more normally – I’d flown with my new transmitter, managed to replace a servo that I’d stripped in my plane, so everything was where I expected it to be. There are still a few wrinkles to work out with the transmitter and the receiver, but I thought I had everything set up properly. I didn’t, but I have an idea what is wrong.

I made it back to the airfield today, expecting everything to go more normally – I’d flown with my new transmitter, managed to replace a servo that I’d stripped in my plane, so everything was where I expected it to be. There are still a few wrinkles to work out with the transmitter and the receiver, but I thought I had everything set up properly.

Spoiler alert: I don’t. It’s nothing major, though.

The flying went fine; I am trying to force myself to land right-to-left, and the wind was going the wrong way to make that really “the right thing to do,” so after trying two flights with the wind, I finally gave up and on my last flight I landed left-to-right.

I’m trying to land right-to-left mostly because I’m used to landing left-to-right, and I know the markers where I can see the plane’s on the right approach; I like being comfortable, of course, but I also want to be able to be flexible, so I am trying to force myself out of my comfort zone.

I also tried out the modes; I was going to try to stay mostly in “intermediate mode” at the very least (I did not, and there are a few reasons why) with a bit of dabbling in “expert mode.”

My first flight, I got in the air, flew a pattern a bit (to try to get my “air legs,” which I never quite got to this Saturday), set the radio for “expert mode,” and then tried a loop.

The plane stalled out at vertical, and that was that: no loop.

The way you do a loop is pretty simple: you give the plane full throttle to build up speed, then pull the rudder back hard. As the plane crests at the top of the loop (upside down), you back off the throttle so you’re not accelerating towards the ground, and when you’re near level again, you give it whatever throttle you need to resume flight.

My plane didn’t even make it to be upside down at all. There were two problems, both fairly minor but one easily corrected at the field: I was not using the wind.

Ordinarily you’d fly a loop into the wind, so the wind helps push your plane into the loop. I was not doing that; I was flying a loop with the wind behind me so it was actually pushing my plane out of the loop. Chalk this one up to “this was my first real attempt at a loop,” and I failed.

The other problem was that the “expert mode” I was in… isn’t expert mode. I don’t know what it is, but it’s still some sort of safe mode for the plane; if it gets too far into vertical or sideways, the flaps autocorrect and you can’t continue where you are. That’s what you want in the safer modes, but I was purposefully trying to get out of those modes. (I figured this out with some help from one of the other pilots at the field, by the way. In the featured image for this post, that’s the pilot who was helping me figure this stuff out; the picture is not mine, it’s Sam’s. Sam is one of the trainers at the field, and is the one who got me in the air for the first time a few months ago.)

I couldn’t roll the plane; I tried. I did manage to do two more loops Saturday, both with the plane wheezing at the top of the loop (I was using the wind, finally, to push the plane over the top).

My first loop, I was so surprised to get over the top that I forgot to roll off the throttle, but I managed to recover.

The mantra at the field is to try things “three mistakes high.” It’s good advice. If I’d not been following it, I’d probably still be digging bits of my plane out of the ground. Being that high allowed me time to analyze and remember and recover; the plane was fine, it got out of the loop “one mistake high” and flight resumed.

It was kinda funny, though, because as I was recovering from the loop’s mistake I could hear the other pilots’ warning “uh oh,” thinking they were about to see my second crash. But nope – I survived, and so did my plane!

Other pilots with the same plane checked out the loop – they managed fairly easily, so it’s definitely my configuration. (This is one of the best aspects of this club: hardly anyone there knows me well, but I had a lot of pilots willing to help and observe and – probably – laugh good-naturedly at my struggles. And yes, I was laughing with them.)

The throttle cut also played in. At one point in one flight, I engaged the throttle cut by accident – as in, I was flying and then I disarmed the throttle. As expected, the prop stopped spinning while the plane was in flight… but I couldn’t get it to reengage. I have a feeling this is a receiver thing, too, but I am not sure; I landed on a glide (a fairly bumpy landing, like all my landings were but one) and took back off without a problem, but it’s something to watch for; I hit the disarm while trying to set the flight modes. I may have to move the flight mode switch to something a little farther from the disarm switch.

All in all, it was a frustrating day of flying, because I didn’t fly well at all, but … you know, everything survived to fly again, I have an idea about how to solve the problem with the flight modes, and I did get some valuable practice in.

Flying Report: 2023/Jan/21

I made it to the RC airfield today, and man, the weather was absolutely perfect. I wish I could say the same about my flying. It was a day curtailed by hardware problems, but overall, it was a successful day.

I made it to the RC airfield today, and man, the weather was absolutely perfect. I wish I could say the same about my flying. It was a day curtailed by hardware problems, but overall, it was a successful day.

Here’s the thing: my goal for the day was really to flight test my radio settings: could I change flight modes? Did the throttle cut work properly and predictably? Bench tests – done at home with the prop taken off of the plane – suggested the answers were “yes,” but bench tests aren’t flight tests.

When we (my oldest son and I) got to the airfield, there were a lot of other pilots – that always makes for a great day, because we can rib each other, admire each others’ planes, learn from those more experienced than we are, and so forth and so on – it really is a community.

I took my plane up early, because my goal was to flight test the radio, and sure enough, it worked. The throttle engage switch was restrictive when I wanted it to be (and I’ll write up how it works to go along with a video that someone else made soon), and the mode switches worked; I would set the plane in “expert mode” and tilt it to the side, and set the switch for “safe mode” and the plane would level off as desired.

So now the plane was safe in terms of the throttle – I can leave the throttle disengaged until I’m actually ready to fly, and have confidence that it won’t accidentally reengage trivially – and it was safe in terms of flight mode, such that if I got myself in trouble in the air, I could engage “safe mode” and have the plane level itself off.

I decided I was going to try to land in “expert mode” because I’d never done it before. My approach to the landing strip was… weird, because I couldn’t get it to get low enough to the ground, so I decided I was going to make another pass over the landing strip, but apparently it descended just enough that my plane lost all lift and it went to ground almost immediately. I applied power to try to get it back in the air to make a “good landing” but failed, and thus:

My first real crash! It was free of damage; the cockpit hood of the plane came off, but that’s not a problem at all; it’s designed to be free, as that’s where you install the battery. There was no physical damage to the plane that I could see or detect.

I put the plane back in a harness, and noticed that the front wheel was angled to the right; I’d been struggling with taking off in a straight line, so I gently twisted the wheel to straighten it.

If any readers are flinching, thinking, “oh, no, um, did you really?” … that’s the right reaction.

The real right reaction is a little more detailed: “Oh, no. Did you really? That’s gonna strip the servo!”

Spoiler alert: that’s exactly what happened.

I asked one of the trainer pilots (Dr. Joey, who has helped teach me how to fly too) to help get my oldest son to fly a plane, just for the new experience. We went through the radio settings and basic safety, and we finally connected the battery on the plane, and… the plane was making a lot of noise. It’s a noisy plane in safe mode anyway, so I thought nothing of it, until we were testing the rudder in the pre-flight tests.

It wouldn’t move.

In my plane, the rudder is connected to the same servo as the front wheel. When I adjusted my front wheel, I blew out the servo, so my plane had no rudder.

It’s probably flyable in that condition, if the pilot’s experienced enough, but for a maiden flight – or even a new pilot like me – it’s grounded. We tried to find a compatible servo at the field, but my plane’s servo is apparently fairly weird – a Spektrum A390 – and we were unsuccessful at finding a compatible replacement.

I found some online, and ordered them – they’re only $12-14 or so – but until they get here and I replace that servo, my AeroScout is grounded.

With that said, though: remember how I said that my goal was to flight test the radio, first and foremost? Despite the hardware problems with the plane, I did take it up and flight test the radio settings, and they worked like a charm. I may not have flown a lot today, and I might not have flown well even by my own low standards, but the radio test worked, and my plane was flight worthy even after my rough landing.

Successful day. I enjoyed it, and I’ll love it when I can get back into the air once the replacement parts come in.

First Encounter With EdgeTX

This is a writeup of my first few days with a new RC transmitter, the RadioMaster TX16S. It’s not fully set up for my plane, although it’s set up enough to use now.

I finally got a new radio for my RC planes, the RadioMaster TX16S, which is a 16-channel 4-in-1 with a touch screen. The channel count means that it has lots of ways to communicate to the planes (i.e., I can theoretically control many servos/actuators if the plane has a receiver that supports such controls) and the “4-in-1” means that it has support for multiple protocols – and can communicate with a lot of planes “out of the box.”

I have not flown anything with the TX16S yet. I’m still in the unboxing/setup process, and I still have things to do before I’m comfortable taking it out for real.

EdgeTX is a version of a radio-focused operating system called OpenTX. EdgeTX is updated in a lot of ways, primarily for touch screens, and theoretically has a number of UI updates as well (I have not used OpenTX, so I don’t have any prior experience to compare EdgeTX with.) The TX16S came with EdgeTX 2.7.1; the current version of EdgeTX is 2.8.0.

If that sounds a lot like Linux, particularly with bare-bones Linuxes like Debian or Slack and their user-focused counterparts like Ubuntu, well… it probably should, because that’s the way that it feels. OpenTX is “the real OS” and EdgeTX is the version for people who want to fly (as long as their radios support the requirements).

With the new radio, there are a lot of little things to do. If you’re an experienced flier, a lot of this will be “well, duh” material, and some of it will probably sound wrong and/or basic and/or horribly new. That’s okay with me; a lot of it probably is wrong and/or basic and/or horribly new. I’m writing this as a record, after all, and I’m learning as I go.

Getting Started

The first thing I wanted to do was validate that it could connect to my plane, a Horizon Hobby AeroScout 2.1 RTF. This is a beginner plane (which fits, as I am a beginner!), and comes with a Spektrum transmitter (the DSX, which is definitely an inexpensive starter radio) and receiver. Spektrum uses a specific protocol (called “DSM”) and support for this protocol is part of why I chose the 4-in-1 version of the TX16S transmitter; most of the planes I am likely to fly will probably have Spektrum receivers.

That calls into question why I bothered with the TX16S at all, actually: if most of the planes I’m likely to fly are Spektrum, why not get a Spektrum transmitter like the NX8, NX10, or whatever?

The reasons come down to cost and interest. Spektrum is good – excellent, probably – but it’s very expensive for what it is. The expense is not especially relevant, in that they’re designed to purpose (i.e., if you want to fly a plane with a Spektrum receiver, you … can use a Spektrum transmitter with little problem), but if you want to control anything else… well… they’re designed for specific receivers, as I understand.

The interest is the real thing, though. Spektrum is, as I said, designed to purpose: flying things that have Spektrum receivers. They do that well. But they’re not programmable; you get the transmitter, you use it as designed, end of story.

I’m an old-ish school Linux guy: not first generation, but relatively close to the second-wave, when Linux went from “hey, you can run this operating system and some programs actually run on it, too!” to “yeah, there’s probably a way to port it to Linux, if it hasn’t been done already” (and before the “wait, the source code has support for other UNIXes too?” period, when Linux basically took over the UNIX world.)

So OpenTX and EdgeTX, being programmable (and open source), have a lot of appeal for me on an intellectual level; one of the other pilots at the field was advocating for the NX8 very appropriately, saying “the purpose is to fly, not program,” and he wasn’t wrong at all… but my purpose is not just to fly, so the TX16S held a lot of appeal as a full-featured, programmable radio… as long as it could connect to my plane.

What I Need To Do

So: back to my list of things to do. The first was “connect to my plane, right?”

My list:

  1. Connect to the AeroScout to validate the TX16S -> Spektrum receiver connection
  2. Set up a throttle cut (to allow me to carry the AeroScout safely while powered up; a throttle cut prevents the prop from being activated)
  3. Set up flight modes for the Spektrum
  4. Set up panic mode for the Spektrum

Connect to the AeroScout/Spektrum

This is the first thing I did after unboxing the TX16S, and it went flawlessly, for the most part, except I didn’t have the throttle cut set up; without that, I’m not comfortable using the radio with the plane. So after “binding” my radio to the plane – a basic requirement, because it means I can communicate with the plane – I needed to set up at least one safety feature before I could take the controller and plane to the airfield.

Throttle Cut

The throttle cut was (and is) really important; it’s the first lesson of safety with RC planes. You don’t power up the plane without having your radio on, and you don’t engage the prop until you’re ready to actually fly. The RC engines (and their props) are fast and sharp; you don’t want to injure yourself by accidentally applying the throttle while you’re carrying the plane to the airstrip.

Flight Modes

The flight modes are a little more interesting. One of the really attractive features of the Spektrum receivers is that they support flight modes like “beginner,” “intermediate,” and “expert”.

In “basic” mode, the plane keeps itself relatively level, and the flight controls are limited; you can fly, but your controls are dampened, which prevents you from doing crazy (wrong) things, and also keeps the plane from generally going out of control. It’ll stay relatively level and turn relatively gently. You’re telling the plane what you want to do, and it more or less does it.

In “intermediate” mode, well, you’re still dampened, but not as much; you are flying more than you are with basic mode, and can lose control more easily, but it’s still dampened somewhat.

In “expert” mode, there are no dampeners, there are no controls, there’s nothing keeping you “relatively level,” and you’re literally controlling everything the plane does. You’re not “protected” from your inexperience in the slightest; this is the acrobatic, real flying mode, and is what the old-timers like my father would have thought was actually flying RC; they didn’t have those newfangled protection modes!

The AeroScout is very literally my first plane (and only plane, so far). I have maybe ten or twelve flights with it; I am still at “rank beginner” in skill, although I’m proud to say that I try to fly “intermediate only” when I’m using the Spektrum controller, to improve my skills.

With the TX16S, though, one of my goals is to figure out how to get it to support those Spektrum modes, not because I want to target them, but because I’m not good enough not to target them yet! One of the nicest things about the modes is, after all, to fly intermediate and get yourself in a pickle, and switch the mode to “safe” mode and have the plane level itself out for you – it rescues you, and that rescues the plane, and protects your investment in it.

Panic Mode

The “panic” mode is similar; I’d like to be able to flip a switch and have the plane stay in the same “flight mode” (assuming I can get that set up) but still level itself off and normalize position; imagine I get my plane in a spin, I want to be able to hit a button and have it level itself off (rescuing me from the spin) and then resume flying.

Actually Setting It Up

Unboxing went pretty well. I ordered a battery with the radio; slotting it was pretty clear enough, although the manual that came with the radio was very limited on information. The radio has two USB-C ports (why?!) and hides a micro-SD card under the bottom rubber bumper. It’s built pretty solidly, though, albeit out of plastic.

The bottom USB-C port is for charging; the top one is for communication, so if you’re connecting the radio to a computer as a USB device, you use the top port, and if you’re charging the battery, you use the bottom USB-C port. This is a design decision that is unclear to me; I’m pretty sure it’s related to design choices for the radio and how it’s put together in two panels, but ideally you’d have one slot and use it for everything the radio needs to communicate.

The SD card slot is workable, but it’s not mounted perfectly; it’s painfully easy to put an SD card in place and miss the slot, which means you’d have to open the radio to get the card back out. In general, if you’re working on the SD card (which is how you’d update the radio or work with the radio data directly) you’re probably better off mounting the radio as a USB storage device (the top USB-C slot) and working with the filesystem that way.

Binding to the AeroScout was, as I’ve said, really pretty easy; in EdgeTX 2.7.1 (the version that came with the radio, remember?) you’d go to models, create new, and the main thing to do was select the communication protocol (DSM) and hit the “bind” button. Once you’ve done that, you’d power up the AeroScout and tell the receiver (an AR631 in my case) to bind; it has a convenient physical button on the receiver for that purpose. Once the bind process is done, you can actually control the plane with the radio. As I’ve said, though, there’re no safety features at this point.

I tried a few different ways to set up the throttle cut. Most of the available tutorials and documentation focuses on OpenTX and not EdgeTX; they are different! The features are generally compatible, but the locations of things and how you’d set them are not the same.

One thing I did while trying to work out the throttle cut: update EdgeTX to 2.8.0, as the reference materials keep using the “current version.” This was relatively easy – put the updated binary on the radio, tell the radio to prepare to flash the new firmware, then boot the radio while holding the trim switches “in” – and the new EdgeTX had some features that it rather wanted, like support for a period (“.”) in the on-screen keyboard. I found a video for this online; it was not part of the supplied documentation. The video had information that I had not seen elsewhere, an issue that EdgeTX (and the radios) suffer routinely.

I got the throttle cut worked out with Open TX Ultimate Arm Switch; I want to change one thing about this, because the switch that it uses starts in the “down” position and the disarm switch ends up being the “up” position (i.e., I want to invert the disarm as given by the tutorial). But it works, so now I’m able to at least take the radio to the airfield without worrying about a very very very basic safety rule.

The “beginner,” “intermediate,” and “expert” flight modes – and the panic button – I still haven’t figured out.

The biggest problem EdgeTX has – and OpenTX shares it – is a lack of documentation. It’s moving relatively quickly, and there’s not a cure for that (nor is it really a problem) but the community is still a little on the early Linux “do it yourself” curve; Spektrum receivers, for example, are (from what I’ve seen) really popular, and I’d think that “here’s how to set up your Spektrum to match features with the Spektrum transmitters” would be a huge lever for EdgeTX… and it’s just not there.

Binding to Spektrum is, but as long as you can support the DSM protocol, that part’s pretty easy. It’s the other features that should be normalized; there could be (and should be) a reference somewhere that says “oh, you just got your [radio here] and it’s running EdgeTX? Here’s how to connect to [popular receiver] and configure the radio to use [reason the receiver is popular].”

The receivers are fairly generalized; some have special features (like many of the Spektrum receivers!) and the radios are generally the same as well (which is why EdgeTX can run on so many of them); the specialization for the radio and receiver combinations would be pretty light, pretty much a matrix of “if your radio can support DSM, you can connect to Spektrum like so and configure these features by following this howto…”

… and if I learn the radio well enough to do that for the RadioMaster TX16S and the Spektrum receivers, that’s what I’m going to do.

Geddy Lee’s Approach to Bass

Geddy Lee’s bass playing was always fantastic, but the main changes in how he wrote bass lines centers around melodic and rhythmic repetition, and I think this can be seen in four phases through Rush’ careeer.

I believe that Geddy Lee changed his approach to songwriting and playing bass over his career, in four phases, going back and forth between the traditional role for bass as a foundational aspect of a song to a melodic role.

When Rush started out, it was as a straightforward rock and roll band, built from aspirations to be like Led Zeppelin, The Who, Cream, and Blue Cheer. The inspirations weren’t limited to these bands, but these are bands whose elements can easily be seen in early Rush.

The main thing Rush lacked on their first album was a drummer who could match those bands; John Rutsey was competent as a bricklayer drummer (he could hold a beat, and played competently, but you wouldn’t note the drums except to say that they were there.)

As a result, early Rush focused very heavily on guitar; it was a vehicle for Alex Lifeson to play solos, and the songs were… all right. There were certainly good songs on the first album, including songs good enough to be played live through Rush’s entire career, but they were still vehicles for Lifeson.

Geddy Lee’s role on bass for the first album was really to provide the basis for the rhythm section to underpin the guitar; the drums were okay, but not good enough to stand up to the guitar, so that fell on Lee to not be overshadowed. I think it’s fair to say he succeeded well enough, but you could mostly hear that the bass was played well, but was not astoundingly composed.

When Rush added Neil Peart, though, all that changed; now the drummer was no longer the limiting factor of the rhythm section and we could see Rush change from a guitarist and his backing band to an actual team of musicians. Not only did Lifeson no longer have to carry the band, but all three members could stretch however they wanted, musically speaking, and their fellow musicians could meet them at the peak of their abilities.

On Fly By Night, Lee could show us a little more of what he could do, and started transitioning away from a traditional bass player’s role – where he held down the root notes and played the occasional flourish – into a more legato, melodic role. It wasn’t a “lead bass” the way you might find The Who’s John Entwhistle playing, but it was a much more harmonically active approach than you found on the first album; Fly By Night is where you start to get a sense that Geddy Lee might be a monster on bass.

One simple way to imagine the shift is to think of how one composes, or learns, bass lines. Imagine a song is written with relatively simple chords: Am, C, D, and Em, for example. If that’s the progression of the chords, one chord per measure, one can imagine a competent (albeit boring) bass line built around the roots of those chords. In measure one, you’d hold down an A note; measure two, the C; measure three, the D, measure four, the E.

That’s very simple, but it’s also something you’d find in probably a thousand rock songs: the bass is a foundational instrument, not a melodic instrument, and plays the song over playing any frills. Bass players might address uniqueness through rhythm, but not really note choice, in this basic scenario.

There are, of course, other choices. Another option is to play melodic ruffles through those measures; instead of just holding down an A, play a climbing melodic run to match the tone of possible lyrics, for example, or emphasize the rhythmic content or match a ruffle by the drummer. In other words, the bass player could play something approximating a melody (or the melody itself, if you can imagine that!) or amplify the rhythm through note choice.

To play the former, one simply has to know the chords of the song; to play the latter approach, one has to know the song, and replicating such lines means actually knowing the entire song as it was played, including the flourishes.

This is the bridge that Lee found himself on, on Fly By Night, where songs like By-Tor and the Snow Dog had far more complex bass lines and rhythmic structures. It’s not that he abandoned the traditional role of bass, it’s that he played bass far more actively, melodically speaking, and his repetitions were more rare; to play Rush basslines from this period one has to pay attention to what specific note choices were made for each part of the song, although there still was a lot of repetition.

Lee added melodic content more and more for each album during this period, culminating with 1978’s Hemispheres album, which was a tour de force on bass, and while the song construction simplified after that album through the influence of New Wave and other musical styles, Lee’s approach on bass was still marvelously rich, from a melodic perspective.

The song that projected something different for me was “Vital Signs,” from Moving Pictures. This song is incredibly active on bass, but it’s not particularly melodically very rich; there’s an outro bass solo, but it has the sensation of releasing all of the tension from having built up the expectation of melodic richness from the rest of the song. (I believe there’s intent here, given the subject of the song.)

On Signals, the next album, Lee avoided the “high repetition” bass approach of Vital Signs; the approach didn’t really show up again until their next album, Grace Under Pressure, but there it showed up and nearly dominated the album, for bass, and the approach remained largely intact for the next five albums.

The approach is typified by high repetition, not simple playing; in many ways, the bass playing from Grace Under Pressure through Test for Echo is harder than the earlier, more melodically active bass lines were. They were very harmonically rich, and typically very active; the “repetition” is not an indicator that the bass playing was more lazy or easier. It was just more consistent from a song composition standpoint.

If you were able to play the bass from a given section of a given song, you could play that section multiple times during the song, and the song would be played “correctly.” There were still individual flourishes from time to time, but such moments stand out.

When Rush got back together as a working band for Vapor Trails, Lee returned to some of the more melodically rich form he’d had in their “second phase” career; he “grew up,” in that he was still using the higher repetitions from the post-Grace album period, but he was playing very aggressively, so there was a lot more of the harmonic and melodic richness you’d have found in the “golden era” from Fly By Night through Signals, particularly because Lee multitracked bass lines so much for Vapor Trails.

For Snakes and Arrows, he multitracked less, but the richness remained, to the point that playing Snakes and Arrows on bass is similar in basic approach to those earlier albums, where you learn melodic lines for each part of each song.

This post isn’t really revelatory, in that I don’t think it really says anything new; it’s just a recorded observation of how Lee approaches repetitiveness on bass for Rush’ song construction.

Migrating a WordPress Blog: Any Advice?

I like this blog, honestly. But it’s very crufty by now, having had multiple generations of multiple plugins tied to multiple versions of WordPress, and I’d love to clean it up.

Anyone have any advice on migrating content from WordPress to a clean install of WordPress, such that I can add plugins carefully to create a cohesive body of work again?

Messaging with MQTT and Javascript

I do a lot with messaging architectures, and because I work on embedded systems so much lately, my main broker protocol has been MQTT, used with Javascript. I learned something that surprised me this morning, even though it really shouldn’t have, given some thought.

MQTT is a common protocol used in IoT. It stands for “Message Queuing Telemetry Transport“, and the current specification for MQTT is 5.0. Common brokers include Eclipse Mosquitto, EMQX, and HiveMQ.

As its name implies, MQTT is designed to be super-light. It has some pretty nice features, including termination semantics, quality of service (guaranteed delivery), retention, and other facets, but the primary use is for fairly simple communication of small messages – the header has room for a “payload length” and it’s two bytes, so your maximum packet size is somewhere in the region of 64k bytes.

The thing about MQTT that got me was the subscription model. It would be convenient to have a handler per subscription:

// this code does not do what it seems to expect.
client.subscribe('rpc/1', 
    (message) => { 
        console.log('hey, we got a message on rpc/1: ${message.toString()}'); 
    });
client.subscribe('rpc/2', 
    (message) => { 
        client.publish('rpc/1', `hello, ${message}`); 
    })

As the comment says – who reads comments, right? – this code does not work. It looks like it should do something specific when a message comes in on rpc/1, and something different when a message comes in on rpc/2 – but it doesn’t. It actually solely establishes two subscriptions for the client connection and those “message handlers” will not be executed, ever, under normal circumstances.

MQTT clients in Javascript, using the mqtt and async-mqtt modules, use Javascript’s stream paradigm. Connections use on() to establish event handlers for events as they come through. Thus, a connection event emits a connect event, an incoming message emits a message event, and so on.

If you wanted to subscribe to two topics, as expressed above, you’d have a simpler subscription process:

client.subscribe('rpc/1');
client.subscribe('rpc/2');

This tells the client connection (and the broker) to handle any messages matching the topic name, including any wildcards you might want. You can have as many subscriptions on a single client as you like, although I imagine the brokers have rational limits.

That applies in the same way to message handlers. You add a message handler as a callback for the message event:

client.on('message', (topic, message) => {
        // assumes 'message' is a human-readable string!
        console.log(topic, message.toString());
    });

Here’s the thing: you can have multiple message handlers, too. And they’ll get every message that the client is subscribed to.

If we’re subscribed to rpc/1 and rpc/2, that same message handler gets any message posted to either of those topics. It won’t get any other messages – presuming we haven’t added any more subscriptions – but it will get every message for those subscribed topics.

What’s more, if we add another message handler – via client.on('message', ...) again – every message handler will get every message, without discrimination.

If the handlers should need to handle only specific messages, then they each have to implement that functionality – filtering on topic, for example, or message content.

An alternative approach – and the one I think is more appropriate, within the limits of resource consumption – is to have multiple MQTT connections, each one with subscriptions that match a specific functionality.

In our first broken example, we have two topics, rpc/1 and rpc/2, where a message written to rpc/1 emits a sort of “hello world” message, and a message written to rpc/2 causes a message to be published to rpc/1.

If we’re preserving connections to the broker, our message handler would have to look something like this:

client.on('message', (topic, message)=>{
    if(topic.endsWith('1')) {
        console.log('hello', message.toString());
    }
    if(topic.endsWith('2')) {
        client.publish('rpc/1', message.toString());
    }
});

In environments where sockets are less expensive – i.e., we aren’t worried about counting how many sockets we use – we can be a lot more clear:

const helloClient=MQTT.connect('tcp:localhost:1883');
const sayHelloClient=MQTT.connect('tcp:localhost:1883');

helloClient.on('connect', ()=>{
    helloClient.subscribe('rpc/1');
});
helloClient.on('message', (topic, message)=>{
    console.log('hello', message.toString());
});

sayHelloClient.on('connect', ()=>{
    helloClient.subscribe('rpc/2');
});
sayHelloClient.on('message', (topic, message)=>{
    sayHelloClient.publish('rpc/1', message.toString());
});

In most message queueing libraries, you would set up a handler for incoming messages on each subscription, but MQTT is designed to be lighter than that. This shows a clean way to handle topic propagation in MQTT.