The Problem with Camelot Numbers

Up until now, I’ve been using the Camelot Wheel system to categorize my music. If you’re a DJ, you know the drill: 1A, 2A, 3B, etc. It’s a great way to handle harmonic mixing, and it felt like a logical way to group tracks that should play together.

However, as my game world expanded, this system started to feel… restrictive. I only had a few Camelot numbers in active use, and whenever I wanted to add a new “vibe” or “biome” to the game, I found myself mentally mapping abstract numbers to actual musical themes. It wasn’t sustainable. I didn’t want to remember that 2A was my “Berlin School” theme; I wanted it to just be called Berlin.

The Solution: Theme-Based Mapping

I’ve officially ditched the Camelot numbers in favor of Theme Names.

Instead of a folder named 1A, I now have folders named Ambient-001, Berlin-Industrial, or Deep-Space-Drone. This might seem like a small semantic change, but it has completely opened up the workflow.

Why this is better:

1. Unlimited Scalability: I’m no longer bound by a fixed wheel of codes. I can create as many themes as I want, with descriptive names that actually mean something to me as a composer.
2. Instant Integration: My mapping is now handled directly by the filesystem. If I want a new theme in the game, I just create a folder with that name in my Assets/Music/Themes/ directory.
3. Creative Freedom: It allows me to group related tracks much more intuitively. I can have Ambient-Day and Ambient-Night without trying to find “empty” Camelot slots for them.

The Bitwig Studio to Godot Pipeline

The real magic of this transition is how it interacts with my DAW. Using Bitwig Studio, I can now create a set of related stems (Drone, Pads, Textures, Melodic) and export them as .ogg files directly into these theme folders.

Because my MusicManager in Godot is set up to scan these folders and automatically categorize tracks based on their filenames (using a simple 0-3 numbering convention for stem types), the transition from “Finished Loop” in Bitwig to “Interactive Music” in Godot takes seconds.

Final Thoughts

Refactoring a core system can be scary, but it’s almost always worth it when it removes friction from your creative process. By moving from Camelot Numbers to Theme Names, I’ve traded a rigid technical constraint for a flexible, human-readable system that lets me focus on what matters most: making the game sound great.

Stay tuned for more updates on the development of Fifty Things!

The post From Codes to Creativity: Why I Refactored My Generative Music System first appeared on cerkit.com.

What is the Camelot System?

The Camelot Wheel is a tool used by DJs to mix tracks harmonically. Every musical key is assigned a number and a letter (e.g., 8A for A minor, 9A for E minor). By matching these numbers, you ensure that multiple audio stems will always sound harmonious when played together.

In our game, we use this to drive a “Generative” engine.

Why Generative Music?

Standard game music can become repetitive. By breaking a song down into four distinct “stems,” we can mix and match variations in real-time:

1. SubDrone: The foundational low-end.
2. MainPads: The harmonic atmosphere.
3. Textures: Environmental noise and field recordings.
4. Melodic: Leads, arpeggios, and high-frequency flair.

By having, for example, 3 different pad variations and 5 different lead variations for a single key, the game can generate 15 different versions of the same song!

Technical Implementation in Godot

We built this system using Godot Mono (C#) with a focus on performance and flexibility.

1. The Centralized JSON Catalog

We moved away from embedding metadata in WAV files. Instead, we use a single track_catalog.json. This file acts as the “brain” of the system, telling the game which files belong to which Camelot key and stem type.

{
  "tracks": [
    {
      "FileName": "abyss_2A.ogg",
      "TrackName": "Abyssal Pad",
      "CamelotNumber": "2A",
      "StemType": 0
    }
  ]
}

2. The MusicManager (Singleton)

The MusicManager is a global autoload that handles the heavy lifting. It parses the JSON, caches the audio files to prevent frame-stutter, and—most importantly—triggers all four stems at the exact same micro-second to ensure perfect synchronization.

We also added support for multiple formats like OGG Vorbis, which drastically reduces our memory footprint (from 30MB WAVs down to 3MB OGGs!) while maintaining high quality and gapless loops.

3. The Trigger System

To bring the music into the world, we created a GenerativeMusicTrigger scene. It’s a simple collision area that developers can drop anywhere in a level. When the player walks into the trigger, it tells the MusicManager to “Play 2A,” and the engine instantly builds a harmonious mix from the available catalog.

Summary

This pivot to a JSON-driven Camelot system gives us:

• Infinite Variety: No two playthroughs sound exactly the same.
• Harmonic Consistency: The music always sounds “right” because it follows music theory rules.
• Efficiency: Smaller file sizes and smart caching mean better performance on all hardware.

Stay tuned for more updates as we continue to expand the soundscape of 50 Things!

The post Dynamic Generative Music: Bringing the Camelot Wheel to Godot first appeared on cerkit.com.

I have owned the physical version of Star Wars: Outer Rim for a while now, and it perfectly captures that gritty, scoundrel lifestyle. The gameplay loop of upgrading your ship, hiring crew members like Chewbacca or Hondo Ohnaka, and taking risky jobs is incredibly fun. It’s exactly the kind of thematic experience I want from a Star Wars board game.

However, there is a giant, logic-defying asteroid in the way: the setup.

The Barrier to Entry: The Infamous “Tabletop Shrapnel”

I truly love the game, but I never, ever look forward to the setup prior to playing. Outer Rim has a massive table presence. The galaxy map is made of individual crescent-shaped pieces that need to be aligned. There are numerous market decks that all require shuffling—cargo, mods, luxury goods, jobs, bounties, ships. On top of that, you have hundreds of tiny tokens for damage, credits, contacts, and reputation. It takes me a solid 20 minutes to set up, and I always feel a little overwhelmed before my first turn.

And don’t even get me started on the take-down. Sweeping those hundreds of tiny components back into their tiny plastic baggies while my friends are already asking about what we’re going to eat is the ultimate anti-climax. This setup and teardown fatigue has, more than once, caused us to choose a simpler, “cleaner” game instead.

That is exactly why the digital version on Tabletop Simulator on my Mac has been an absolute revelation. Star Wars Outer Rim Tabletop Simulator is a fun way to play.

Making it Virtual: Getting Started on your Mac

Tabletop Simulator (TTS) isn’t a standalone game; it’s a physics toolbox that lets you play board games digitally. If you are a Mac user, this is the most effective way to play Outer Rim. Here is how you can get it up and running:

The first step is getting Tabletop Simulator itself. You will need to have the Steam client installed on your Mac. If you don’t already have Steam, visit store.steampowered.com and download it. Once Steam is running, search for “Tabletop Simulator.” It frequently goes on sale during Steam’s seasonal events. Purchase the game and Steam will immediately download and install it into your library.

Installing “Star Wars: Outer Rim” into TTS

This is where the magic of the community happens. Once Tabletop Simulator is installed, you need to find the specific community mod for Star Wars: Outer Rim. While on the Tabletop Simulator page in your Steam Library, look for the “Workshop” tab located just below the “Play” button. Click it to open the library of user-created mods. In the main Workshop search bar, type “Star Wars Outer Rim”. You will see several versions. I highly recommend looking for a version marked “scripted”—these are the ones created by amazing community coders that handle the tedious bits for you. When you find a highly rated version that looks good, simply click on the thumbnail to visit its page, and then click the large green “+ Subscribe” button. Steam will immediately begin downloading that mod’s assets into your TTS game file.

Hyperspace in a Single Click

Once subscribed, launch Tabletop Simulator. Click on “Create” (or “Join” for multiplayer), select your game type (Singleplayer works great for learning), and then click on the Workshop tab. You will see a thumbnail of the Star Wars: Outer Rim mod you just subscribed to. Click it, and the game will begin to load.

Because I use a highly scripted mod, the annoying setup and take-down that I dreaded are completely gone. The mod randomizes the contact tokens, shuffles every market deck, and builds the intricate galaxy map on its own. In the base game, I might dread shuffling that Databank deck, but in TTS, I just right-click and search. This digital setup removes all the friction, allowing me to dive straight into the fun of upgrading my YT-1300 and navigating the dangerous criminal underworld of the Outer Rim.

The post Star Wars: Outer Rim on Mac – Tabletop Simulator Guide first appeared on cerkit.com.

A Look Behind the Scenes

Preparations are in full swing. Today, O.Z. Hall, Jr. and I got together for an intensive practice session to dial in our sound and transition through the set. There’s something special about the energy that builds when the synthesizers start humming and the sequences begin to lock in.

While we were deep in the gear, I decided to capture the moment—but with a bit of a twist.

Enter the “Crow-Headed Aliens”

I’ve been experimenting with 360-degree photography to capture the vibe of our practice space. However, a standard view of cables and knobs felt a bit too “human.” To spice things up, I’ve digitally altered the images to reflect the otherworldly nature of the music we’re creating.

In this immersive view, you’ll find two crow-headed aliens at the helm of the synthesizers, navigating through a landscape of electronic sound.

Experience the 360 view here:  Caldera Dreams – 360 Practice Space

(Note: If you’re on mobile, you can move your phone around to look around the room; on a desktop, just click and drag! Access it from a VR headset to be completely immersed!)

Join Us in Birmingham at the Magic City Art Connection

We are hard at work making sure this performance is a unique sonic experience. If you’re in the Birmingham area during the festival, I’d love to see you there.

Stay tuned for more updates as we get closer to the event. Check out the official Magic City Art Connection website for the full schedule and ticket info (the 2026 performance schedule should be released around the first of April).

The post Aliens in the Studio: Prepping for Magic City Art Connection first appeared on cerkit.com.

I recently built a hardware-based MIDI “Man-in-the-Middle” (MITM) device that does exactly this: it inverts MIDI notes in real-time, allowing you to play any standard MIDI controller as a “Left-Handed” piano. In this post, I’ll break down how this project works, the technical details, and how you can build one yourself!

The Concept: Inverting the Keyboard

The theory behind a left-handed piano is to flip the keyboard layout around a central pivot point. For this project, I chose D4 (MIDI Note 62) as the pivot.

By applying a simple mathematical formula, we can invert the incoming notes:

Inverted Note = 124 - Original Note

With this formula:

• D4 (62) remains D4 (62)
• C4 (60) becomes E4 (64)
• A0 (21) becomes G8 (103)

This creates a perfect mirror image of the keyboard!

The Hardware: Arduino as a MIDI MITM

To achieve this without noticeable latency, I used an Arduino MEGA 2560 to sit horizontally between the MIDI controller and the sound module (or DAW). The MEGA is great for this because it features multiple hardware serial ports (Serial1, Serial2, etc.), allowing high-speed, reliable MIDI handling while still being able to output debug information over USB (Serial).

The flow looks like this:

1. MIDI IN: The controller sends Note On/Off messages to the Arduino’s Serial1.
2. Processing: The Arduino runs a robust state machine to parse the incoming MIDI bytes. It applies our inversion formula to note data while letting other messages (like Clock or CC) pass through untouched.
3. MIDI OUT: The modified MIDI data is sent out to the synthesizer via Serial2.

Overcoming Technical Hurdles

It might sound simple to just subtract the note number, but MIDI is a serial protocol with some quirks that make real-time processing tricky. Here are a few things the code has to handle gracefully:

1. Zero-Latency Parsing

The code uses a non-blocking state-machine-based parser to process MIDI bytes exactly as they arrive. This ensures there’s no perceptible processing delay when playing fast passages.

2. State Management for “Stuck Notes”

What happens if you press a key, the translation logic changes (e.g., a hardware bypass switch is flipped), and then you release the key? If we inverted the release message based on the current state rather than the state when the key was pressed, we might send a Note Off for the wrong key, resulting in the dreaded “stuck note.”

To solve this, the software maintains an internal array activeNotes[128] to track the exact inverted note that was triggered for every physical key. When a key is released, it looks up the specific note in the array to turn off.

3. MIDI Running Status

MIDI devices often use “Running Status” to save bandwidth. If multiple Note On messages are sent in a row, the status byte (0x90) is omitted for subsequent notes. The parser has to keep track of the last seen status byte to correctly interpret incoming data bytes.

Bill of Materials (BOM)

To build this project, you will need the following components:

• Arduino MEGA 2560: The core processor board providing ample hardware serial ports.
• MIDI Breakout Shield: A board with 5-pin DIN connectors and an optoisolator circuit.
• 4x Jumper Wires: For connecting the shield to the MEGA’s alternate hardware serial pins.
• USB Cable (A-to-B): To power the device and monitor the real-time serial output.
• 2x Standard MIDI Cables: For connecting your keyboard and your synthesizer/audio interface.

Wiring Diagram

Because we want to reserve the MEGA’s primary serial port (Pin 0/1) for PC debugging, we do not simply stack the MIDI shield on top. Instead, we use jumper wires to route the MIDI data to Serial1 (RX1) and Serial2 (TX2).

Note: The shield’s RX pin receives data from the MIDI IN optoisolator and connects to the Arduino’s RX1. The Arduino’s TX2 pin sends data to the shield’s TX pin to be transmitted via the MIDI OUT jack.

The Code

Here is a snippet showing the core logic of the full message handler, demonstrating how the note inversion, state management, and serial debugging are applied. This version leverages the robust hardware serial processing available on the Arduino MEGA 2560:

void handleFullMessage() {
  uint8_t status = midiMsg[0];
  uint8_t type = status & 0xF0;
  uint8_t channel = status & 0x0F;
  uint8_t data1 = midiMsg[1];
  uint8_t data2 = midiMsg[2];

  // Active Logic: Invert Note On/Off
  if (type == 0x90 || type == 0x80) {
    uint8_t originalNote = data1;
    uint8_t velocity = data2;

    // Inversion formula: 124 - original_note
    int invertedNote = INVERSION_OFFSET - (int)originalNote;
    if (invertedNote < 0)
      invertedNote = 0;
    if (invertedNote > 127)
      invertedNote = 127;

    if (type == 0x90 && velocity > 0) {
      // Note On
      activeNotes[originalNote] = (int8_t)invertedNote;
      Serial2.write(0x90 | channel);
      Serial2.write((uint8_t)invertedNote);
      Serial2.write(velocity);

      Serial.print("Note On: ");
      Serial.print(originalNote);
      Serial.print(" -> ");
      Serial.println(invertedNote);
    } else {
      // Note Off (type 0x80 or 0x90 with velocity 0)
      int8_t noteToSend = activeNotes[originalNote];
      if (noteToSend == -1) {
        // Failure case: received Note Off without Note On.
        // Just invert it and send anyway to be safe.
        noteToSend = (int8_t)invertedNote;
      }

      Serial2.write(type | channel);
      Serial2.write((uint8_t)noteToSend);
      Serial2.write(velocity);

      activeNotes[originalNote] = -1;

      Serial.print("Note Off: ");
      Serial.print(originalNote);
      Serial.print(" -> ");
      Serial.println((uint8_t)noteToSend);
    }
  } else {
    // Pass through CC and other multi-byte messages
    for (int i = 0; i < expectedBytes; i++) {
      Serial2.write(midiMsg[i]);
    }
  }
}

Conclusion

Building a custom hardware MIDI processor is deeply satisfying and opens up a ton of creative possibilities. By putting a simple Arduino between your keyboard and your synth, you can fundamentally alter how you interact with your instrument.

If you’re interested in giving this a try, grab an Arduino, a couple of MIDI jacks, and start flipping those notes! Happy playing!

The post Building a Left-Handed Piano MIDI “Man-in-the-Middle” Device first appeared on cerkit.com.

That’s why I developed the Left-Handed Keyboard Inversion VST. This MIDI effect plugin flips the script (and the scales) by mirroring the entire keyboard, allowing for a completely different ergonomic experience.

Check out a short video demonstrating the inverted keyboard.

The Theory: Mirroring Around the Axis of D

The concept is based on the inherent symmetry of the piano keyboard. If you look at the pattern of black and white keys, the note D sits exactly in the center of the two black keys. This makes it a perfect axis of symmetry.

The plugin works by applying a simple but powerful mathematical formula to every MIDI note you play:

Inverted MIDI Note = 124 - Original MIDI Note

By using 124 as the sum, the pivot point becomes D4 (MIDI note 62). When you play a D4, you get a D4. But as you move physically “up” the keyboard to the right, the pitches move “down” into the bass register.

How It Works in Practice

When the plugin is active, your physical relationship with the instrument is reversed:

• Left Hand (Physical Low End): Now plays the high-frequency melody notes.
• Right Hand (Physical High End): Now handles the low-frequency bass notes.

This isn’t just a gimmick; it’s an ergonomic shift. It places the most complex, dexterous part of the performance—the melody—firmly in the hands of the most dexterous part of the musician: the left hand.

Technical Implementation

The plugin is built using the JUCE framework and operates as a pure MIDI effect. It handles:

• Real-time Note Translation: Every Note On and Note Off message is intercepted and recalculated instantly.
• State Tracking: It intelligently tracks active notes to ensure that if you release a key, the correct inverted “Note Off” is sent, preventing hanging notes even if you toggle the bypass mid-performance.
• Zero Latency: Because it’s a simple mathematical transformation of MIDI data, it introduces no perceptible delay to your playing.

Why Invert?

For many left-handed pianists, this creates a fascinating new way to interact with virtual instruments. It allows you to leverage your natural hand-dominance in a way that the standard piano layout doesn’t easily permit. Whether you’re looking for a fresh creative spark or a more natural flow for your lead lines, the keyboard inversion provides a literal new perspective on your music.

The post Reimagining the Keys: The Left-Handed Keyboard Inversion VST first appeared on cerkit.com.

First, I check in with the Current Me. This step is about defining the immediate reality of the situation and asking myself what I genuinely want the outcome to be right now. The Current Me represents my immediate desires, constraints, capabilities, and emotions. It is important to acknowledge what I want in the present moment, but it is equally important not to let this be the only voice in the room. The present is often heavily influenced by fleeting feelings or the appeal of short-term convenience, which is why the other two perspectives are so vital.

Next, I consult the Past Me. This version of myself holds the library of my experiences, successes, and, most importantly, my mistakes. I ask the Past Me what he would do based on everything he has learned so far. This is the voice of hard-earned wisdom. Has he been in a similar situation before? How did it play out? I treat this perspective as my personal advisor. If the Past Me gives a warning based on a previous misstep, I make sure to listen closely. Ignoring the lessons of the past is a quick way to repeat them.

Finally, I project forward and consider the Future Me. I think about what this older version of myself would think about the decision that I’m trying to make today. This step is entirely about long-term consequences. If the Future Me would look back and be angry, stressed, or disappointed with the Past Me (what is currently the Current Me), I take special care to re-evaluate my options and make the right decision. The ultimate goal is to set the Future Me up for success and peace of mind, rather than leaving him to clean up a mess.

Ultimately, this framework is about balancing the desires of the present with the lessons of the past and the hopes for the future. It forces you to step outside of the immediate pressure of a dilemma and view your choices across the continuous timeline of your life. This strategy has served me incredibly well, and by checking in with the Three Me’s, I find that I have fewer regrets as the years speed by.

The post The Three Me’s – A Strategy for Making Good Decisions first appeared on cerkit.com.

But as our system matured, a new challenge emerged: State Persistence.

Our Node-RED flows were doing an excellent job of instantly spinning up dynamic, private MQTT channels (the νz in our Pi Calculus model) and feeding custom UI layouts to connected clients. However, this orchestration was entirely ephemeral. If Node-RED restarted, or if we needed to audit historical connection records, that session data was gone forever.

We needed a backend capable of durably recording every handshake and saving the exact layout payloads delivered to each device. To solve this, we added pi-functions: a .NET 10 Minimal API that acts as a serverless-style backend, writing session states directly to a PostgreSQL database.

Enter pi-functions and Minimal APIs

When clients connect and request a UI, Node-RED negotiates the private channel. We wanted to seamlessly map that negotiation into a database. Rather than building a bulky web application, .NET 10 Minimal APIs provided the perfect “serverless” development experience—lightweight, extremely fast, and highly focused.

We created a simple Program.cs that spins up an ASP.NET Core web application, registers Entity Framework Core for our data access layer, and exposes essential HTTP endpoints:

// Function 1: Node-RED calls this to save a handshake state
app.MapPost("/api/state", async (SessionState state, PiCalculusDbContext db) =>
{
    // 1. Check if this client already has a session in the DB
    var existingSession = await db.SessionStates
        .FirstOrDefaultAsync(s => s.ClientId == state.ClientId);

    if (existingSession is not null)
    {
        // 2. UPDATE: The client exists, just update their active properties
        existingSession.Status = state.Status;
        existingSession.ActiveChannel = state.ActiveChannel;
        existingSession.CurrentUiState = state.CurrentUiState;
        existingSession.LastUpdatedAt = DateTimeOffset.UtcNow;
    }
    else
    {
        // 3. INSERT: Brand new client
        db.SessionStates.Add(state);
    }

    // 4. Save changes
    await db.SaveChangesAsync();
    
    return Results.Ok(state);
});

This acts as a seamless webhook for Node-RED. During the MQTT handshake process, an HTTP Request node can silently POST the session details to http://pi-functions:8080/api/state.

The Magic of PostgreSQL’s JSONB

Our UI layouts and dynamic menus are JSON objects pushed from Node-RED down the MQTT pipe. Creating rigid relational database tables to represent the infinite possibilities of a dynamic UI would be tedious and fragile.

Instead, we utilized PostgreSQL 16. Postgres offers native support for the JSONB data type, which stores JSON data in a decomposed binary format. This makes it incredibly fast to process and query, without the overhead of parsing raw text on the fly.

By simply tagging our CurrentUiState string property using the Fluent API in Entity Framework Core, we mapped it directly to a native JSONB column:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);

    // Add an index to ClientId so your Node-RED lookups are blazing fast
    modelBuilder.Entity<SessionState>()
        .HasIndex(s => s.ClientId)
        .IsUnique();

    // Store the raw Node-RED UI payload natively.
    modelBuilder.Entity<SessionState>()
        .Property(b => b.CurrentUiState)
        .HasColumnType("jsonb");
}

Now, the entire pi-console or pi-wasm configuration schema is durably saved exactly as it was requested, ready to be analyzed or restored at a moment’s notice.

Orchestrating the Ecosystem with Podman

With a new API and a database to manage, our local developer environment grew from two containers to four. Here’s a sample of what that Podman Compose architecture looks like (with credentials replaced by placeholders):

  postgres:
    image: postgres:16
    container_name: postgres
    restart: unless-stopped
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=admin
      - POSTGRES_PASSWORD=<YOUR_STRONG_PASSWORD>
      - POSTGRES_DB=PiCalculusDb
    volumes:
      - postgres_data:/var/lib/postgresql/data

  pi-functions:
    build: 
      context: ../Development/pi-console
      dockerfile: pi-functions/Dockerfile
    container_name: pi-functions
    restart: unless-stopped
    ports:
      - "5001:8080"
    environment:
      - ConnectionStrings__DefaultConnection=Host=postgres;Database=PiCalculusDb;Username=admin;Password=<YOUR_STRONG_PASSWORD>
    depends_on:
      - postgres

Podman Compose easily links the pi-functions bridge directly to the Postgres host postgres:5432. It builds the container straight from our C# workspace using a multi-stage Dockerfile.

The Evolution of the Pi Calculus Ecosystem

What started as a fun terminal experiment using Spectre.Console has bloomed into a highly decoupled, real-time distributed application framework.

By treating our UI configurations as data that moves over dynamic channels (the Pi Calculus model), we completely abstracted the concept of a graphical layout away from the client application. Now, with the addition of pi-functions and PostgreSQL, that ephemeral real-time orchestration is given memory and historical context.

Whether we are connecting through an SSH terminal in pi-console, or booting up the WebAssembly clone in pi-wasm, our central backend immediately authenticates the client, provisions a secure dynamic channel, saves the current UI layout state in Postgres via our minimal API, and paints the screen with the exact commands needed.

The ecosystem is robust, secure, and fully stateful. Next time, we’ll dive into building out custom sensor modules and watching the telemetry flow back upstream!

The post Building a Dynamic Console UI with .NET 10, MQTT, and Node-RED – Part 7: Persisting the Pi Calculus Session State with a Minimal API and PostgreSQL first appeared on cerkit.com.

But as our Pi Calculus ecosystem grew, we realized a critical flaw: Our MQTT connections were entirely unauthenticated.

Anyone with a basic MQTT client could theoretically connect to our broker, intercept the dynamic Handshake topics, or inject unauthorized layout JSON into our applications. It was time to lock down our Node-RED backend and secure our .NET clients.

Mosquitto Password Protection

The first step was securing our Mosquitto MQTT broker. By default, Mosquitto allows anonymous connections. We updated our mosquitto.conf file to disable anonymous mode and point to a generated password file:

# Global Authentication Settings
allow_anonymous false
password_file /mosquitto/config/passwd

Next, we used the mosquitto_passwd utility to generate a secure user (pi_user) and a corresponding encrypted password hash. A quick restart of the Docker container, and our broker was officially sealed.

Of course, the immediate side-effect was that our poor pi-console and pi-wasm clients started throwing NotAuthorized exceptions! The brokers wouldn’t let them in to perform their Pi Calculus orchestration. We needed to teach our shared .NET 10 library how to handle credentials.

Teaching Pi.Shared to Authenticate

Inside our Pi.Shared library, we updated our central orchestration engine, the MqttService. We added new Username and Password properties to the class, and updated our runtime connection block to append .WithCredentials() to the MqttClientOptionsBuilder:

if (!string.IsNullOrEmpty(Username) && !string.IsNullOrEmpty(Password))
{
    mqttClientOptionsBuilder = mqttClientOptionsBuilder.WithCredentials(Username, Password);
}

Now, the service was capable of authenticating. But where would it get those credentials? Hardcoding passwords directly into our Program.cs files or the shared library is a monumental security anti-pattern, especially since we track this project in a public GitHub repository.

We needed a strategy to load settings at runtime without ever letting Git see them. Because our clients run in two entirely different environments (a local terminal vs. a browser sandbox), we had to implement two distinct credential delivery mechanisms.

Securing the Terminal: secrets.json

For the native macOS terminal application (pi-console), we have full access to the local machine’s file system. We opted for a secrets.json file.

We created a .secrets folder at the root of our local workspace and added a secrets.json file containing our credentials:

{
  "MqttIpAddress": "localhost",
  "MqttPort": 9001,
  "Username": "pi_user",
  "Password": "super_secret_password"
}

Since the secrets.json file sits at the root of the solution, but the dotnet run execution happens deep inside the bin/Debug/net10.0/ folder, our MqttService needed to be smart enough to find it. We implemented a directory traversal loop to search upwards from the AppContext.BaseDirectory until it located the .secrets directory. Once found, it parses the JSON and populates the Username and Password fields.

Most importantly, we added .secrets/ to our .gitignore file, ensuring our Mosquitto passwords never accidentally get pushed to GitHub.

Securing the Browser: appsettings.json

Our Blazor WebAssembly client (pi-wasm) presented a completely different challenge. Since it runs inside the strict sandbox of your web browser, it has absolutely zero access to your local machine’s file system. It can’t directory-traverse its way to secrets.json.

Instead, Blazor WASM applications rely on configuration files served by the hosting web server. For pi-wasm, we created an appsettings.json file directly inside the wwwroot folder—the static web directory that gets bundled and sent to the browser:

{
    "Mqtt": {
    "Username": "pi_user",
    "Password": "super_secret_password"
    }
}

In pi-wasm/Program.cs, we tell our Dependency Injection container to pull the credentials directly from Blazor’s configuration builder:

service.Username = builder.Configuration["Mqtt:Username"];
service.Password = builder.Configuration["Mqtt:Password"];

When the user launches the website, the browser downloads appsettings.json, parses out the MQTT variables, injects them into the MqttService, and establishes an authenticated WebSocket connection.

Just like with the console app, we immediately added pi-wasm/wwwroot/appsettings.json to our .gitignore to protect the file from entering source control.

Connected and Secured

With both clients updated, our Pi Calculus orchestration system is fully authenticated. Node-RED requires a password to serve handshakes, and our .NET 10 UI clients dynamically inject their credentials based on their execution environment.

Whether you’re hitting the Qubit BBS from your local terminal or browsing it over WebSockets, the dynamic UI remains snappy, responsive, and—finally—secure.

Stay tuned as we continue expanding our MQTT UI orchestrator. You can follow along by cloning the pi-console Repo on GitHub!

The post Building a Dynamic Console UI with .NET 10, MQTT, and Node-RED – Part 6: Securing the Pi Calculus Ecosystem with MQTT Authentication first appeared on cerkit.com.

But what if we aren’t at our terminal? What if we want that exact same “Qubit BBS” dashboard experience—dynamically orchestrated via Pi Calculus—but available in a web browser from anywhere?

In this fifth installment, we evolved our single-client console application into a versatile multi-client ecosystem. We decoupled our core logic into a reusable Pi.Shared library, launched a brand-new .NET 10 Blazor WebAssembly client (pi-wasm), and implemented “Targeted Handshakes” to route custom UI configs to multiple active clients simultaneously.

The Pi.Shared Core Library

To support multiple UI frontends without duplicating our complex orchestration and MQTT logic, the first step was a major architectural refactor.

We created a new .NET 10 Class Library called Pi.Shared. Into this library, we migrated:

• The core data Models (MenuItem, UiConfigData, etc.)
• The MqttService responsible for backend communication
• The DynamicUiOrchestratorService responsible for handling the Pi Calculus handshakes and session states

To decouple the orchestrator from Spectre.Console directly, we introduced an 

IUiService interface containing abstractions like UpdatePanel and UpdateMenu. Now, our backend logic simply calls _uiService.UpdatePanel(), completely agnostic to whether those pixels are rendering in a native terminal or a web browser.

Enter pi-wasm: The Blazor WebAssembly Client

With our core engine safely abstracted, we generated a new .NET 10 Blazor WebAssembly standalone project: pi-wasm.

Implementing the new client was incredibly straightforward. We simply added a project reference to Pi.Shared and implemented 

IUiService inside a new BlazorUiService class.

Instead of writing out CLI blocks, the Blazor UI binds strongly-typed component state directly to CSS Grid elements, maintaining the exact visual layout of our original “Qubit BBS” mockup (Header, Operations Menu, Output, and Status panels).

Translating Spectre.Console to HTML

One unique challenge: Our Node-RED responses and orchestrator states were heavily utilizing Spectre.Console markup tags like [green]ONLINE[/] to inject colors into the text stream.

To keep the backend blissfully unaware of the frontend rendering engine, we built a lightweight regex-based 

SpectreConsoleParser in the WASM app. It seamlessly intercepts incoming Spectre tags and translates them into HTML <span> elements with inline CSS coloring. The parsed string is then injected into the UI via Blazor’s MarkupString, giving our browser UI the exact same color profiles as the CLI.

Bypassing TCP Ghosts with WebSockets

During testing, we encountered the “Tale of Two Brokers”. Our browser-based pi-wasm client securely connected to the Docker Mosquitto instance via WebSockets (localhost:9001) and instantly fetched the default menus. However, our native Mac pi-console application was randomly dropping packets over the standard TCP port (1883).

It turned out the host OS had a standalone TCP broker intercepting traffic, preventing packets from crossing the Docker network bridge!

The solution? We standardized both clients to connect explicitly over MQTT via WebSockets to bypass the native network conflicts.

Targeted Handshakes

With both pi-console AND pi-wasm successfully connected to the same Node-RED backend simultaneously, we faced our final Pi Calculus challenge: How do we send a different UI configuration to the Console app vs the Browser app?

We achieved this by implementing Targeted Handshakes.

1. During MqttService initialization in Program.cs, each client is statically assigned a unique ClientId (e.g., "pi-console" or "pi-wasm").
2. When announcing their presence on startup (pi-console/client/startup), clients now include their ID in the JSON payload: {"clientId": "pi-console"}.
3. Node-RED parses this ID and dynamically routes the ensuing Pi Calculus handshake to a specific targeted listener: pi-console/handshake/{clientId}.
4. Node-RED then looks up the clientId against a dictionary in pi-console-configs.json and pushes the tailored UI layout parameters and menu options down the secure session channel.

Thanks to this targeted routing, our Node-RED backend can serve entirely different, customized dashboards to different clients—all utilizing the exact same shared .NET 10 orchestration engine!

Stay tuned as we continue to push the limits of dynamic MQTT UI orchestration!

Clone the pi-console Repo on GitHub and develop your own UI orchestrations (Node-RED flows in the Architecture file in the repo)

The post Building a Dynamic Console UI with .NET 10, MQTT, and Node-RED – Part 5: Blazor WebAssembly, Shared Libraries, and Targeted Handshakes first appeared on cerkit.com.