Monthly Archives: February 2026
Drone-pressor
The Drone-pressor is a specialized audio restoration and spectral processing plugin designed for film post-production, broadcast, and field recording cleanup. Unlike a standard compressor or noise gate, it uses AI-driven motion-tracking algorithms to isolate and suppress the specific non-linear acoustic signatures of Unmanned Aerial Vehicles (UAVs).
Below are the technical specifications for its primary control parameters.
1. Pitch Take-Off Speed
This parameter controls the sensitivity of the plugin’s tracking oscillator. Because drone motors increase in pitch exponentially during takeoff or rapid maneuvers, a standard static filter would fail to track the sound.
* Specification: A temporal-frequency variable that defines the rate (in Hz/ms) at which the suppression filter can “climb” or “dive.”
* Function: Lower settings are used for stable, hovering drones. Higher settings allow the plugin to maintain suppression during aggressive vertical climbs or “punch-outs” where the RPM spikes instantly.
2. Doppler Effect Remover
This is the “spatial de-shifter.” It counteracts the frequency compression and expansion caused by the drone’s movement relative to the microphone.
* Specification: An inverse-motion algorithm that calculates the radial velocity of the sound source.
* Function: It “un-stretches” the audio in real-time. It identifies the pitch drop (the “Nee-Yum” sound) and applies a compensatory pitch-shift in the opposite direction, keeping the fundamental drone frequency centered so the narrow-band notch filters can remain locked on the target.
3. Drone Size (UAV Mass Class)
The acoustic signature of a drone is dictated by the length and material of its propellers. Smaller drones “whine” (high frequency), while larger drones “thrum” (low-mid frequency).
* Specification: A multi-band spectral profile selector ranging from Nano/Micro (250g) to Industrial/Heavy Lift (25kg+).
* Function: Adjusting this shifts the plugin’s “Attention Mask.”
* Small: Focuses on 2kHz to 15kHz.
* Large: Focuses on 150Hz to 1.5kHz.
4. Optical Metadata Integration (The Camera Toggle)
This unique feature allows the plugin to sync with visual data from the film set or the drone’s onboard feed to improve accuracy.
Parameter: Camera Sync (Enabled)
* Specification: Utilizes an Optical Flow Analysis bridge.
* Function: The plugin “looks” at the video file in the DAW. If the drone is visually moving left to right at a certain speed, the plugin automatically calculates the required Doppler correction and suppression strength based on the pixel-distance from the camera. It automates the parameters based on what is seen on screen.
Parameter: Blind Mode (No Camera)
* Specification: Pure Acoustic Inference Engine.
* Function: The plugin relies entirely on the audio signal. It uses a “best-guess” AI model to identify the drone type and distance based solely on harmonic distortion and the sound pressure level (SPL). This is used for audio-only recordings or when the drone is “off-camera.”
Summary Table for DAW Implementation
| Parameter | Unit | Purpose |
| Slew Rate | Hz/ms | Tracks how fast the motor pitch changes. |
| Shift Comp | Percentage | How much of the Doppler shift to flatten. |
| Mass Profile | grams/kg | Adjusts the frequency “sweet spot.” |
| Optic Link | On/Off | Syncs suppression to visual movement. |
To effectively remove the sound of a drone from an audio track, the “Drone-pressor” needs parameters that address the specific physics of multi-rotor flight. Because drones are moving targets with shifting frequencies, a simple static filter won’t work.
Here are the essential parameters for the removal engine:
1. Fundamental Frequency Tracking (f_0)
Since drone motors spin at variable speeds, the “noise” isn’t a single tone—it’s a moving target.
* Auto-Center: A real-time pitch tracker that locks onto the primary whine of the motors.
* Harmonic Multiplier: Drones produce integer multiples of their base frequency (overtones). This parameter allows you to suppress the 2nd, 3rd, and 4th harmonics simultaneously with a single slider.
2. Blade Count & Symmetry
The number of propellers changes the “texture” of the sound.
* Blade Parameter: Select between Tri-blade (smoother, higher frequency) or Bi-blade (choppier, more aggressive).
* Phase Offset: Adjusts for the fact that four motors are never perfectly in sync, creating a “beating” or “pulsing” effect.
3. Spatial Motion Parameters
These deal with the drone’s physical movement through the 3D sound field.
* Radial Velocity (Doppler Fix): A “Look Ahead” feature that predicts the pitch drop as the drone passes the microphone, adjusting the notch filters before the frequency shift occurs.
* Proximity Gain: An inverse-square law filter. As the drone gets closer (louder), the suppression intensity automatically increases to prevent clipping or “bleed.”
4. Turbulence & “Prop Wash” Removal
When a drone descends or turns sharply, it creates chaotic, low-frequency air turbulence that sounds like “buffeting.”
* Wash-Gate: A frequency-dependent transient shaper that targets the “thumping” air sounds without affecting the dialogue or ambient background.
* Jitter Reduction: Smooths out the micro-fluctuations in pitch caused by the flight controller making thousands of tiny motor adjustments per second.
5. Environment & Occlusion
* Reflectivity Scale: Adjusts how the plugin handles “echoes” of the drone bouncing off buildings or trees.
* Optical Occlusion (Camera Link): If the camera “sees” the drone go behind a wall, this parameter automatically softens the high-frequency suppression, as the wall would naturally act as a low-pass filter.
Summary of Parameter Controls
| Parameter Name | Unit | Action |
|—|—|—|
| Harmonic Depth | dB | How aggressively to cut the overtones. |
| Slew Rate | ms | How fast the filter follows a pitch change. |
| Blade Profile | 2 / 3 / 4 | Matches the filter shape to the prop type. |
| Doppler Ratio | M/S | Compensates for the speed of the passing drone. |
Making buttons glow in python
VU meter iterations
Ever wonder why VU meters are always rectangular or circular?
It’s usually a matter of mechanical necessity. In the analog world, the physical sweep of a needle and the housing required to protect it dictated the design. We’ve become so accustomed to these “skeuomorphic” constraints that anything else feels almost alien—mechanically impossible, and therefore, aesthetically foreign.
But when you move from physical hardware to dynamic variables, hooks, and handles, those walls disappear.
The Danger & Joy of “Outside the Box”
Iterating without boundaries is a double-edged sword:
-The Danger: You can lose the user. If a shape is too “unseen,” it loses its familiarity and function.
-The Joy: You unlock unlimited potential. By manipulating the geometry through code, I’ve been riffing on the classic VU meter to see where the math takes me.
I’ve had to invent a new vocabulary just to keep track of these iterations. Say hello to the Squircle, the Squectangle, and the Hex-Dome.
Breaking the Skewmorphic Ceiling:
By leaning into the “mechanically impossible,” we create something that couldn’t exist in a world of gears and glass. It challenges the eye and redefines what an interface can look like.
Personally, the Parking Meter style is my favorite—there’s something inherently authoritative and nostalgic about that heavy arc.
Which of these shapes do you think works best? Or have we pushed “outside the box” too far?
#DesignSystems #UIUX #IterativeDesign #CreativeCoding #VUMeters #ProductDesign
Zero-Copy Sound: How MXL Reinvents Audio Exchange for the Software-Defined Studio
The broadcast industry is undergoing a fundamental shift from hardware-centric systems to software-defined infrastructure, a move championed by initiatives like the EBU Dynamic Media Facility (DMF). At the heart of this transition lies the Media eXchange Layer (MXL), a high-performance data plane designed to solve the interoperability challenges of virtualized production. While MXL handles video through discrete grains, its approach to audio—via Continuous Flows—represents a sophisticated evolution in how compute resources exchange data using shared memory.
The Move from Sending to Sharing
Traditional IP broadcast workflows rely on a “sender/receiver” model involving packetization and network overhead. MXL replaces this with a shared memory model. In this architecture, media functions (such as audio processors or mixers) do not “send” audio; rather, they write data to memory-mapped files located in a tmpfs (RAM disk) backed volume known as an MXL Domain.
This allows for a “zero-overhead” exchange where readers and writers access the same physical memory, eliminating the CPU cycles usually wasted on copying data or managing network stacks. Continue reading
Schematic Semantics: Ethernet left or right side
The debate over whether an Ethernet port functions as a transmitter or a receiver on a schematic is the technical equivalent of the “toilet paper over or under” argument. It is a fundamental disagreement over orientation that often ignores the fact that the utility remains the same regardless of which way the roll is hanging.
Traditionally, schematics follow a rigid left-to-right flow: sources (transmitters) live on the left, and sinks (receivers) live on the right. This worked perfectly for analog audio or serial data where electricity moved in one direction. Ethernet, however, is a bidirectional transceiver technology. It is constantly “pushing” and “pulling” simultaneously, which breaks the traditional rules of drafting.
The Access vs. Consumption Debate
Many designers view the Ethernet switch as the “provider.” In this mental model, the switch is the source of connectivity, sitting on the left side of the page and “feeding” access to the edge devices on the right. The edge device is seen as the consumer of the network.
Conversely, others view the edge device as the “source” of the data itself. If a 4K camera is generating a video stream, that camera is the transmitter, and the switch is merely the consumer of that stream. In this scenario, the camera sits on the left, and the switch sits on the right.
Why It Is Like Toilet Paper
Just like the “over or under” debate, both sides have logical justifications that feel like common sense to the practitioner:
* The “Over” (Switch as Source) Argument
* It prioritizes infrastructure. Without the switch, there is no signal path.
* It follows the logic of power distribution, where the source of “energy” (in this case, data access) starts at the core.
* It treats the network as a utility, similar to a water main providing flow to a faucet.
* The “Under” (Edge as Source) Argument
* It prioritizes the payload. A switch with no devices has nothing to move.
* It maintains the “Signal Flow” tradition. If a microphone generates audio, it must be on the left, regardless of whether it uses an XLR or an RJ45 jack.
* It focuses on the intent of the system (e.g., getting video from a camera to a screen).
The Best Mechanism for Drafting
The shift in modern schematic design is moving away from seeing the switch as a “provider of access.” Instead of trying to force a bidirectional “highway” into a one-way “pipe” layout, the most effective designers are treating the switch as a neutral center point.
By placing the network switch in the center of the drawing, you acknowledge its role as a transceiver. You can then place “Signal Generators” (like cameras or microphones) to the left of the switch and “Signal Consumers” (like displays or speakers) to the right. This acknowledges that while the switch provides the “road,” it is the edge devices that provide the “traffic.”
Ultimately, as long as the drawing is consistent, it doesn’t matter if the “paper” is hanging over or under—as long as the data reaches its destination.
Reference of Audio Metering
The Master Reference of Audio Metering
Audio metering serves two distinct masters: Psychoacoustics (how loud the human ear perceives sound) and Electrical Limits (how much voltage the equipment can handle). No single meter can do both perfectly.
This document compiles the ballistics, scales, visual ergonomics, and technical implementations of the world’s major audio metering standards.
The 50ms Loop: A Broadcast Engineer’s Confusion with AV Standard Practice
By: Anthony Kuzub. A Confused Broadcast Engineer
I’ve spent the last twenty years in OB vans and broadcast control rooms. In my world, “latency” is a dirty word. (production offsets is what I like to call them) If a signal is one frame out of sync, we panic. If a host hears their own voice in their IFB (earpiece) with even a 10ms delay, they stop talking and start shouting at us. You can judge an in ear mix by how far they throw the beltpack.
So can you imagine my confusion when I recently stepped into the commercial AV world to help commission a high-end boardroom.
I opened a clients DSP file—a standard configuration for a room with ceiling mics and local voice lift—and I saw something that made me think I was reading the schematic wrong.
There were Acoustic Echo Cancellation (AEC) blocks on everything.
Not just on the lines going to the Zoom call (where they belong), but on the microphones being routed to the local in-room speakers. I turned to the lead AV integrator and asked a genuine question:
“Why are we running the podium mic through an echo canceller just to send it to the ceiling speakers five feet away?”
His answer was, “To stop the echo.”
And that is when my brain broke.
The Chicken, The Egg, and The Latency
In broadcast, we follow a simple rule: Signal flow follows physics.
If I am standing in an empty room and I speak, there is no electronic echo. If I turn on a microphone and send it to a speaker with zero processing, there is still no echo—there might be feedback (squealing) if I push the gain too high, but there is no distinct, slap-back echo.
So, I looked closer at the AEC block in the software.
• Processing Time: ~20ms to 50ms (depending on the buffer and tail length).
Suddenly, the math hit me. By inserting this “safety” tool into the chain, we were effectively delaying the audio by nearly two video frames before it even hit the amplifier.
Here is the loop I saw:
1. The presenter speaks.
2. The DSP holds that audio for 50ms to “process” it.
3. The audio comes out of the ceiling speakers 50ms late.
4. The microphones at the back of the room hear that delayed sound.
5. Because 50ms is well beyond the Haas Effect integration zone, the system (and the
human ear) perceives this as a distinct second arrival. A slap-back. An echo.
Creating the Problem to Fix the Problem
I realized that in this room design, the AEC wasn’t curing the echo; it was the source of it.
Because the system was generating a delayed acoustic signal, the other microphones in the room were picking up that delay. The integrator’s solution? “Oh, just put AEC on those back mics too.”
It felt like watching a doctor break a patient’s leg just so they could bill them for a cast.
In the broadcast world, we use “Mix-Minus” (or N-1). If a signal doesn’t need to go to a destination, you don’t send it. If a signal doesn’t need processing, you bypass it. You strip the signal path down to the copper.
The “Empty Room” Test
I proposed a crazy idea to the team. I asked them to imagine the room completely empty. No Zoom call. No Microsoft Teams. Just a guy standing at a podium speaking to people in chairs.
• Is there a remote caller? No.
• Is there a far-end reference signal? No.
• Is there a need to cancel anything? No
If we simply bypassed the AEC block for the local reinforcement, the latency dropped from 50ms down to about 2ms. At 2ms, the sound from the speakers arrives at the listener’s ear almost simultaneously with the actual voice of the presenter. The “echo” vanishes.
The system became stable not because we added more processing, but because we stopped fighting physics.
A Plea from the Control Room
I’m still learning the ropes of AV, and I know that VTC calls are complex. But I can’t help but feel that we are over-engineering our way into failure.
If you have to use an Echo Canceller to remove an echo that you created by using an Echo Canceller… maybe it’s time to just turn the Echo Canceller off.