Monthly Archives: October 2025

Empowering the user

Posted on by

Empowering the User: The Boeing vs. Airbus Philosophy in Software and Control System Design

In the world of aviation, the stark philosophical differences between Boeing and Airbus control systems offer a profound case study for user experience (UX) design in software and control systems. It’s a debate between tools that empower the user with ultimate control and intelligent assistance versus those that abstract away complexity and enforce protective boundaries. This fundamental tension – enabling vs. doing – is critical for any designer aiming to create intuitive, effective, and ultimately trusted systems.

The Core Dichotomy: Enablement vs. Automation

At the heart of the aviation analogy is the distinction between systems designed to enable a highly skilled user to perform their task with enhanced precision and safety, and systems designed to automate tasks, protecting the user from potential errors even if it means ceding some control.

Airbus: The “Doing It For You” Approach

Imagine a powerful, intelligent assistant that anticipates your needs and proactively prevents you from making mistakes. This is the essence of the Airbus philosophy, particularly in its “Normal Law” flight controls.

The Experience: The pilot provides high-level commands via a side-stick, and the computer translates these into safe, optimized control surface movements, continuously auto-trimming the aircraft.

The UX Takeaway:

Pros: Reduces workload, enforces safety limits, creates a consistent and predictable experience across the fleet, and can be highly efficient in routine operations. For novice users or high-stress environments, this can significantly lower the barrier to entry and reduce the cognitive load.

Cons: Can lead to a feeling of disconnect from the underlying mechanics. When something unexpected happens, the user might struggle to understand why the system is behaving a certain way or how to override its protective actions. The “unlinked” side-sticks can also create ambiguity in multi-user scenarios.

Software Analogy: Think of an advanced AI writing assistant that not only corrects grammar but also rewrites sentences for clarity, ensures brand voice consistency, and prevents you from using problematic phrases – even if you intended to use them for a specific effect. It’s safe, but less expressive. Or a “smart home” system that overrides your thermostat settings based on learned patterns, even when you want something different.

Boeing: The “Enabling You to Do It” Approach

Now, consider a sophisticated set of tools that amplify your skills, provide real-time feedback, and error-check your inputs, but always leave the final decision and physical control in your hands. This mirrors the Boeing philosophy.

The Experience: Pilots manipulate a traditional, linked yoke. While fly-by-wire technology filters and optimizes inputs, the system generally expects the pilot to manage trim and provides “soft limits” that can be overridden with sufficient force. The system assists, but the pilot remains the ultimate authority.

The UX Takeaway:

Pros: Fosters a sense of control and mastery, provides direct feedback through linked controls, allows for intuitive overrides in emergencies, and maintains the mental model of direct interaction. For expert users, this can lead to greater flexibility and a deeper understanding of the system’s behavior.

Cons: Can have a steeper learning curve, requires more active pilot management (e.g., trimming), and places a greater burden of responsibility on the user to stay within safe operating limits.

Software Analogy: This is like a professional photo editing suite where you have granular control over every aspect of an image. The software offers powerful filters and intelligent adjustments, but you’re always the one making the brush strokes, adjusting sliders, and approving changes. Or a sophisticated IDE (Integrated Development Environment) for a programmer: it offers powerful auto-completion, syntax highlighting, and debugging tools, but doesn’t write the code for you or prevent you from making a logical error, allowing you to innovate.

Designing for Trust: Error Checking Without Taking Over

The crucial design principle emerging from this comparison is the need for systems that provide robust error checking and intelligent assistance while preserving the user’s ultimate agency. The goal should be to create “smart tools,” not “autonomous overlords.”

Key Design Principles for Empowerment:

Transparency and Feedback: Users need to understand what the system is doing and why. Linked yokes provide immediate physical feedback. In software, this translates to clear status indicators, activity logs, and explanations for automated actions. If an AI suggests a change, explain its reasoning.

Soft Limits, Not Hard Gates: While safety is paramount, consider whether a protective measure should be an absolute barrier or a strong suggestion that can be bypassed in exceptional circumstances. Boeing’s “soft limits” allow pilots to exert authority when necessary. In software, this might mean warning messages instead of outright prevention, or giving the user an “override” option with appropriate warnings.

Configurability and Customization: Allow users to adjust the level of automation and assistance. Some users prefer more guidance, others more control. Provide options to switch between different “control laws” or modes that align with their skill level and current task.

Preserve Mental Models: Whenever possible, build upon existing mental models. Boeing’s yoke retains a traditional feel. In software, this means using familiar metaphors, consistent UI patterns, and avoiding overly abstract interfaces that require relearning fundamental interactions.

Enable, Don’t Replace: The most powerful tools don’t do the job for the user; they enable the user to do the job better, faster, and more safely. They act as extensions of the user’s capabilities, not substitutes.

The Future of UX: A Hybrid Approach

Ultimately, neither pure “Airbus” nor pure “Boeing” is universally superior. The ideal UX often lies in a hybrid approach, intelligently blending the strengths of both philosophies. For routine tasks, automation and protective limits are incredibly valuable. But when the unexpected happens, or when creativity and nuanced judgment are required, the system must gracefully step back and empower the human creator.

Designers must constantly ask: “Is this tool serving the user’s intent, or is it dictating it?” By prioritizing transparency, configurable assistance, and the user’s ultimate authority, we can build software and control systems that earn trust, foster mastery, and truly empower those who use them.

Immersive audio demonstration recordings

Posted on by

From Artist’s Intent to Technician’s Choice

In a world full of immersive buzzwords and increasingly complex production techniques, the recording artist’s original intentions can quickly become filtered through the lens of the technician’s execution.

I’ve been thinking about this a lot recently. I just acquired something that powerfully inspired my career in music—a piece of music heard the way it was truly intended before we fully grasped how to record and mix effectively in stereo. It was raw, immediate, and utterly captivating.

I feel we’re in a similar transition zone right now with immersive content production. We’re in the “stereo demo” phase of this new sonic dimension. We’re still learning the rules, and sometimes, the sheer capability of the technology overshadows the artistic purpose. The power of immersive sound shouldn’t just be about where we can place a sound, but where the story or the emotion demands it.

It brings me back to the core inspiration.

Putting the Mechanics into Quantum Mechanics

Posted on by

As we explore the frontier of quantum computing, we’re not just grappling with abstract concepts like superposition and entanglement—we’re engineering systems that manipulate light, matter, and energy at their most fundamental levels. In many ways, this feels like a return to analog principles, where computation is continuous rather than discrete.

A Return to Analog Thinking

Quantum systems inherently deal with waves—light waves, probability waves, electromagnetic waves. These are the same building blocks that analog computers once harnessed with remarkable efficiency. Analog systems excelled at handling infinite resolution calculations, where signals like video, sound, and RF were treated as continuous phenomena:

  • Video is light being redirected.
  • Sound is pressure waves propagating.
  • RF is electromagnetic waves traveling from point to point.

The challenge now is: how do we process continuously varying signals at the speed of light, without being bottlenecked by digital discretization?

Light as Information

I often joke that light moves at the speed of light—until it’s put on a network. But in the quantum realm, we’re literally dealing with light as both input and output. That changes the paradigm entirely.

To “put the mechanics into quantum mechanics” means:

  • Designing systems that physically embody quantum principles.
  • Treating light not just as a carrier of information, but as the information itself.
  • Building architectures that process analog signals at quantum scales, leveraging phase, amplitude, and polarization as computational resources.

Engineering Quantum Behavior

In this paradigm, we’re not just simulating quantum behavior—we’re engineering it. Quantum computing isn’t just about qubits flipping between 0 and 1; it’s about manipulating the very nature of reality to perform computation. This requires a deep understanding of both the physics and the engineering required to build systems that operate at the atomic and photonic level.

We’re entering an era where the boundaries between physics, computation, and communication blur. And perhaps, by revisiting the principles of analog computation through the lens of quantum mechanics, we’ll unlock new ways to process information—at the speed of light, and with the precision of nature itself.

The Most Powerful Computers You’ve Never Heard Of

 

Why “Red” and “Blue” Are Misleading in Network Architecture

Posted on by

In network design, naming conventions matter. They shape how engineers think about systems, how teams communicate, and how failures are diagnosed. Among the more popular—but problematic—naming schemes are “red” and “blue” architectures. While these color-coded labels may seem harmless or even intuitive, they often obscure the true nature of system behavior, especially in environments where redundancy is partial and control mechanisms are not fully mirrored.

“When you centralize the wrong thing, you concentrate the blast… Resiliency you don’t practice – is resiliency you don’t have” – David Plumber

The Illusion of Symmetry

The use of “red” and “blue” implies a kind of symmetrical duality—two systems operating in parallel, equally capable, equally active. This might be true in some high-availability setups, but in many real-world architectures, one side is clearly dominant. Whether due to bandwidth, control logic, or failover behavior, the systems are not truly equal. Calling them “red” and “blue” can mislead engineers into assuming a level of redundancy or balance that simply doesn’t exist.

Why “Main” and “Failover” Are Better

A more accurate and practical naming convention is “main” and “failover.” These terms reflect the intentional asymmetry in most network designs:

  • Main: The primary path or controller, responsible for normal operations.
  • Failover: A backup that activates only when the main system fails or becomes unreachable.

This terminology makes it clear that the system is not fully redundant—there is a preferred path, and a contingency path. It also helps clarify operational expectations, especially during troubleshooting or disaster recovery.

The Problem with “Primary” and “Secondary”

While “primary” and “secondary” are common alternatives, they carry their own baggage. These terms often imply that both systems are active and cooperating, which again may not reflect reality. In many architectures, the secondary system is passive, waiting to take over only in specific failure scenarios. Using “secondary” can lead to confusion about whether it’s actively participating in control or data flow.

Naming Should Reflect Behavior

Ultimately, naming conventions should reflect actual system behavior, not just abstract design goals. If one path is dominant and the other is a backup, call them main and failover. If both are active and load-balanced, then perhaps red/blue or A/B makes sense—but only with clear documentation.

Misleading names can lead to misconfigured systems, delayed recovery, and poor communication between teams. Precision in naming is not just pedantic—it’s operationally critical.

Alternative Terminology for Primary / Secondary Roles

  • Anchor / Satellite
  • Driver / Follower
  • Coordinator / Participant
  • Source / Relay
  • Lead / Support
  • Commander / Proxy
  • Origin / Echo
  • Core / Edge
  • Root / Branch
  • Beacon / Listener
  • Pilot / Wingman
  • Active / Passive
  • Initiator / Responder
  • Principal / Auxiliary
  • Mainline / Standby

The Case of the Conductive Cable Conundrum

Posted on by

I love interesting weird audio problems—the stranger the better! When a colleague reached out with a baffling issue of severe signal loading on their freshly built instrument cables, I knew it was right up my alley. It involved high-quality components behaving badly, and it was a great reminder that even experts can overlook a small but critical detail buried in the cable specifications.

The Mystery of the Missing Signal

My colleague was building cables using Mogami instrument cable (specifically 2319 and 2524) and Neutrik NP2X plugs, both industry-standard choices. The results were perplexing:

  • With Neutrik NP2X plugs: The signal was heavily compromised—a clear sign of signal loading—requiring a massive 15dB boost just to achieve a usable volume.

  • With generic ‘Switchcraft-style’ plugs: The cables functioned perfectly, with no signal loss.

The contradiction was the core of the mystery: Why would a premium connector fail where a generic one succeeded, all while using the same high-quality cable?

The Sub-Shield Suspect: A Deep Dive into Cable Design

The answer lay in the specialized design of the Mogami cable, particularly a feature intended to prevent noise. Most musical instrument pickups, like those in electric guitars, are high-impedance, voltage-driven circuits. This makes them highly susceptible to microphonic noise—the minute voltage generated when a cable is flexed or stepped on.

To combat this, the Mogami W2319 cable specification includes a specialized layer:

Layer Material Details
Sub-Shield Conductive PVC (Carbon PVC) Placed under the main shield to drain away this microphonic voltage.

This sub-shield is designed to be conductive.

The Termination Trap

My colleague’s standard, logical termination procedure was to strip the outer jacket and shield, then solder the hot wire to the tip connector with the inner dielectric butted right up against the solder post. This is where the problem originated.

I theorized that the internal geometry of the Neutrik NP2X plugs—which features a tightly-fitted cup and boot—was the culprit:

“It’s the way it sits in the cups. Sometimes it touches. Like when you put the boot on it goes into compression and jams it right up to the solder cup.”

 

When the cable was compressed by the tight Neutrik boot, the exposed, conductive sub-shield was being pushed into contact with the tip solder cup—creating a partial short circuit to ground (the shield). This resistive path to ground is the definition of signal loading, which robbed the high-impedance guitar circuit of its precious voltage and necessitated the hefty 15dB boost. The generic connectors, by chance, had just enough internal clearance to avoid this fatal contact.

The Professional Solution

The specifications confirm the necessity of a careful strip: Note: This conductive layer must be stripped back when wiring, or a partial short will result.

The fix was straightforward: cleanly peel or strip back the black, conductive PVC layer a small amount, ensuring it cannot make contact with the tip solder cup when the connector is fully assembled. This prevents the short and restores the cable’s proper functionality.

My colleague quickly confirmed the successful result:

“The issue was in fact the conductive PVC layer.”

“fuck yeah, nailed it!”

This experience serves as a powerful reminder that even seasoned professionals must respect the specific design and termination requirements of high-quality components. When troubleshooting audio problems, sometimes the most unusual solution is found not in a faulty part, but in a necessary step that was, literally, not in the wire.

Onset Vs Outset

Posted on by

Onset

Onset generally refers to the start of something negative, unwelcome, or intense, often an event that seems to happen suddenly or that you did not choose.

  • Meaning: The beginning or initial stage of something, especially something bad.
  • Connotation: Negative, unwelcome, or inevitable.
  • Typical Usage: Often used with diseases, weather, or negative conditions:
    • The onset of flu symptoms.
    • The onset of winter.
    • The onset of war.

 

Outset

Outset simply refers to the start or beginning of an activity, process, or endeavor and carries a neutral or positive connotation. It is often used to refer to a starting point of an undertaking or a journey.

  • Meaning: The beginning or start of a process, event, or period.
  • Connotation: Neutral, often referring to a planned or chosen start.
  • Typical Usage: Almost always used in the phrase “at the outset” or “from the outset”:
    • He made his intentions clear at the outset of the meeting.
    • There were problems with the project from the outset.
    • She felt positive at the outset of her new career.