By Claude Sonnet, Anthropic — based on a real debugging session with the sites you’re already reading this on

If you manage a WordPress site on cPanel hosting and your redirects have mysteriously stopped working, or your .htaccess file looks like it was written by several drunk people arguing over a keyboard, this post is for you.

This isn’t a theoretical tutorial. It’s a post-mortem of an actual broken site, with two real .htaccess files as evidence. The short version of what happened: two security plugins were fighting each other, and the redirects got caught in the crossfire. The longer version is worth understanding, because it will happen again on any WordPress site that isn’t set up correctly — including yours.

First: What Is .htaccess and Why Should You Care?

The .htaccess file is a configuration file that lives in the root directory of your WordPress site. Apache — the web server software that most cPanel hosting runs on — reads this file and follows its instructions every time someone visits your site.

It controls things like:

• Redirects — sending a visitor from one URL to another
• HTTPS enforcement — forcing all traffic to the secure version of your site
• Security rules — blocking specific IP addresses, preventing directory browsing, protecting sensitive files
• WordPress permalinks — the rewrite rules that make your pretty URLs work instead of returning 404 errors

The critical thing to understand is that .htaccess is processed top to bottom, and certain instructions can tell Apache to stop reading and act immediately. If something near the top of the file says “stop here,” nothing below it will ever run. This is the trap.

Who Writes to .htaccess?

This is where the chaos begins, because on a typical WordPress site, multiple things write to .htaccess automatically, and none of them coordinate with the others:

WordPress itself writes a block between # BEGIN WordPress and # END WordPress markers. This contains the rewrite rules that make permalinks work. WordPress regenerates this block whenever you save your Permalinks settings.

cPanel’s Redirects tool appends redirect rules when you use the graphical redirect manager in your hosting dashboard. It just tacks them on — it doesn’t check what’s already there or whether the ordering makes sense.

Security plugins write their own blocks, usually marked with their own # BEGIN and # END comments. Some plugins are well-behaved and only touch their own section. Others are aggressive and rewrite large portions of the file whenever they feel like it.

cPanel itself also writes PHP configuration blocks (the # BEGIN cPanel-generated sections) that you should never touch.

The result, on a site that’s been running for a few years with a few plugins installed and changed, is a file that looks like sedimentary rock — layers of stuff deposited at different times by different forces, some of it contradicting other parts, some of it left over from plugins that were uninstalled years ago.

The Two-Plugin Problem

Here’s the specific thing that broke the redirects on the sites I was debugging.

Both sites were running two security plugins simultaneously — one was Really Simple Security (formerly Really Simple SSL), and the other was either Shield Security or Solid Security (formerly iThemes Security). Running two security plugins at the same time is almost always a mistake, for the same reason you don’t want two people editing the same document at the same time without talking to each other.

Each plugin writes its rules to .htaccess. Each plugin, when it updates or when WordPress does something that triggers a file rewrite, may overwrite or reorder what it finds there. The result is a file where the sections end up in an order that breaks things.

Here’s what the broken file looked like, in simplified form:

# BEGIN Really Simple Security
RewriteEngine on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]   ← THE TRAP
# END Really Simple Security

# BEGIN WordPress
(empty — nothing here)
# END WordPress

RewriteRule ^Seasons2025$ "https://www.example.com/?page_id=68851" [R=301,L]
RewriteRule ^Seasons2024$ "https://www.example.com/?page_id=65856" [R=301,L]

See the [R=301,L] on the Really Simple Security rule? That L flag means “Last — stop processing rules after this one.” Every single HTTP request coming into the site hits that rule, gets redirected to HTTPS, and Apache stops reading. The custom redirects below it are never reached. They might as well not exist.

This is why adding new redirects through cPanel’s Redirects dashboard appeared to do nothing — cPanel was correctly writing the rules to the file, but the rules were being written below the trap.

The Second Site: A Different Symptom, Same Disease

The second site I looked at had the same two-plugin setup but a different outcome. Its .htaccess file was structured more sensibly — the Really Simple Security HTTPS rule came after the WordPress block, and the custom redirects came after that. So the redirects were probably working fine.

But that file had a different problem: bloat. Solid Security had been banning malicious IP addresses over time and writing each ban to .htaccess. By the time I saw the file, there were 45 banned IP addresses — each one listed three times in one format for compatibility with older Apache, and again in another format for newer Apache. That’s one security plugin contributing nearly 300 lines of IP ban rules to the file, and it will keep growing indefinitely.

This illustrates a broader principle: .htaccess files on WordPress sites accumulate cruft, and nobody ever cleans them out. The file becomes a graveyard of old rules from old plugins, duplicate entries, and orphaned directives.

The Fix: Clean File, Clear Ownership, One Plugin

Here’s how to get to a stable, maintainable state.

Step 1: Pick One Security Plugin and Remove the Other

If you’re running two security plugins, stop. Pick one and fully delete the other — not just deactivate, but delete it entirely from the Plugins menu. Deactivated plugins can still leave their .htaccess rules behind.

For most small to medium WordPress sites, Wordfence (free version) is the right choice. It’s the most widely used WordPress security plugin, has a robust free tier, is well-maintained, and is generally well-behaved about .htaccess — it only writes to its own marked section and leaves everything else alone.

If your main reason for running Really Simple Security was HTTPS enforcement, you don’t need a plugin for that. The HTTPS redirect is a single rule you can put directly in .htaccess yourself (see below), and cPanel/Let’s Encrypt handles the actual SSL certificate.

Step 2: Understand the Sections and Their Order

A clean, correctly ordered .htaccess for a WordPress site on cPanel should look like this, from top to bottom:

1. Security plugin block (e.g., Wordfence) — firewall rules, IP blocks
2. HTTPS redirect rule — force all traffic to HTTPS
3. Your custom redirects — the ones you actually care about
4. WordPress block — permalink rewrite rules (# BEGIN WordPress / # END WordPress)
5. cPanel PHP configuration — the auto-generated blocks you never touch

This ordering is important. With pretty permalinks enabled, the WordPress block contains a catch-all rule (RewriteRule . /index.php [L]) that grabs any URL that isn’t a real file or directory on disk. Your redirect targets are never real files or directories, so if your custom redirects are below the WordPress block, WordPress intercepts every request first and returns a 404 before your redirects ever fire. They silently do nothing.

Custom redirects above the WordPress block work correctly regardless of whether you’re using plain or pretty permalinks.

The HTTPS rule needs to come before your custom redirects but must not use the [L] flag in a way that swallows everything else. Here’s a safe version:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

This is fine because the [L] flag here only fires for HTTP requests — if the request is already HTTPS, the RewriteCond above it fails and processing continues normally to the rules below.

Step 3: Don’t Use the cPanel Redirects Dashboard

I know it’s tempting — it’s right there in the interface and seems like the easy way. But the cPanel Redirects tool appends rules to .htaccess without any awareness of rule ordering. It will drop your redirects wherever it feels like, which may be after a rule that stops processing.

Instead, add your redirects directly to .htaccess using cPanel File Manager. Open the file, find your custom redirects section (above the WordPress block), and add your rules there. It takes about thirty seconds once you know the syntax:

RewriteCond %{HTTP_HOST} ^.*$
RewriteRule ^YourShortcut$ "https://www.yoursite.com/?page_id=12345" [R=301,L]

Replace YourShortcut with the short URL path you want (e.g., Birds to make yoursite.com/Birds redirect somewhere), and replace the destination URL with wherever you want it to go.

Step 4: Let Wordfence Write First, Then Add Your Rules

After you install Wordfence, let it do its initial setup. It will write its block to .htaccess. Then open the file in File Manager and add your custom redirects above the WordPress block. That way you’re building around what’s already there rather than having Wordfence overwrite what you wrote.

Step 5: Don’t Use the cPanel Redirects Dashboard (I’m Saying It Twice)

Seriously. Once you’ve manually set up your redirects in the file, if you later use the cPanel Redirects tool, it will append duplicate rules in the wrong place and you’ll be back where you started.

A Note on “Plain” Permalinks

If your WordPress site is set to Settings → Permalinks → Plain (the default, where URLs look like ?p=123), the WordPress block in .htaccess will be empty — just the markers with nothing between them. This is normal and correct. Plain permalinks don’t need rewrite rules because Apache handles query strings natively. The empty block is not a bug.

Custom redirects still belong above the WordPress block regardless of permalink setting. It’s the safe universal position.

Quick Reference: The .htaccess Cheat Sheet

Who writes what:

Rule of thumb for ordering: Security → HTTPS → Your redirects → WordPress → cPanel

When something breaks:

1. Open .htaccess in File Manager and look at the order of sections
2. Check whether any rule near the top has [L] and is catching all traffic
3. Make sure your custom redirects are above the WordPress block
4. Check whether you have two security plugins installed

When you add a new redirect:

• Use File Manager, not the cPanel Redirects dashboard
• Add it in the custom redirects section, above # BEGIN WordPress
• Test it immediately after saving

What This Doesn’t Cover

This post is specifically about Apache/cPanel hosting. If your host uses Nginx instead of Apache, .htaccess files don’t apply at all — Nginx uses a completely different configuration system that you usually can’t edit directly on shared hosting. In that case, use a plugin like Redirection to manage redirects from within WordPress instead.

It also doesn’t cover WordPress Multisite, which has its own .htaccess requirements, or situations where the file permissions on .htaccess are wrong (should be 644 on most hosts).

The Bigger Lesson

The .htaccess file is one of those things that works fine until it doesn’t, and when it doesn’t, the failure mode is invisible — your redirects just silently do nothing, with no error message to tell you why. The root cause is almost always that multiple things are writing to the same file without coordination, and the ordering ended up wrong.

The fix isn’t complicated, but it requires understanding what the file actually does and taking deliberate ownership of it rather than letting plugins and cPanel tools manage it by committee.

Once you’ve got a clean, correctly ordered file and a single security plugin that knows its lane, it stays fixed. These aren’t the kind of problems that recur on their own — they recur because the conditions that caused them (too many plugins writing to the same file, using the cPanel Redirects tool) are still in place.

Clean it up once, manage it deliberately going forward, and you won’t have to think about it again.

Claude Sonnet is an AI assistant made by Anthropic. This post was written based on a real debugging session analyzing .htaccess files from two WordPress sites running on cPanel hosting. The author does not have a tractor and cannot help you fix yours.

By Claude Sonnet, Anthropic — based on a real debugging session with the sites you’re already reading this on

Note:  This is a guest post by my buddy Claude.ai, who helped me figure this out and agreed to write it up as a blog post for me.  All credit where credit is due…  Click here for a reference-card version.  Pro tip:  I bet if you point Claude at this page and maybe add a copy of the reference card to your chat, he can help you straighten out your .htaccess file too.

If you manage a WordPress site on cPanel hosting and your redirects have mysteriously stopped working, or your .htaccess file looks like it was written by several drunk people arguing over a keyboard, this post is for you.

This isn’t a theoretical tutorial. It’s a post-mortem of an actual broken site, with two real .htaccess files as evidence. The short version of what happened: two security plugins were fighting each other, and the redirects got caught in the crossfire. The longer version is worth understanding, because it will happen again on any WordPress site that isn’t set up correctly — including yours.

First: What Is .htaccess and Why Should You Care?

The .htaccess file is a configuration file that lives in the root directory of your WordPress site. Apache — the web server software that most cPanel hosting runs on — reads this file and follows its instructions every time someone visits your site.

It controls things like:

• Redirects — sending a visitor from one URL to another
• HTTPS enforcement — forcing all traffic to the secure version of your site
• Security rules — blocking specific IP addresses, preventing directory browsing, protecting sensitive files
• WordPress permalinks — the rewrite rules that make your pretty URLs work instead of returning 404 errors

The critical thing to understand is that .htaccess is processed top to bottom, and certain instructions can tell Apache to stop reading and act immediately. If something near the top of the file says “stop here,” nothing below it will ever run. This is the trap.

Who Writes to .htaccess?

This is where the chaos begins, because on a typical WordPress site, multiple things write to .htaccess automatically, and none of them coordinate with the others:

WordPress itself writes a block between # BEGIN WordPress and # END WordPress markers. This contains the rewrite rules that make permalinks work. WordPress regenerates this block whenever you save your Permalinks settings.

cPanel’s Redirects tool appends redirect rules when you use the graphical redirect manager in your hosting dashboard. It just tacks them on — it doesn’t check what’s already there or whether the ordering makes sense.

Security plugins write their own blocks, usually marked with their own # BEGIN and # END comments. Some plugins are well-behaved and only touch their own section. Others are aggressive and rewrite large portions of the file whenever they feel like it.

cPanel itself also writes PHP configuration blocks (the # BEGIN cPanel-generated sections) that you should never touch.

The result, on a site that’s been running for a few years with a few plugins installed and changed, is a file that looks like sedimentary rock — layers of stuff deposited at different times by different forces, some of it contradicting other parts, some of it left over from plugins that were uninstalled years ago.

The Two-Plugin Problem

Here’s the specific thing that broke the redirects on the sites I was debugging.

Both sites were running two security plugins simultaneously — one was Really Simple Security (formerly Really Simple SSL), and the other was either Shield Security or Solid Security (formerly iThemes Security). Running two security plugins at the same time is almost always a mistake, for the same reason you don’t want two people editing the same document at the same time without talking to each other.

Each plugin writes its rules to .htaccess. Each plugin, when it updates or when WordPress does something that triggers a file rewrite, may overwrite or reorder what it finds there. The result is a file where the sections end up in an order that breaks things.

Here’s what the broken file looked like, in simplified form:

# BEGIN Really Simple Security
RewriteEngine on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]   ← THE TRAP
# END Really Simple Security

# BEGIN WordPress
(empty — nothing here)
# END WordPress

RewriteRule ^Seasons2025$ "https://www.example.com/?page_id=68851" [R=301,L]
RewriteRule ^Seasons2024$ "https://www.example.com/?page_id=65856" [R=301,L]

See the [R=301,L] on the Really Simple Security rule? That L flag means “Last — stop processing rules after this one.” Every single HTTP request coming into the site hits that rule, gets redirected to HTTPS, and Apache stops reading. The custom redirects below it are never reached. They might as well not exist.

This is why adding new redirects through cPanel’s Redirects dashboard appeared to do nothing — cPanel was correctly writing the rules to the file, but the rules were being written below the trap.

The Second Site: A Different Symptom, Same Disease

The second site I looked at had the same two-plugin setup but a different outcome. Its .htaccess file was structured more sensibly — the Really Simple Security HTTPS rule came after the WordPress block, and the custom redirects came after that. So the redirects were probably working fine.

But that file had a different problem: bloat. Solid Security had been banning malicious IP addresses over time and writing each ban to .htaccess. By the time I saw the file, there were 45 banned IP addresses — each one listed three times in one format for compatibility with older Apache, and again in another format for newer Apache. That’s one security plugin contributing nearly 300 lines of IP ban rules to the file, and it will keep growing indefinitely.

This illustrates a broader principle: .htaccess files on WordPress sites accumulate cruft, and nobody ever cleans them out. The file becomes a graveyard of old rules from old plugins, duplicate entries, and orphaned directives.

The Fix: Clean File, Clear Ownership, One Plugin

Here’s how to get to a stable, maintainable state.

Step 1: Pick One Security Plugin and Remove the Other

If you’re running two security plugins, stop. Pick one and fully delete the other — not just deactivate, but delete it entirely from the Plugins menu. Deactivated plugins can still leave their .htaccess rules behind.

For most small to medium WordPress sites, Wordfence (free version) is the right choice. It’s the most widely used WordPress security plugin, has a robust free tier, is well-maintained, and is generally well-behaved about .htaccess — it only writes to its own marked section and leaves everything else alone.

If your main reason for running Really Simple Security was HTTPS enforcement, you don’t need a plugin for that. The HTTPS redirect is a single rule you can put directly in .htaccess yourself (see below), and cPanel/Let’s Encrypt handles the actual SSL certificate.

Step 2: Understand the Sections and Their Order

A clean, correctly ordered .htaccess for a WordPress site on cPanel should look like this, from top to bottom:

1. Security plugin block (e.g., Wordfence) — firewall rules, IP blocks
2. HTTPS redirect rule — force all traffic to HTTPS
3. WordPress block — permalink rewrite rules (# BEGIN WordPress / # END WordPress)
4. Your custom redirects — the ones you actually care about
5. cPanel PHP configuration — the auto-generated blocks you never touch

The HTTPS rule needs to come before the WordPress block but must not use the [L] flag in a way that swallows everything else. Here’s a safe version:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

This is fine because the [L] flag here only fires for HTTP requests — if the request is already HTTPS, the RewriteCond above it fails and processing continues normally to the rules below.

Step 3: Don’t Use the cPanel Redirects Dashboard

I know it’s tempting — it’s right there in the interface and seems like the easy way. But the cPanel Redirects tool appends rules to .htaccess without any awareness of rule ordering. It will drop your redirects wherever it feels like, which may be after a rule that stops processing.

Instead, add your redirects directly to .htaccess using cPanel File Manager. Open the file, find your custom redirects section (below the WordPress block), and add your rules there. It takes about thirty seconds once you know the syntax:

RewriteCond %{HTTP_HOST} ^.*$
RewriteRule ^YourShortcut$ "https://www.yoursite.com/?page_id=12345" [R=301,L]

Replace YourShortcut with the short URL path you want (e.g., Birds to make yoursite.com/Birds redirect somewhere), and replace the destination URL with wherever you want it to go.

Step 4: Let Wordfence Write First, Then Add Your Rules

After you install Wordfence, let it do its initial setup. It will write its block to .htaccess. Then open the file in File Manager and add your custom redirects after the WordPress block. That way you’re building around what’s already there rather than having Wordfence overwrite what you wrote.

Step 5: Don’t Use the cPanel Redirects Dashboard (I’m Saying It Twice)

Seriously. Once you’ve manually set up your redirects in the file, if you later use the cPanel Redirects tool, it will append duplicate rules in the wrong place and you’ll be back where you started.

A Note on “Plain” Permalinks

If your WordPress site is set to Settings → Permalinks → Plain (the default, where URLs look like ?p=123), the WordPress block in .htaccess will be empty — just the markers with nothing between them. This is normal and correct. Plain permalinks don’t need rewrite rules because Apache handles query strings natively. The empty block is not a bug.

Quick Reference: The .htaccess Cheat Sheet

Who writes what:

Rule of thumb for ordering: Security → HTTPS → WordPress → Your stuff → cPanel

When something breaks:

1. Open .htaccess in File Manager and look at the order of sections
2. Check whether any rule near the top has [L] and is catching all traffic
3. Make sure your custom redirects are below the WordPress block
4. Check whether you have two security plugins installed

When you add a new redirect:

• Use File Manager, not the cPanel Redirects dashboard
• Add it in the custom redirects section, below # END WordPress
• Test it immediately after saving

What This Doesn’t Cover

This post is specifically about Apache/cPanel hosting. If your host uses Nginx instead of Apache, .htaccess files don’t apply at all — Nginx uses a completely different configuration system that you usually can’t edit directly on shared hosting. In that case, use a plugin like Redirection to manage redirects from within WordPress instead.

It also doesn’t cover WordPress Multisite, which has its own .htaccess requirements, or situations where the file permissions on .htaccess are wrong (should be 644 on most hosts).

The Bigger Lesson

The .htaccess file is one of those things that works fine until it doesn’t, and when it doesn’t, the failure mode is invisible — your redirects just silently do nothing, with no error message to tell you why. The root cause is almost always that multiple things are writing to the same file without coordination, and the ordering ended up wrong.

The fix isn’t complicated, but it requires understanding what the file actually does and taking deliberate ownership of it rather than letting plugins and cPanel tools manage it by committee.

Once you’ve got a clean, correctly ordered file and a single security plugin that knows its lane, it stays fixed. These aren’t the kind of problems that recur on their own — they recur because the conditions that caused them (too many plugins writing to the same file, using the cPanel Redirects tool) are still in place.

Clean it up once, manage it deliberately going forward, and you won’t have to think about it again.

Claude Sonnet is an AI assistant made by Anthropic. This post was written based on a real debugging session analyzing .htaccess files from two WordPress sites running on cPanel hosting. The author does not have a tractor and cannot help you fix yours.

By the way, ChatGPT had to be coaxed through this a little bit.  It got the calculation of the compute ratio between the Apple II and the Mac Mini wrong by a factor of a thousand (those darn millions and billions…) the first time through.  You probably don’t want ChatGPT to reconcile your checkbook without looking over its shoulder.

Here’s the prompt to ChatGPT:

compare the computation, memory and disk specifications of my current 2024 Mac Mini (M4 processor, 24 gb RAM memory, 80TB of disk) with my Apple II (purchased new around 1980, 48 kB RAM memory, 16 kB language card).

then ignore the many impossibilities and estimate the approximate time it would take the Apple II to process a one hour WAV file of bird calls — a process that takes about 4 seconds on the Mac Mini.

then note that i have about 40,000 audio files in the dataset. using the prior estimates, extrapolate how long both computers would take to process all the files.

Here’s the response:

1. Hardware comparison

Computation

Compute ratio (order of magnitude):

~100 billion×  10 million x more computational power for the Mac mini (ChatGPT goofed on this one)
(very conservative for signal processing workloads)

Memory

Ratio:

~400,000× more RAM

Disk / Storage

Ratio:

~570 million× more storage

2. Single-file processing time

Given

• 1-hour WAV file
• Mac mini time: ~4 seconds
• Ignore all practical impossibilities for the Apple II

Extrapolated Apple II time

Using the ~10,000,000 × compute gap:

4 seconds × 10,000,000
= 40,000,000 seconds

Convert to years:

40,000,000 ÷ 31,536,000 ≈ 1.275 years

Apple II: ~12–13 years per file

3. Dataset-wide extrapolation (40,000 files)

Mac mini

40,000 × 4 s = 160,000 s

Conversions:

• ≈ 44.4 hours
• ≈ 1.85 days

Mac mini total time: ~2 days

Apple II

1.27 years/file × 40,000 files
≈ 508,000 years

Apple II total time: ~500 thousand years

4. Final summary

5. Perspective

One weekend on your Mac mini equals half a million years on an Apple II.

But I like this kinda thing as a blog post, so here is is.  Click on the pictures to embiggen them.

It starts out with the build (and takes a detour into revising the assembly the Vevor rake I bought to sit in my quick attach 3 point hitch setup).

The last part is a bunch of pictures before and after a day of raking the summer weeds out of the driveway.  I found this to be a LOT easier/better than using the land plane to do the job.  So from now on, I’ll use the land plane in the spring and the rake for the rest of the year.  Here’s a link to my post about the land plane.

The story begins with the 140 pound box crushing my little deliveries tub at the top of the driveway.  Awww.

We rassled it into the bucket and hauled it to the garage…

… and I started building it on the tractor.  Step 1 looked fine, the first piece dropped right into the quick-attach 3-point hitch.  But…

… which creates two puzzlers.  First, assembling according to the instructions made it too wide for quick-attach.  AND the top connection won’t work because they have you mount the diagonal bar right in the place where the top hook of the quick-attach wants to go.  More pictures about both of those in a minute…

Here’s the detour that shows how I got it to fit in my quick-attach.  First thing — there are lots of versions of these out there that are all slightly different.  The one I bought was the Vevor (which sits in the middle of this picture).

The tricky bit is that each of those assemble their 3-point slightly differently, so my scheme may not work for all of them.  For example the one in the upper left looks like the top hook will work — they’ve mounted the diagonal above the the bar that the top-hook wants to slide into.  But they still assemble the bottom so it looks like it will be too wide.  Best plan would be to get confirmation from your vendor that it’ll work with a 3-point before you buy it.  Second best would be to get detailed measurements and confirm for yourself.  Third best is cross your fingers and hope my scheme will work for you.

Here is how I handled the “too wide” problem.  I moved the two diagonal bars from the outside to the inside of that bottom piece.  That got me back to a width that fits in the bottom of the quick attach.

To make room for the top-hook of the quick attach, I assembled the top bolt with the diagonal bar on one side and then the two bushings next to each other, which made enough room for the top hook to come up and engage.

Here’s a string of happy pictures showing how it now fits in the quick attach.

This is one side of the bottom with a little bit of space…

This is the other side, snug but engaged.

This is a side shot showing that the top hook can now slide up past that moved-to-the-side diagonal piece.

Here’s the assembly.  Two bushings, THEN the diagonal brace.  Plenty of room for the top hook now.

Back to the build-out pictures…

My only minor complaint is that the rake can only be rotated in 45-degree increments.  I’d like less-aggressive angling options and may drill another hole or two at some point.  For now, I’ve found that swinging the 3-point hard to one side lines the (60″) rake up with the edge of the tractor tires and gives a little bit of pull-to-the-center angling.  Not too bad.

Putting tines on…

… gets pretty tedious and Marcie rescued me at the end by being a 3rd hand.

Done.

On to the before-after pictures.  I couldn’t find any good ones out on the ‘net.  So here’s the result of about six passes over the driveway — took about an hour each, so about a day to do about 3/4 mile of gravel driveway weed pulling.  Sure beats working.

A great project.  With a nice puzzler in the middle.

Catholic leaders say Wisconsin Catholic Tribune is political mail not authorized by the church

And, since he doesn’t have any copyright notices in his propaganda, here’s the whole thing.  Thanks for all your help you jerk.

My conclusion in a nutshell: I accept the new rates as they stand.  They seem fairer to coop members as a whole and I’m happy to carry the impact that my solar panels have on our shared infrastructure. 

I looked at three rate-change puzzlers: Demand Charge, Annual to Monthly True-Up and Rate of Return.  The rest of this post goes through them at a high level, and there’s an 18-minute video at the end that goes into more detail.

UPDATE: There is a new version of the spreadsheet and an additional video on how to use it at the very end of this post.

Click HERE if you would like to download a copy of the original spreadsheet I used to analyze the impact on our bills.  Go to that one to check my work.  Details are in the first video.  Contact me if you have questions or want some help.

Demand Charge

Riverland Energy Cooperative (aka REC) recently introduced a monthly demand charge for all members. It differs from old style (prior to residential solar) Demand Charges in that it is based on the highest flow in either direction – peak demand or peak production.  It’s calculated by finding the highest demand or production rate, averaged over a 15 minute interval and multiplying that number by a dollar to arrive at the monthly charge.  Here’s a typical month for me (October of this year):

My conclusions:

• Demand charges help build/maintain infrastructure
• I make large and unusual demands on that infrastructure because of my grid-connected solar
• Seems fair that I should pay for that privilege.  
• Looks like it’s never above $20/month total
• It’s only $5-$10/month more than I’d pay if I didn’t have solar

Annual to Monthly True-Up

This is the puzzler that got me started on this project.  I was curious to see what the difference would have been had this approach been in effect over the years that I’ve had solar connected to the grid.  It took me a while to put this together and my Hero of the Week, Scott Hayes from REC, checked my math.  He and the rates folks at the coop gave me a thumbs up on this part of the analysis.

Here’s the punchline page.  The “Old minus New” line is the one that shows the difference the new rate would have made. 

My conclusions:

• Fairer to both sides – reduces risk of mispricing credits
• Simpler for members and the accounting dept – eliminates the month to month “banking” accounting
• Minor impact on monthly cost (at least to me)
• My numbers may not be representative – you can try your own if you want
• Best time to switch to new rate – seems to be the annual “true-up” month
  
  

Rate of Return

Here’s a simple analysis of how the change to true-up would change the rate of return on the panels.  I calculated how much my kilowatt-demand charge would have been if I didn’t have the panels (the top row), compared that number with what I would have paid under the new rate and what I actually paid under the old rate (the middle two rows) and what the difference would be (the bottom row). 

Note:  Scott Hayes and I are having a friendly argument about that top-row number – I’ll update it when we settle.  Again, details of the calculations (and how you can do it yourself) are in the video that’s coming up Real Soon Now.

My conclusions:

• My rate of return on solar panels is negative – I’ve spent way more than I’ll ever recover. Fortunately, that’s not why we put them in – we do it mostly to reduce our carbon footprint and provide convenient whole-house backup power.
• The overall impact is minor – less than 10% change in cash flow
  
  

Video

Here’s a video that goes into about 18 minutes of detail as to how I got to those final pages

UPDATE – 12/16/24

I’ve revised the spreadsheet to make it easier for folks to use.  Click HERE for the new version.  And here’s a new “how to” help-video that goes with it.

Connecting over the wire (USB in the documentation) didn’t work, but using a Network MIDI connection did — with the advantage of not having to be tethered to the Mac.  Here’s a 45 second video that shows the following steps:

Open Audio Midi Setup and show the MIDI Studio window

Click open the Configure Network Driver window (the little globe in the top menu bar)

Enter and enable a Session (which defaults to Session 1 on both the Mac and the phone — confusing — this is the Mac Session 1)

“Network Session 1” should now be available in ShowMIDI

Head over to X/Y Pal on the phone and select a preset — “mike’s demo” in my case

Edit each device so that it points to the phone’s “Network Session 1”  (confusing, sorry)

Go back to the MIDI Network Setup window, select the phone and click Connect

That’s what I did to get X/Y Pal to talk to my Mac over WiFi.

Here’s a 45 second video of all that.  Click the pop-out icon to put it in its own window or just go full screen to really embiggen it.

• NTIA funding – both power increase and Bedford St. move
• CPB-qualification
• Bedford St. deal
• Board minutes from that period

Significant Events

• Applying FCC approval to change frequency and transition to vastly upgraded transmitter power and antenna facility on the west side of town.  Joan Rubel and Vinnie Curren worked on that, Steve Lewis and Ben Dawson assisted.
• Applying for and getting the NTIA grant.  We had NTIA funding for the power increase / move to WMTV’s tower and for the build-out of the new facility on Bedford Street.  Memories are currently vague about whether it was one grant or two, but funding was critical.
• Getting CPB qualified, with the Community Service Grant then rolling in to help subsidize operations.  Joan Rubel did all of that.
• Managing to buy the Bedford St building from STASH at a time when interest rates were 18%.  Joan Rubel and Mark Fuerst pulled that miracle off.

Documents and filings

FCC

Melissa Askew at the FCC and Samual Flores of Berry Best Services found this collection of documents related to the power increase.  Click here for a zipped archive of all the documents they retrieved.  [I haven’t exploded them into details yet, but they’ll go in this timeline]

• 1-22-79 — Application for the move the transmitter from Winnebago Street, to the west-side towers, radically increasing HAAT (and thus coverage) — granted 10-9-79 — I was gone (left in early summer 1977 to go to grad school) — Joan Rubel, Vinnie Curren and others can flesh out this story.
  • HAAT (height above average terrain) – 937feet,
  • ERP (effective radiated power) – 1.3kw
  • Antenna – Phelps-Dodge FMC-LP-2, 2 bays (a placeholder for the application)
  • Transmitter – ?? – no info in the FCC history cards
  • Location – 43°03’01.0″N 89°29’15.0″W

Reminiscences

• Vinnie — about the first test of the new transmitter and antenna

Oil change

Try a socket wrench on the drain plug – might be easier to get the leverage-pipe on it.

The tractor takes just over 2 gallons of oil, so a 2.5 gallon jug isn’t enough to do both the oil change and the hydraulic filter.  Three jugs will do both tractors and have a little to spare for topping up the hydraulic fluid reservoirs.  10W-40 or 15W-40 will work.  I’ve taken to using synthetic oil.  YMMV

Work out a gizmo to route the old oil out of the engine to the hole in the bottom of the tractor — it needs high walls around a fairly large catch basin that’s then routed to the exit via a wide path.  Goal is to avoid overflowing into the engine compartment.  Aluminum foil is going to be my material of choice for the next attempt.

Use the small funnel with the long flexible neck to snake into the filler — a single pour is a two-person job (one person holding the funnel, the other pouring).

Pay attention to where the handle on the dipstick winds up on the newer tractor — it has a curved rotating handle.  Make sure it’s rotated out of the path of the hood as it comes down.

Use grass-clippings/sand/gravel to clean up floor spills.

Hydraulic filter change

Use the breaker bar and pipe extender to break the filter loose — it’ll take about an eighth of a turn before it releases and it’s very hard to turn.  Thus it’s essential to know which way to rotate.  Figure out upside-down righty-tighty lefty-loosey in advance.

Prepare for a few ounces of oil spilling out as the seal breaks — relieving hydraulic pressure doesn’t seem to quite clear the pressure to the filter.  A couple rags per filter – one to catch the initial burst, another to clean and hold the outgoing and inbound filter.

Note that the path of the filter out and back in is a little twisty.  Down first, then out.

Use clean oil to fill the new filter.  Not quite all the way to the top, so’s to make it easier to navigate it into place and get the threads started without spilling.

Purge the air out of the system after installing the new filter using the longer one-ended hose so it can reach the reservoir under the driver’s seat.  Use short bursts of crank/run on the tractor where the deadman switch is disabled.

My interest is in the first two and a half years of Back Porch Radio — from a few months before it was incorporated until the station went on the air.  If anybody has any tips or info, please let me know.

Wishlist of documents

• Initial application for the FCC license (locations -FCC archives (Engineering File in hand, still looking for non-engineering exhibits).  Those are the exhibits that Tom Thomas, Terry Clifford and I wrote which describe the goals and vision of the station-to-be.  I’m waiting for that original document to settle into its new home at the National Archive in Kansas City.  Many of the words in our application can be found in the WORT Handbook, which was “taken word for word from a handbook published by KDNA, St. Louis, in 1971.”  Tom Thomas wrote the KDNA original.  click here for the WORT version of the handbook.

Key Dates leading up to going on the air

FCC “Broadcasting License Record” — This FCC microfiche summarizes the process of applying for the license  click here

Key Dates and Documents (click on the links where I’ve got copies of the documents — thanks to Melissa Askew at the FCC and Samual Flores of Berry Best Services for their help on retrieving these).  Click here for a zipped archive of all the documents they retrieved.

• 12/13/1973 – Incorporation — Back Porch Radio Broadcasting, Inc. is incorporated as a 501(c)3 nonprofit corporation.  Articles were drafted by me, with a lot of help from Robert Jay Stein (our Washington DC based lawyer), Terry Clifford and Tom Thomas (Terry and Tom eventually became the founding staff — and arguably leaders — of the National Federation of Community Broadcasters).   Filed with the state by Mike O’Connor (as incorporator).  Mark Korbell (a colleague of mine from WHA) and David Deveraux-Weber were the other two initial board members. (click here for Articles of Incorporation) and (click here for the Certificate of Incorporation)
• 12/17/1973 – Bylaws — These bylaws were established a few days later.  This copy is from a series of documents I shared with Bill Thomas when he was working on the application for WEFT (Prairie Air) in Champaign, IL and my comments suggest that he use a different set of bylaws as his model.   click here
• 4-12-74 — BPED-1816 — Application for construction permit — first received by the FCC — written by Terry Clifford, Tom Thomas and Mike O’Connor, engineering by Jeremy Lansman, filed by Robert Jay Stein.  This copy is from the FCC’s Engineering file and is missing most of the narrative parts of the application (the non-engineering ones) I’ll keep trying to track those parts down.  (click here for the Engineering Copy of the application, obtained from the FCC),  (click here for financial exhibits) and (click here for various narrative exhibits)
  • HAAT (height above average terrain) – 149 feet,
  • ERP (effective radiated power) – 8.54kw
  • Antenna – Gates-FMA-3, 3 bays
  • Transmitter – RCA-BTF-3 (3kw output power)
  • Location – 101 E. Mifflin St (the top of the YWCA Building) –  43°04’34″N 89°23’09.0″W
  • Funding Guarantee – $10,000, provided by Mike O’Connor (see financial exhibits above)
• 5-25-74 — Letter to WORT and WUWM — notifying both applicants of an interference collision between our applications encouraging us to work it out between us.  WUWM (Milwaukee) was pursuing a very complex application for a major facilities change.  Neither of us were aware of the other application because they arrived at the FCC almost simultaneously. (click here)
• 8-16-74 — Our amendment resolving an interference issue — in which we reduced our proposed transmitter power from 3kw to 1kw in order to avoid disrupting the application from WUWM.  Engineering by Jeremy Lansman, submitted by Bob Stein and Mike O’Connor.  (click here)
• 9-20-74 — Request for information as to the availability of the operating funds we described in our application.  They’re comprised of a loan of $10k from Mike O’Connor and additional money from donations and fundraisers.  Another exchange I don’t remember, but we must have satisfied them with our response.  (click here)
• 11-14-74 — Construction permit granted!!  Woohoo!   This was probably when we fully came out of “stealth mode” and really started promoting the project to the Madison community.  (click here for the permit and here for some FCC internal engineering working papers)
• 1-17-75 — Call letters assigned — we first applied for WART, but by the time our request arrived at the FCC that call had been snapped up by an “arts” station.  John Ohliger (RIP) mentions my bright (and quickly shot down) idea of WOMB in his “Early Days at Back Porch Radio” speech.  (click here)
• 3-1-75 — An early call-to-action story now that the license had been secured (thanks to Stu Levitan for this one)
  
• 5-13-75 — Application to amend the Construction permit to move the station from Capital Square to 2047 Winnebago St — written/submitted by Mike O’Connor, engineered by Jeremy   Note the cool WORT stationary created by Jeff Lange.  There’s also a letter from Earl Fessler confirming his commitment to lease us his facility for the princely sum of $175/month.  I wish he had been in better health during those days — that lease had a lot to do with getting us on the air as quickly as we did. (click here).
  • HAAT (height above average terrain) – 104 feet,
  • ERP (effective radiated power) – 3.975kw
  • Antenna – Earl Fessler’s Collins 732-A, 4 bays
  • Transmitter – Earl Fessler’s Collins 37-M-8 (rated at 8kw(?, Pat Ryan, serial number?) but we only used the first, 1kw, stage) output power 1kw
  • Location – Earl Fessler’s old WMFM studios at 2047 Winnebago Street – 43°05’35.0″N 89°21’12.0″W
  • Funding Guarantee – $10,000, provided by Mike O’Connor
    
• 8-4-75 — Application-to-move-to-Winnebago granted (click here)
• 11-6-75 — FCC Form 341 — Application to transition out of Construction Permit to fully-licensed.  This is primarily a technical document demonstrating that the station was capable of broadcasting in accordance with FCC standards.  Prepared by Pat Ryan and Mike O’Connor.  (Click here) 
• 3-9-76 — Broadcast License granted (we went on the air under the Construction Permit and ran that way for several months before the permanent license was granted). (Click here)
• And not really an event, but something people tend to forget — CETA funding.  For the first few years, much of the staff was paid for (not very much, though!) by CETA grants.  It’s hard to imagine how the station could have become so impactful in its early days without that funding.

First broadcast – December 1st, 1975

Many thanks to Aaron Scholz who recovered and restored this recording from the original recorded by Richard Mahler (RIP) who’s no longer with us.  Richard was focused on audio and news news production and Spanish-language programming and recorded our broadcast from his home.  Click here to read his recollection of that event in the “WORT – 25 Years of Community Radio” book.

I’m running the board and was spectacularly unprepared for the broadcast.  I hadn’t previewed John Ohliger’s demo broadcast and cut away from it abruptly when some reversed audio appeared.  To compound my error I blamed John for the problem.  Argh!  But wait, there’s more.  I also hadn’t checked to see if the next show I cut away to was ready to go.  What a mess.  It’s no wonder Richard panned my effort in his article.

Here’s a list of the voices I recognize and the first few places they appear:

Key Events/Dates of the Big Upgrade – late ’70’s

This section got too big for this post – click here

Scans of early newsletters – Spread the WORT

Volume One Number I – click here for the whole issue

Published April 1975

I’m missing this one — any help tracking one down would be much appreciated.  All hail Doug Ranney, audio-archivist at WORT.  He just sent me a link to his scan of the issue which I’ve poached and posted above.   He’s got LOTS of historical material (and might be interested in some help with his archiving effort).

Volume One Number II – click here for the whole issue

Published mid-summer 1975

I write about how these alternative institutions we’re creating provide value to da peepul who do the work.

Don Alan – writes about how decision-making was coalescing in the emerging program, news and music committees.  The consensus process that we evolved at WORT left out (at least) one thing — how to avoid the single-person veto — so we had some really exhausting meetings.

Jeff Lange (RIP) – writes about the implications of the decision to abandon our plan to house the station and transmitter on the Square and instead rent Earl Fessler’s old WMFM studio, transmitter and tower on Winnebago Street.  In hindsight, that probably saved us a year or more getting on the air.  Note:  we organized and put that station on the air in 1 year after we came out of stealth mode with a  construction permit and announced the project to the world.  Not bad!

Somebody (me?) – provides a status update on the big accomplishments since the first issue came out.  The first example of the staggeringly small amounts of money that powered the effort.  Raised $4000, spent $1,800.

Don Alan – writes about the National Alternative Radio Konvention, which, since we didn’t have enough to do getting the station on the air, I volunteered us to host.  Don’s opener captures this pretty well.  “A National Alternative Radio Konvention (NARK), so unkle Mike hasn’t been dragging us halfway to the moon by our ears with endless dribble about a “pie in the sky” radio that’s listener-sponsored, with community input and free-form programming.  No folks, skeptical as I can be, this scheme is real, crazy maybe, but NARK displayed that it does work and it’s beautiful.”

John Ohliger (RIP) and I – write about the two community-radio cultures we hearken from.  John writes a story about Pacifica and I write about the KRAB Nebula.  KRAB Nebula was Lorenzo Milam’s gang of crazy people (including me) who founded lots of community radio stations in the early 70’s.

WORT made it into Lorenzo’s list of “Sympathetic Broadcasters” in his third edition of Sex and Broadcasting.  Click here for the list.  The entry must have been written between the end of 1974 (when the CP was granted) and mid 1975 (when we signed the deal with Earl Fessler) because WORT’s address is my apartment on Midtown Road, Verona (much less snazzy than what’s out there now).

Gay Eder (aka Goldie) – shares the recipe for a WORT-shake and writes about our outings to salvage an old Wisconsin Public Radio transmitter.  She reminds us of my accidentally not shutting off the 440 power to the transmitter thus almost electrocuting Mark Stoelting (another WHA engineer who, along with Pat Ryan and Al Reiland, built almost all of the audio and radio infrastructure at WORT).  Other senior engineers at WHA very quietly helped us as well but chose to remain anonymous at the time and I’ll continue to honor that promise unless we can track them down.

That transmitter was our third — Jeremy Lansman had one that we specified in the application, this one was the one we were planning to use until the third one (Earl Fessler’s Collins) came along.

So this one eventually made it’s way to Cincinnati and became the transmitter for Nan Ruben and Steve Lewis’s WAIF (Stepchild Broadcasting) project.  I drove the transmitter out there in my van and participated in getting the transmitter on the roof.  There was a very tense moment when the crane that lifted the transmitter to the top of the building turned out to be just a foot too short for the transmitter to clear the knee wall around the roof — so the crane operator “swung” the transmitter over it and a few people (with no safety gear at all) “caught” it and lifted it the rest of the way over the wall.

Jerry Dahlke (RIP) – writes about the two benefit concerts that happened that summer — one by Bonnie Raitt (who would later return for a repeat visit).

Themes:

The layout — these early hand-drawn WORT newsletter just gun me down.  My memory is that Jeff Lange did the the heavy lifting but it seems like others must have contributed too.  Pay especial attention to detail when looking at the front-page layouts.  Astounding.

The crystal — several mentions of the new crystal that we needed to buy in order to re-tune the transmitter from the WMFM frequency to WORT’s 89.7.  That re-tuning, not just of the ancient transmitter but also the antenna, is the gating item that needed to get done before we could go on the air.  Pat Ryan bore the brunt of the pressure on that Herculean effort.  I did the tower-climbing stuff (dismounting and remounting the antenna and coax, and tuning the antenna).  The first time up the tower was terrifying — Jeff Lange (RIP) was my spotter — we sat at the bottom of the tower cried together when I got back down to earth.

The advertisements — are a wonder to behold.  Some bring back fond memories of Madison in that time (and of their owners, who were our sponsors).  Others are just a laugh riot and display wondrous creativity.

Volume One Number 3 – click here for the whole issue

Published in November 1975 — the last issue before we went on the air.  The period leading up to the December on-air date was grueling for Pat Ryan, Mark Stoelting and Al Reiland, the engineers who carried us across the finish line.

Undetermined author (me?  Jeff?  Don?)  – chronicles the “whole history of WORT” which lays out a timeline of events that mirrors my recollection.

• WORT was a new project (and corporation) that came after several prior community-radio efforts, including David and Danielle Deveraux-Weber’s Human Radio Corporation.
• I was set on this project by Lorenzo Milam after I told him that I was following my sweetheart Carol Patterson to Madison.  My recollection is that Lorenzo provided funding that supported the effort to apply for the FCC license but I never knew the details.  Terry, Tom and Bob (see immediately below) might.
• The first year was the “stealth” effort by Terry Clifford, Tom Thomas, Jeremy Lansman, Bob Stein and me to shepherd an application through the FCC without letting anybody in Madison know about the frequency that Jeremy had found for us (for fear of drawing a Petition to Deny like the ones that had stalled similar efforts in Minneapolis and Chicago).
• The second year was the very-public year-long effort to organize and build the station that quickly added the core volunteers who you’re reading (or reading about) in these newsletters.

Jeff Lange (RIP) — writes about the “curious fack” that nobody can quite explain how decisions get made at the station.  A lovely piece that reminds me so strongly of Jeff every time I read it.  I really miss that guy.  I think David Chandler had it right when he wrote in WORT – Madison: 25 Years of Community Radio   “To this day I believe Jeff was the indispensable person at WORT.  He could do almost anything and he did — wiring, carpentry, paste-up, painting, carpet-laying, writing, artwork, ‘requisitioning.’  He launched ideas and provided inspiration of all kinds, and eventually carried a ten-ton load of recruitment, training and production work.  Despite his deeply guarded personality, Jeff was a leader because he was a doer.”

I will add another unsung contribution — the Back Porch Radio Handbook published in 1977.  It’s a revised version of the KDNA Handbook which was written and assembled by Tom Thomas and published in the January 1972 edition of KDNA’s program guide Fat Chance.  This remains one of the most succinct summaries of the goals and values of the community radio movement that I’ve ever read.  It would be neat to update it again, given today’s digital reality.

Unknown — writes about the horrific radio interference that overwhelmed WORT’s immediate neighbors.  Living right next to a broadcast station is miserable because of that interference – which is allowed (and protected) by the FCC.  We did what we could to help, but…

Progammers! — write program listings!  For their programs!

Unknown authors — write program listings!  For tapes from Bill Thomas and Betsy Rubinstein’s NFCB Tape Exchange (see below).

John Ohliger (RIP) — writes about his hopes, dreams and fears about what WORT might become.  I think the 50th would have seen him smiling broadly were he still with us.

David Chandler — writes about the number and variety of formats of shows that will appear on WORT — comparing it to the (then dying) “Progressive” radio format.

Jeff Lange (RIP) and unknown others — lay out the first edition of the Program Schedule — a masterpiece of hand drawn and hand lettered design that occupied the centerfold of the newsletter.  A stupendous undertaking.  Capturing the pioneering programmers who all worked hard at non-programming tasks too — as that was kinda the expected thing, doncha know.

Don Alan — reports on the “constitutional convention” meeting of the National Federation of Community Broadcasters in Columbia, MO (hosted by Pat Watkins, Steve “Checker” Dreher and the other volunteers at KOPN) that followed up the NARK meeting.

John Ohliger (RIP) — writes an invitation for folks to create radio dramas at WORT.

Themes:

This was the last of the three “pre-air” newsletters.  There were a lot of people who had worked really hard to get us to that place.  You’ll have seen articles by some of those folks, but check out the centerfold Program Guide for lots more.  And there were even more than that.  For example, the people who did the engineering (Pat Ryan, Al Rieland, Mark Stoelting and many others) don’t appear in these pages for the most part.

I love this issue because it captures the Whole Thing — the excitement of an oncoming launch, the exhausted satisfaction from many big accomplishments and jobs well done, the hopes for the future.  Pretty darn nifty.

Volume Two – January 1976 – click here for the whole issue

Jerry Zeiger — writes about the effort he led to build up a record library for WORT.  A daily event was the hoped for arrival of new records — some days none, some days a couple and on Good Days five or more.  All had to be cataloged, ID’d with colored tape on the end and shelved.  I think Jeff Lange built the shelves, which looked pretty empty at the beginning.

John Ohliger — writes about Media Interbang, a weekly commentary about bias in local TV news coverage. .

… and more…  i’m still working on this stuff…

Tips:

To just remove the pulley (say, to tighten the silver bolts underneath) just loosen the grub screw that locks the assembly to the key.  The whole pulley assembly can then be lifted off without having to break the pulley away from the hub.

Hmm…  Might work for dropping the blade-hub out too.   That would save a lot of these steps.

But just in case you’re just as stupid as me and you want to set it back to the Mac OSX default, here’s what I did.

First handy item – a command-line to display exactly what IFS is currently set to

echo -n "$IFS" | hexdump -C

Second handy item — a target to shoot for.  The answer I got from a different Mac that hadn’t been stupidly tinkered with was space, tab, newline, zero (as seen in the following hex that popped out of that command on that machine):

00000000 20 09 0a 00 | ...|
00000004

Third handy item — a command to load those values

IFS=$' \t\n\0'

After entering that string, both the normal Mac and the stupidly-tinkered-with Mac show the same values.

Most examples I came across left off the zero at the end, but I figured maybe OSX does things differently than regular Linux and tacked it on.  I’ll amend this post if things break.

The puzzler:  Building a 20-person mix-delete audio routing template in my Pretty Good Jacktrip Toolkit crashes (moderately-sized) Linode servers.  They seem to crash when automating large numbers of Jack-connection adds or deletes — issuing a delete-all with JMESS for example.

The hypothesis: Jack works OK, it’s the number of connections per endpoint that’s causing the trouble.

The idea to get around this (so far): split the mix-minus routing in two by putting players in sections.

There are now two mix-minus routings (“Each-player-in-section to All-other-players-in-section” and “Each-section to All-other-sections”), which still grow geometrically but result in much lower endpoint counts and thus will hopefully scale larger.

I’m testing this idea with 20-person-ensemble Ardour and JMess templates.  The Ardour template configures the mixer/DAW, the JMess template sets up the audio routing in Ardour each time players join.  They will be included in the Toolbox once I’m convinced they’ll work.

The Configuration:

Here’s the puzzler: a 20 person mix-minus routing (where every person is connected to everybody else).  That’s N(N-1) or 20×19 or 380 connections (19 connections per endpoint) times 2 (because there are two endpoints per connection) for a total of 760.  This is an old picture, so its got 21 players and is also in stereo, multiply by 2 again.

This is the pretty picture representing a challenging puzzler:

Here’s the proposed mix-minus routing for people within four groups – everybody in the group can hear everybody else.  See?  Not nearly as many connections at each endpoint.

The swooping-up curvy wires are bringing all-other-sessions audio to each person — see the next picture.

Here’s the mix-minus routing between the four groups.  People in every group can hear a mix of every other group.  This is another way to visualize the lower number of endpoint connections.

The swooping-down curvy wires are bringing player-audio into session-mixes — see the last picture.

A bonus.  This routing gives us “section mixes.”  Here’s a picture of the mix panel where they appear.

The results:

Aug 27, 2021  The 20-player x 4-group configuration runs, JMess can delete and reload routings and this setup can accept at least 1 Jacktrip connection in Linode’s smallest configuration (a “Nanode” which has 1 CPU, 1GB Ram, 512k swap, 25Gbyte disk, and costs $.0075/hour capped at $5.00/month).

It’s taxing the Linode right to the max (almost no memory or swap left, CPU routinely running between 50-80%).  JMess takes about a minute to tear down and refresh all the connections).  Moving up a notch or two runs more crisply — I’ve been routinely hosting sessions and doing development in a Linode 4GB ($.03/hour capped at $20/month).

Nanode test1.  I want to see how much load the tiny Nanode can handle.  This test was of the full mix-minus routing even though there was only one connected Jacktrip session.  That generates hundreds of additional audio channel connections to the stress-test.

All the channels worked.  Audio recording works — I recorded both the regular and broadcast channels of the  session.  A click click appears at exactly the same point in both recordings (presumably it came from me) — it’s a little more pronounced in the Broadcast-channel recording.

Here are audio-recording snippets, downloaded from the Nanode:

–  Regular-channels – stereo – 17seconds – 48k – wave

–  Broadcast-channels – stereo – 17seconds – 48k – wave

UPDATES — scroll to the end

April 2026 — I’ve used it for a while… and this replacement part is no longer being made. I’ve added some stuff about both topics at the end.

Starting point — March 1st, 2020 — the old cover

The new cover arrives – March 7 2020

Check out this post to get part numbers for the new hood.  The description of the hood is in the paragraph just before the video, the part numbers are just after.  With 20/20 hindsight I should have ordered the new knob and latch mechanism, but it wasn’t too hard to move the old one over.  Here’s the link — go there for part-numbers at a minimum.

http://www.halfinchshy.com/2011/04/upgrading-performax-16-32-to-sandsmart.html

Removed the new-cover hinge-mounts – March 8, 2020

… and notched the hinge-indentations to match the old/standard cover.  This is the best view of the difference in size between the old 2.5 inch port and the new 4 inch port – about 2.5 times the area (and thus airflow) which should help a lot.

And that’s where those two parts sat until today — June 20, 2021.

I got stuck trying to figure out how to mark the place to drill the holes for the hinges.  My pal David was over and suggested putting the cover in the open position, which would put the hinges on top of it.  Easy to mark from there.  <facepalm>

So I finished it up this afternoon.  Here’s the hinge side…

Here’s the handle side.  Black tape covers the pre-drilled hole for the handle.  It would have been clever to order the new knob and catch (check those numbers out in the post-link above).  But it wasn’t hard to mount the old hardware.

Old hardware, remounted…

With a reminder as to how to open the latch.

2026 UPDATE

My experience with this has been great.  Using a bit more caution and running with this dust cover has been a joy and I now use the Performax regularly without troubles.  So much for the good news.

The bad news is that this part is no longer being made.  So when Wayne asked me about getting one I came up dry and turned to my favorite AI (Claude) for answers.  He landed right where I was headed — a 3D-printed replacement.  I’ll see if Ralph has a 3D scanner.  If he does i’ll run my dust cover through it and post it here.  Claude came up with some other options as well — here they are:

Good news — there are real options here.

Drop-in replacement: probably not. The 80-8002 dust cover for the original Performax 16-32 (with the 2.5″ port) is discontinued and nothing is being made as a straight swap.

What does exist:

1. 1. Quality First Wood Products (q1wp.com) — they make 3D-printed aftermarket parts for obsolete woodworking machines, including the Jet 80-2003 dust cover for the 22-44 sander. Worth contacting them directly to ask if they make or will make an 80-8002 equivalent. They explicitly advertise custom work.
   2. Free STL file on Printables.com — someone designed a 4″ dust port adapter specifically for the older Performax 16-32 with the 2.5″ port. It requires cutting the existing cover to enlarge the hole and drilling two mounting holes for bolts, then using caulk or foam tape to seal it. So if you have access to a 3D printer (or a service like Craftcloud/JLCPCB), that’s a free path to the large-port setup.
   3. The 22-44 cover hack — the Performax/Jet 22-44 dust cover has a 4″ port and some people have cut it down and adapted it for the 16-32. Availability on eBay is hit or miss but worth checking periodically.

DIY option if none of the above pan out:

Cut out the existing 2.5″ port on your current cover, enlarge the hole, and bond a 4″ dust collection port (available from Grizzly, Rockler, Woodcraft) using JB Weld or similar adhesive. It’s not elegant but it works and preserves your existing cover as the structural piece.

One thing worth checking before you commit: going from 2.5″ to 4″ drops air velocity significantly — someone on Sawmill Creek suggested making a cardboard mockup to test before cutting anything. If you’re already running a strong vacuum, the velocity loss may hurt more than the CFM gain helps, depending on your dust collector’s specs.

This post is for a person using command-line connection to Jacktrip and Qjackctl to manage Jack (which is the way we did it back in March of 2021).  It creates a single virtual device to route audio to and from Jacktrip.  This makes Qjackctl a lot easier to manage by providing a single interface that can be used for both input and output.

These days JackTrip has a terrific graphic user interface (GUI) that can manage audio input and output devices directly through RT Audio (eliminating the need to use Qjackctl).  In that case I would suggest creating a separate Loopback devices for audio being sent to Jacktrip and audio being received from Jacktrip.  It’s much easier to keep things straight and just as flexible.

Here’s a step-by-step post about routing Jacktrip audio using Rogue Amoeba’s Loopback software.  Loopback is a for-money successor to Soundflower and similar to BlackHole.  I like it because it is more visual and does more stuff.

The goal of this post is to get a person with a 2×2 interface going with a setup that will let them join a Jacktrip session reliably, without having to “rewire” things each time.  It also covers things like routing audio into and out of other audio software like Logic Pro, Ableton Live, Max and Zoom.

Alas, this is for Mac folks only.  Windows audio puzzles me.  I don’t have a clue how to do this on a Windows machine.

There are links to short videos that “animate” each of these steps and examples.   Click on the pictures to embiggify and read them.

Step 0: Assumptions – Click here for video

Step 1: Starting out – Click here for video

Create a new Loopback device.  This is just like a 2-channel Soundflower or Blackhole device – apps can send 2 channels to this gizmo, and other apps can listen to those two channels.

Step 2: Add components – Click here for video

It’s good to make a list of sources and destinations for audio and add them all at once.  Loopback makes guesses about the routing, which are fine but those guesses won’t work for what we’re doing.  Adding things later will sometimes cause Loopback to “rewire” the whole setup.

Step 3: Clear out default routings – Click here for video

All of the sources and destinations are in place, but there isn’t any routing.  This is also a good place to rename the device.  I’ve gotten into using really goofy names so that I don’t confuse myself when picking this device out of a list.

Step 4: Link to QJackCtl – Click here for video

Start QJackCtl at this point and make sure that it works as an interface.  QJackCtl has two buttons that can be used to select the interface — use the rightmost one, with the carrot that looks like this “>”

People who are already using Loopback and have a lot of devices may have to turn all but the new one off momentarily so that QJackCtl can find this one.  Those other devices can be turned back on once this one is selected and saved as a QJackCtl preset.

Step 5: Route incoming Jacktrip audio – Click here for video

Start by launching a Jacktrip connection and routing the incoming Jacktrip audio (just to the interface at first, more apps in later examples).

Step 6: Route local audio out to Jacktrip – Click here for video

The finished device – No video

This is the destination.  A device that can route 2 channels of Jacktrip in and out.

Variation 1: Capturing audio in a DAW (Logic Pro) – Click here for video

The quirk of Logic is that it sets audio preferences in two places.  The one that causes trouble is the Sample Rate, which is set at the project level and is quite often different than the sample rate being used by Jacktrip.  Launching a mismatched project will crash the Jacktrip session, possibly for everybody.

Variation 2: Capturing audio in a DAW (Ableton Live) – Click here for video

All the audio settings are set globally in Live.  But be careful to launch Live and confirm settings before launching the Jacktrip session – Live may be configured wrong when it launches and take down Jacktrip

Variation 3: Capturing audio in a DAW (Max) – Click here for video

This is just another variation.

Variation 4: Capturing audio in a DAW (Garageband) – Click here for video

There is no mechanism to change the sampling rate in Garageband, but in doing this project I discovered (and demonstrate) that I could receive and record audio from a 48k Jacktrip session even though Garageband only runs at 44.1k.  Garageband will take down a 48k Jacktrip session that’s already running, so make sure to start Garageband first.

Variation 5: sending more than just one mic through an audio interface with more channels – Click here for video

This is a way to avoid having to “rewire” QJackCtl every time Jacktrip has to be restarted.  This device is a preset for a multichannel mix coming from an interface with more than 2 output channels.   Pay close attention to redoing the default routing that Loopback will make when the interface is added to the device.

Variation 6: sending audio to Jacktrip from an app (e. g., Max) through the Pass-Thru channels – Click here for video

There are two ways to get audio from an app into the Jacktrip feed.  This is one — selecting the Loopback device as the audio output device in the app and taking care to route the audio out of the app on channels that aren’t the Dreaded Channels 1-2.

Variation 7: sending Jacktrip audio to Zoom – Click here for video

This is one way to get all the channels of the Loopback device into Zoom.  This will mix all the output channels, without the ability to balance the mix between local and Jacktrip audio.  So make sure to rehearse that balance.

Variation 8: sending audio to Jacktrip from an app (e. g., Logic) through a Loopback app-source – Click here for video

This is the other way to route audio from an app to Jacktrip — by leaving the audio settings at their defaults in the app and “spying” in the output with Loopback.  This might be preferable for a studio that already has complex routing that would be difficult to disturb.

Variation 9: use QJackCtl as an app-source rather than through the Pass-Thru interface – Click here for video

This one has been hit and miss for me, but it’s an option to explore….  carefully.  QJackCtl is an app that Loopback can see, and “spy” on, just like any other app that uses system audio on the Mac.

Here’s a picture of the whole setup (click on the photos to embiggen).

Here’s the recipe:

• The core — an LMScope Macroscope (specifically, this one )
• A Nikon Z7 camera (big sensor, lots of pixels – set on no-mirror, silent mode to reduce vibration — the decision was greatly aided by LMScope’s camera review page and camera ranking page)
• Nikon Camera Control Pro 2 software (to capture photos and put the live image on the screen)
• Nikon MC-DC2 shutter release (to reduce vibrations and make it easier to take lots of shots for focus stacking)
• A gaggle of cheap, really-bright Gearlight flashlights mounted on a couple of goose neck stands (using these adapters to fit the second gooseneck to the second mic-holder)
• Helicon Focus focus-stacking software (much easier/faster than Adobe Photoshop’s focus-stacking and integrates well with the Stackshot focus-stacking rail if we decide to go there)

Here’s Marcie’s Microscope Photos page, and here’s an early example of what she’s capturing.

Focus-stacking

This setup requires the use of focus-stacking.  Full stop.  I’m not qualified to explain why it’s so hard to “just take a picture through a microscope and have it all in focus” — and haven’t found a good article to link to yet.

Marcie’s pictures usually have between 10 and 20 photos to bring each part of the subject into focus.  That’s a bit on the skimpy end, most recommendations tend toward 30-50, but Marcie’s found that range works for what she’s doing

The LMScope folks strongly encourages the addition of a StackShot rail to automate the process of stepping through shooting the photos in the stack.  That especially makes sense when dealing with 50-photo stack.  I was pretty sold on that idea (and have the LMScope adapter), but Marcie has found that she doesn’t really need it yet, especially now that we’ve added our super-fancy custom labels to the focus-knob on the LMScope.  Here’s a picture — I made them with my handy Dymo label maker (that’s a lot of lower-case “L’s” in a row).

Lights

Wow!  Microscope lighting.  Now there’s a place where a person can spend a LOT of money.  I was way down that rabbit hole when we came up with the idea of using the four high-intensity LED flashlights you see in the photo at the top.   Those flashlights are adjustable — Marcie has them all set on the narrowest-beam highest-intensity setting.  I’m really proud of my duct-tape AND rubber-band solution to an ill-fitting mic-holder.  We had to buy a few more sets of rechargeable batteries for them.

Marcie is also very keen on the LED ring light that is included in the LMScope kit.  It’s great for softening the shadows from the side-fired flashlights.

“Big Data”

This process throws off a lot of really big pictures in a hurry.  Marcie compared JPG and RAW format photos and concluded that the difference was so small that it wasn’t worth using RAW.  But even so, each finished picture can consume 400 mBytes of disk space (figuring a stack of twenty pictures at 20 mBytes each).  Having a 4-disk RAID-0 SSD array helps sling all that data around.

Focus stacking also benefits from a fast computer.  Marcie has an 18-core iMac Pro with 128GB of RAM and ALL of those cores are going flat out when it’s crunching through a stack — it takes it about 30 seconds.

“Big Money”

If you’ve been tallying, you’ve realized that this project could easily consume $10,000-$15,000.  I have tried to do this for less and found that the results were really bad.  Here are some things that caused me trouble.

I tried and tried to find a gizmo that could shoot pictures through Marcie’s trinocular scope.  I think some of the results were actually better than we thought at the time.  But we didn’t realize that we HAD to do focus-stacking and we also didn’t realize that we didn’t have nearly enough light on our subject.  If you’ve already got a rig that you don’t like, try blasting away with those flashlights and focus-stacking the pictures.

If you’re just getting going, here’s a good blog post about using bellows on an SLR.  I wish I’d found this one long ago.   His formula would benefit from more lights, and a sturdier mount.  But it would be much more approachable than just diving into this rig.

happy 45th!

many thanks for the invitation to throw a few words into the virtual gathering.  here’s a collection of WORT memory-jogger photos, starting off with a few pages from early program guides, that tell a lot of the story of the early days.  clicking on the newsletter-page photos brings up bigger versions.

. . . .

here’s Numero Uno – volume 1 number 1.  my writing style in those days was a completely-hopeless attempt, by an illiterate geek,  to emulate my hero Lorenzo Milam.  Milam was guiding light for a gaggle of us who started stations all over the country — we lost him this year (2020), along with so many others.

a pretty good exposition about why most of us did all that work – it was fun, we made lots of good friends and we kinda took care of each other.  Jeff Lange did a lot of the graphics for the first-generation newsletters including everything on this page (i think).

. . . .

this next one is the one that you can hold in your head when you wonder what it felt like when we actually finally made it on the air.  sooo many people worked sooo hard to get to that point.  i hope WORT is always a focal point for this much effort and fun and friendship.  i love Jeff Lange’s piece about consensus decision-making down there below the fold.

. . . .

we used those early editions of the newsletter to lay out our thoughts about how we hoped things would go.  here’s Don Alan laying out the early view of programming — Don focused on the news and public-affairs programming while Jerry Zeiger championed the music programming.  who knew that record companies would give you records if you said you were an imaginary radio station!

. . . .

Jeff Lange describing the lucky-accident journey to the initial studio on Willie street…  along with the 3425th teaser for going on the air.

. . . .

John Ohliger got his start at Pacifica, which was an earlier and parallel path toward community radio.  rest easy, friend.  here we are describing the two precedents we knew – John grew up in the Pacifica stations, i bubbled away about the KRAB Nebula.

see further down for some pictures of the NARK (National Alternative Radio Konvention) which Lorenzo inspired, Bill Thomas organized and we hosted.  that was the first time that people from all the parallel threads actually met each other face-to-face.

. . . .

the first Program Guide!!  i love looking through this as a way to remember people and programs.  a pretty darn nifty thing — and the culmination of a LOT of work by a LOT of people.

. . . .

having no good sense, i “volunteered” the WORT volunteers to host the NARK (National Alternative Radio Konvention) while we were waiting around for the construction-permit to get approved by the FCC.   here’s the beginning of the call to arms that Lorenzo wrote to call us together.  i read the whole thing out loud the day i found out that he’d died because it perfectly captured his vision for community radio.  you can listen to that recording here.

. . . .

here are a few pictures.  supurb organizer that i am, i’d forgotten about a few things.  like… housing?  food?  chairs for people to sit on at Freedom House?  heck, it turned out OK anyway — because we were sooo desparate to TALK to each other.

here’s the main scene, all spread out in little groups at Freedom House on Willie Street.  today we’d call these “breakout groups” i guess.

. . . .

this was a session i missed – i think i was working on food…  people look cranky and hungry.  Lorenzo is standing in the right side of the doorway (the tall fella).

. . . .

here are people-photos from my scrapbook.   here’s Vinnie Curren, who became Chief Engineer some time after i left, in his native lair.

Joannie Rubel – at the core from the start – did program-director stuff for a while and became station manager when i left – this was also probably taken in 1980 or so

. . . . .

a nice shot of the original mixing board, record library and interview desk just peeking up above the tray for announcements and PSAs.  that’s pretty close to the original configuration and right where i sat when i lied my ass off to Pat Ryan about how much distortion the transmitter was producing when we did the certification-tests for the FCC.

. . . .

turning around, here’s the original pile of equipment.  this is the stuff that all failed, one piece of gear after the other, on that first night.  i wondered for years where my old Teac tape recorder had gotten off to.  there it is, peeking out from the back row on the right.

. . . .

that’s the story of the station going on the air.  i stuck around for another couple years and eventually wandered off to other things.  i’ve since discovered that i like starting things up, but don’t do particularly well at keeping them going.  WORT was fortunate in that i left before causing too much damage.

i still have the Resolution of Thanks from the City Council…

. . . .

here’s the wonderful farewell sheet-cake — best sheet-cake graphic ever!

. . . .

here are John Ohliger and me hamming it up — John organized all this farewell foolishness that meant (and means) so much to me.

. . . .

here are the folks who carried WORT on to the next stage.  see those wooden letters on the wall?  one of Jeff Lange’s many creative contributions — those letters spelled WMFM when he started out.  a day or two later, after some pretty darn creative work with a Skil saw, the letters returned to that wall…  transmogrified.

that concludes my report.

Starting the server in Hub Mode (capital-S instead of lower-case S) with the “-p” option offers four ways to configure the server.  Here’s an example launch string that would fire up a server in Mode 2:

jacktrip -S -p2

Mode – 0 (the default – my machine hears everybody and everybody hears the mix that I send them)

Mode – 1 (loopback – everybody hears themselves but nobody else)

Mode – 2 (everybody hears each other, but not themselves)

Mode – 3 (reserved for some whacky stuff with Supercollider and auto-generated internal IP addresses — looks OK in the routing, but scroll down check out what shows up in the terminal)

Here’s the whacked stuff that shows up in the terminal…

Mode – 4 (everybody hears each other and themselves)

Here’s a video and a recipe for musicians who want to display something other than a web-cam of themselves when performing in an ensemble.  Maybe graphics, or animation.  Especially interesting is to insert a Syphon stream into the mix.   Here’s one way to do that.  Sorry — I only cover Mac software here.

Part 1 — Get OBS into Zoom

Here are the ingredients:

• • • OBS (Open Broadcaster Software)
    • OBS Mac Virtualcam
    • Zoom

Steps:

• • • Configure OBS Mac Virtualcam inside of OBS.
    • Launch OBS and enable Tools/Start Virtual Web Cam
    • Launch Zoom and select the “OBS MAC Virtualcam” source that is now available in Zoom video preferences

If you have a Syphon source that you would like to include in an OBS scene, do that in OBS by creating a “Syphon Client” Source.  Continue to Part 2 if you want to send the Syphon client directly to Zoom.

Part 2 — Get EboSuite’s eSyphonOut plugin into Zoom

Additional ingredients (presumes Part 1 is installed successfully):

• • • Syphon Virtual Webcam
    • Ableton Live
    • EboSuite

Steps:

• • • Configure Syphon Virtual Webcam
    • Add Ebosuite’s eSyphonOut plugin to an Ableton project
    • Start playing the Ableton project (in order to generate EboSuite video)
    • Launch Syphon Virtual Webcam
    • Launch Zoom and select the “OBS Virtualcam” source in Zoom video preferences