SAMPLER.LIKE.AUDIO Bringing Hardware Sampler Soul to the Web Browser

SAMPLER.LIKE.AUDIO

Bringing Hardware Sampler Soul to the Web Browser

The Web Sampler & Sequencer is a fully-featured, open-source drum machine designed to run entirely within a modern web browser. By bridging the tactile workflow of classic beat-making hardware with the accessibility of modern web APIs, it offers a robust music production experience directly from a web browser.

Here is a breakdown of what makes this project technically unique and how it faithfully honors its hardware roots.

What Makes It Unique

The application stands out due to its radical approach to software architecture and browser integration, prioritizing transparency and local execution over cloud dependencies.

  • Zero-Dependency Architecture: The app requires no backend server, no Node.js environment, and no build tools like Webpack.

  • Direct Local File Access: It utilizes the File System Access API on Chromium-based browsers to let users browse and load samples directly from a local computer folder.

  • Absolute Privacy: Because it runs entirely client-side, the app never uploads a user’s audio files or patterns to a remote server.

  • Custom Legacy Audio Decoding: Alongside standard native Web Audio API formats (WAV, MP3, OGG, FLAC), it features a custom pure-JavaScript decoder for AIFF/AIFC files, which are common in vintage sample libraries.

  • Offline Independence: A built-in service worker caches the application shell and libraries, allowing the sampler to function completely offline after the initial load.

  • Transparent Codebase: The source code adheres to a strict philosophy where no individual file exceeds 200 lines.

  • No Compilation Needed: The app runs React natively in the browser via standalone Babel, meaning anyone can “View Source,” edit the code in a text editor, and refresh the page to see changes immediately.

Faithfulness to Hardware Samplers

Despite running in a web browser, the application meticulously recreates the physical feel and workflow limitations that made classic hardware samplers so intuitive.

  • Classic MPC Layout: The interface is built around a traditional 4×4 grid of 16 drum pads.

  • Mouse-Based Velocity: It simulates physical velocity sensitivity by calculating how close the user clicks to the exact center of a pad.

  • Plug-and-Play MIDI: The Web MIDI API allows users to plug in class-compliant USB controllers (like an Akai MPD) to finger-drum immediately with real velocity capture.

  • Tone Mode: By holding CTRL and clicking a pad, users can map a single sample chromatically across all 16 pads to sequence melodies and basslines.

  • Advanced Step Sequencing: The sequencer mimics classic hardware parameters, offering granular, per-step control over velocity, panning, pitch, and swing (shuffle).

  • Analog-Modeled Synthesis: When no sample is loaded on a pad, the app falls back on custom synthesis engines designed to strip acoustic percussion down to its physics—such as modeling the thump of a kick drum or the high-pass filtered noise of a snare wire.

Feature Translation: Hardware vs. Web

Hardware Concept Web Sampler Implementation
Internal Memory

Saves kits, favored samples, and patterns locally using browser localStorage and IndexedDB.

Sample Browsing

Recursively scans local directories to build a searchable, visual waveform grid.

Pattern Chaining

Provides 4, 8, 16, 32, and 64-step pattern options that can be managed in a dedicated Song tab.

Mixer Console

Features a dedicated mixer view with per-track volume, panning, and a shared reverb bus.

SCANALYZER.Like.Audio

https://Scanalyzer.Like.Audio 

At its core, scanalyzer is a smart, automated librarian for your audio files. If you have a massive, unorganized folder full of thousands of random audio samples,
finding the exact sound you need can be a nightmare. This software “listens” to every single file, figures out what it actually sounds like, and visually organizes
your entire collection so you can browse it instantly.

What It Actually Does (The Magic)

Instead of relying on whatever messy name the file was given (like BD_01_final_v2.wav ), the tool relies on acoustic science. When you point it at a folder, it does
the following:

1. Listens & Measures: It quickly scans through your audio files and measures things like how loud it is, how long it rings out, whether it’s a pitched note (like a
piano) or a burst of noise (like a cymbal), and how distorted it is.

2. Classifies & Groups: Based on those measurements, it categorizes the sound. It can tell the difference between a thumping bass, a short drum hit, a lingering
background texture, or a vocal line. It organizes them into a top-level hierarchy (like Percussive, Tonal, or Complex).

3. Builds a Map: It groups sounds that share similar characteristics together—regardless of what they are named.

The Key Benefits for Your Library

• The 3D Sound Cloud: It takes all your sounds and plots them as points in a 3D interactive “cloud.” You can literally see your entire sample library at a glance. If
you click an area where the “kick drums” are grouped, you can visually explore and play similar sounds right next to each other.

• Intelligent Renaming & Reorganizing: Once the software knows what everything is, it features a tool that allows you to easily rename your files and sort them into
neat, structured folders based on their true acoustic traits.

• 100% Private (No Cloud Needed): Even though there is a web browser version of this app, none of your audio files ever leave your computer. All the heavy lifting is
done right on your machine, so your private library stays private.

• Never Scans the Same Thing Twice: Once a file is scanned, it creates a tiny digital “nametag” (a .PEAK file) next to it. If you run the scan again in the future,
it reads the nametag instead of re-listening to the whole sound, saving you a ton of time.

How You Experience It

You can use the tool in two ways—they both do the exact same thing:

• As a Desktop App: A standalone application window running on your computer.
• As a Web Page: A sleek web interface that runs right in your browser (but again, totally offline and client-side).

It turns a chaotic, messy folder of audio files into a clean, searchable, visually explorable library using the actual sound of the files, not just their
filenames.

The Live Sound “Gotcha”: When 48k AVB Fits the Amps, but Breaks the System Core

The Live Sound “Gotcha”: When 48k AVB Fits the Amps, but Breaks the System Core

Every system engineer knows that dangerous moment on a load-in day: the false sense of security. You’ve run your lines, your network switches are glowing with beautiful, stable activity LEDs, and the initial pink noise test passes with flying colors. You step away from the tech table to grab a cold coffee, entirely confident that the audio rig is rock-solid.

Then, you roll in the primary loudspeaker processor, and the entire house of cards collapses.

This is the story of a classic digital audio “gotcha”—a day where a perfectly innocent, standard-rate network conversion box works flawlessly with your amplifiers, only to hit a brick wall when plugged into the system’s central processing brain. It isn’t a hardware failure, and it isn’t the conversion box’s fault. It’s a clash of two entirely different architectural mindsets within modern professional sound systems.

Phase 1: The 48 kHz Honeymoon
The day starts simple. The venue or tour is built around a standard, reliable 48kHz digital infrastructure. To get those console channels out to the main PA over the network, you deploy a format converter to bridge your console’s protocol over to an AVB network stream. It effortlessly spits out a 48kHz AVB stream, pointing it straight down the network to your modern, network-native power amplifiers.

You open your system management software, route the AVB streams to the amps, and *boom*—clean audio.
Why does this work so beautifully? Because modern professional amplifiers are engineered with an “adaptable endpoint” ideology. Even though the internal DSP core of a high-end network amplifier almost always operates natively at 96 kHz,  manufacturers design these endpoints to be incredibly forgiving listeners. When the amplifier detects an incoming 48kHz AVB stream, its onboard network hardware automatically engages an internal Sample Rate Converter (SRC). It gracefully up-samples the 48 kHz network audio to 96kHz at the input gate without a single error or clock pop.
You walk away from the rack room smiling. The 48 kHz stream is happy, the 96kHz amps are happy, and the system sounds incredible.

Phase 2: Rolling in the System Brain
After lunch, the central system processor or immersive matrix engine arrives. This is the master brain tasked with handling complex distribution, time-alignment, tuning, or object-based spatial mixing for the entire venue. To maximize mathematical precision, filter accuracy, and the microsecond time-delays that modern sound system design demands, the configuration dictates that this core processor must be run at its native, premium 96 kHz mode

mode.

You re-patch the network. Instead of sending the conversion box’s 48kHz AVB stream straight to the amplifiers, you route those console tracks into the inputs of the loudspeaker processor first, intending to let the core brain do the heavy DSP lifting before handing the final mix off to the amps.
You click “Connect.”

Suddenly, the network status screen lights up bright red. Absolute silence fills the room. The system processor throws a massive clocking error and completely refuses to unlock the streams.

The Gotcha: A Tale of Two Ideologies
This is where the trap snaps shut. It is incredibly easy to assume that because manufacturers build seamless, automatic sample rate conversion into their *amplifiers*, they must have put that exact same capability into their flagship *central processors*.

They didn’t.

Unlike endpoint amplifiers—which only have to manage a handful of audio channels destined for a specific set of speakers—a core loudspeaker processor or matrix hub handles dozens or hundreds of simultaneous routing cross-points. Because of this massive processing scale, high-end system processors are designed with a strict “True Match” architectural ideology: the input streams must match the internal engine clock identically.

These heavy-duty central brains generally do not possess asynchronous sample rate converters across their primary network input cards. When you set that master processor to run at 96kHz, it completely blinds itself to 48kHz AVB streams. It cannot upscale them on entry the way the amplifiers did just an hour prior.

Not a Fault, But a Generational Shift
It is tempting to blame the conversion box in this scenario, but the box is doing exactly what it was asked to do: outputting a clean, stable 48kHz network stream. The breakdown occurs entirely because of a shift in engineering mindsets between different classes of DSP hardware.
An amplifier is designed to be a flexible destination; it adapts to whatever flavor of audio you feed it because it sits at the very end of the line. A core matrix processor, however, is designed to be the absolute master clock authority of a massive sound system; it demands total consistency across its inputs to maintain strict, deterministic processing latency and absolute mathematical accuracy

The Fix for the System Engineer
By the time the sun starts to set, the lesson is learned. To get out of this corner, you have two choices:

1. **The Compromise:** Force the central loudspeaker processor to drop its internal engine down to 48kHz to match your conversion box. You lose a tiny bit of high-sample-rate resolution on paper, but the network immediately locks, the audio flows, and the show goes on.

2. The Right Tool for the Job: Recognize that a 48 kHz console infrastructure and a 96kHz system processing core need a dedicated mediator. You introduce a heavy-duty, system-grade hardware network bridge—one specifically engineered with the massive asynchronous processing horsepower required to upscale a 48kHz world into a strict, pristine 96kHz network stream before it ever hits the processor’s input gate

the show must go on:

The Hybrid Infrastructure Compromise: If you are dealing with a permanent installation or a split system where some zones absolutely demand 96kHz networking but others are trapped in 48kHz, you start splitting lanes. You run an old-school, analog 2-wire copper lines straight into a handful of local amplifiers to bypass the network entirely, while simultaneously building an AES3-to-AVB hardware gateway elsewhere in the rack. By taking a 48 kHz AES3 feed and running it through a local gateway that handles the up-sampling to 96kHz AVB, you can feed the master processor exactly what it wants for the main array, leaving the copper to handle the rest.

In live sound, assuming that two pieces of gear from the same generation or ecosystem think the same way is the fastest route to a headache. Always look past the network jack on the chassis, check the clocking architecture under the hood, and remember that just because an amp can adapt, doesn’t mean the brain can.

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.

Continue reading

CMDP: Circular Motion Displacement Potentiometer

CMDP: Circular Motion Displacement Potentiometer

DEMO: http://like.audio/CMDP

# CMDP: Circular Motion Displacement Potentiometer

Overview
The **Circular Motion Displacement Potentiometer (CMDP)** is a novel user interface concept designed for spatial audio mixing, microphone array management, and multidimensional sound control. It combines the precision of linear faders with the intuitive spatial organization of a polar coordinate system, allowing users to visualize and manipulate sound sources in a 360-degree field.

 

Continue reading

(GCA) Ganged Controlled Array

(GCA) Ganged Controlled Array – Anthony P. Kuzub (Anthony@Kuzub.com)

DEMO:  https://like.audio/GCA/

## Overview

The **Ganged Controlled Array (GCA)**, also known as the **Composite Fader**, is a high-density user interface widget designed to manage multiple related parameters (channels) through a single “Master” fader cap. It solves the problem of controlling groups of values (e.g., a 5.1 surround mix, a drum bus, or an RGB color mix) where maintaining relative offsets is critical, but screen real estate is limited.

# Composite Smart-Fader Design & Style Guide

Continue reading

Linear Traveling Potentiometer – Software

February is Toronto AES Audio Engineering Society Member showcase….

The **Linear Travelling Potentiometer (LTP)** is a hybrid user interface widget designed to save screen real estate while maximizing control density. It integrates a rotary knob directly onto the cap of a linear fader, allowing simultaneous control of two related parameters (e.g., Level and Pan, or Send Level and Send Pan) in a single compact footprint.

Back in 2013, I presented a concept at the AES Toronto meeting called the “Linear Traveling Potentiometer” (LTP).

demo: https://like.audio/LTP/

The idea was simple but mechanically complex: Combine a linear fader and a rotary potentiometer into a single, fluid control. Two motions, one component.

I even had a prototype in a “black bag” that I let people feel without seeing. The goal was to control intensity (volume) and position (pan) simultaneously—a single-point coordinate system for surround sound and spatial audio.
For years, this existed mostly as hardware prototypes and sketches. But the vision never went away.

Now, nearly 15 years later, I have finally recreated my vision purely in software. Click, grab it like a fader… Move up for volume and sideways to pan…

I’ve brought the “Two in One” concept to life digitally. No moving parts, just the physics of the original idea translated into code.

It’s been a long road from that first presentation to this software build. Sometimes the technology just needs to catch up to the idea.



 

# builder_audio/dynamic_gui_create_custom_LTP.py
#
# A Linear Traveling Potentiometer (LTP) widget.
# Acts as a vertical fader, but the cap is a rotatable knob.
# Control + Drag rotates the knob (-100 to 100).
# Standard Drag moves the fader vertically.
# “Freestyle” mode allows adjusting both axes simultaneously (vertical=fader, horizontal=rotation).
#
# Author: Anthony Peter Kuzub
# Blog: www.Like.audio (Contributor to this project)
#
# Professional services for customizing and tailoring this software to your specific
# application can be negotiated. There is no charge to use, modify, or fork this software.
#
# Build Log: https://like.audio/category/software/spectrum-scanner/
# Source Code: https://github.com/APKaudio/
# Feature Requests can be emailed to i @ like . audio
#
# Version 20250821.200641.1
import tkinter as tk
from tkinter import ttk
import math
from managers.configini.config_reader import Config
app_constants = Config.get_instance()
# — Default Configuration Constants —
DEFAULT_LTP_WIDTH = 100
DEFAULT_MIN_VAL = 0.0
DEFAULT_MAX_VAL = 100.0
DEFAULT_LOG_EXPONENT = 1.0
DEFAULT_BORDER_WIDTH = 0
DEFAULT_BORDER_COLOR = “black”
DEFAULT_TICK_SIZE_RATIO = 0.2
DEFAULT_TICK_FONT_FAMILY = “Helvetica”
DEFAULT_TICK_FONT_SIZE = 10
DEFAULT_TICK_COLOR = “light grey”
DEFAULT_VALUE_FOLLOW = True
DEFAULT_VALUE_HIGHLIGHT_COLOR = “#f4902c”
DEFAULT_CAP_RADIUS = 18 # Radius of the knob cap (Increased by 20% from 15)
ROTATION_MIN = 100.0
ROTATION_MAX = 100.0
# ———————————————
from workers.logger.logger import debug_logger
from workers.logger.log_utils import _get_log_args
from workers.styling.style import THEMES, DEFAULT_THEME
from workers.handlers.widget_event_binder import bind_variable_trace
class CustomLTPFrame(tk.Frame):
def __init__(
self,
master,
config,
path,
state_mirror_engine,
base_mqtt_topic,
subscriber_router,
):
colors = THEMES.get(DEFAULT_THEME, THEMES[“dark”])
fader_style = colors.get(“fader_style”, {})
self.bg_color = colors.get(“bg”, “#2b2b2b”)
self.accent_color = colors.get(“accent”, “#33A1FD”)
self.neutral_color = colors.get(“neutral”, “#dcdcdc”)
self.track_col = colors.get(“secondary”, “#444444”)
self.handle_col = colors.get(“fg”, “#dcdcdc”)
self.text_col = colors.get(“fg”, “#dcdcdc”)
self.min_val = float(config.get(“value_min”, DEFAULT_MIN_VAL))
self.max_val = float(config.get(“value_max”, DEFAULT_MAX_VAL))
self.log_exponent = float(config.get(“log_exponent”, DEFAULT_LOG_EXPONENT))
self.reff_point = float(
config.get(“reff_point”, (self.min_val + self.max_val) / 2.0)
)
self.border_width = int(config.get(“border_width”, DEFAULT_BORDER_WIDTH))
self.border_color = config.get(“border_color”, DEFAULT_BORDER_COLOR)
# Cap Styling
self.cap_radius = int(config.get(“cap_radius”, DEFAULT_CAP_RADIUS))
self.cap_color = config.get(“cap_color”, self.handle_col)
self.cap_outline_color = config.get(“cap_outline_color”, self.track_col)
# Custom styling
self.tick_size = config.get(“tick_size”, fader_style.get(“tick_size”, DEFAULT_TICK_SIZE_RATIO))
tick_font_family = config.get(“tick_font_family”, fader_style.get(“tick_font_family”, DEFAULT_TICK_FONT_FAMILY))
tick_font_size = config.get(“tick_font_size”, fader_style.get(“tick_font_size”, DEFAULT_TICK_FONT_SIZE))
self.tick_font = (tick_font_family, tick_font_size)
self.tick_color = config.get(“tick_color”, fader_style.get(“tick_color”, DEFAULT_TICK_COLOR))
self.value_follow = config.get(“value_follow”, fader_style.get(“value_follow”, DEFAULT_VALUE_FOLLOW))
self.value_highlight_color = config.get(“value_highlight_color”, fader_style.get(“value_highlight_color”, DEFAULT_VALUE_HIGHLIGHT_COLOR))
self.value_color = config.get(“value_color”, self.text_col)
super().__init__(
master,
bg=self.bg_color,
bd=self.border_width,
relief=“solid”,
highlightbackground=self.border_color,
highlightthickness=self.border_width,
)
self.path = path
self.state_mirror_engine = state_mirror_engine
self.base_mqtt_topic = base_mqtt_topic
self.subscriber_router = subscriber_router
self.config = config
self.freestyle = config.get(“freestyle”, False)
# Initialize Variables
# Linear Value (Standard Fader)
self.linear_var = tk.DoubleVar(value=float(config.get(“value_default”, (self.min_val + self.max_val)/2)))
# Rotation Value (Knob)
self.rotation_var = tk.DoubleVar(value=float(config.get(“rotation_default”, 0.0)))
self.temp_entry = None
# Register Widgets with State Mirror Engine
if self.state_mirror_engine and self.path:
# Register main linear variable
self._register_sub_widget(“linear”, self.linear_var)
# Register rotation variable
self._register_sub_widget(“rotation”, self.rotation_var)
# Bind traces for Redraw
self.linear_var.trace_add(“write”, self._request_redraw)
self.rotation_var.trace_add(“write”, self._request_redraw)
def _register_sub_widget(self, suffix, variable):
if suffix == “linear”:
target_path = self.path
else:
target_path = f{self.path}/{suffix}
sub_config = self.config.copy()
sub_config[“path”] = target_path
if suffix == “rotation”:
sub_config[“value_min”] = ROTATION_MIN
sub_config[“value_max”] = ROTATION_MAX
self.state_mirror_engine.register_widget(target_path, variable, self.base_mqtt_topic, sub_config)
callback = lambda: self.state_mirror_engine.broadcast_gui_change_to_mqtt(target_path)
bind_variable_trace(variable, callback)
topic = self.state_mirror_engine.get_widget_topic(target_path)
if topic:
self.subscriber_router.subscribe_to_topic(topic, self.state_mirror_engine.sync_incoming_mqtt_to_gui)
self.state_mirror_engine.initialize_widget_state(target_path)
def _request_redraw(self, *args):
self.event_generate(“<<RedrawLTP>>”)
def _open_manual_entry(self, event, target_var, min_v, max_v):
if self.temp_entry and self.temp_entry.winfo_exists():
return
self.temp_entry = tk.Entry(self, width=8, justify=“center”)
self.temp_entry.place(x=event.x 20, y=event.y 10)
current_val = target_var.get()
self.temp_entry.insert(0, str(current_val))
self.temp_entry.select_range(0, tk.END)
self.temp_entry.focus_set()
submit_cmd = lambda e: self._submit_manual_entry(e, target_var, min_v, max_v)
self.temp_entry.bind(“<Return>”, submit_cmd)
self.temp_entry.bind(“<FocusOut>”, submit_cmd)
self.temp_entry.bind(“<Escape>”, self._destroy_manual_entry)
def _submit_manual_entry(self, event, target_var, min_v, max_v):
raw_value = self.temp_entry.get()
try:
new_value = float(raw_value)
if min_v <= new_value <= max_v:
target_var.set(new_value)
else:
if app_constants.global_settings[“debug_enabled”]:
debug_logger(
message=f“⚠️ Value {new_value} out of bounds! Ignoring.”,
**_get_log_args(),
)
except ValueError:
pass
self._destroy_manual_entry(event)
def _destroy_manual_entry(self, event):
if self.temp_entry and self.temp_entry.winfo_exists():
self.temp_entry.destroy()
self.temp_entry = None
class CustomLTPCreatorMixin:
def _create_custom_ltp(self, parent_widget, config_data, **kwargs):
label = config_data.get(“label_active”)
config = config_data
path = config_data.get(“path”)
layout_config = config.get(“layout”, {})
font_size = layout_config.get(“font”, 10)
custom_font = (“Helvetica”, font_size)
custom_colour = layout_config.get(“colour”, None)
state_mirror_engine = self.state_mirror_engine
subscriber_router = self.subscriber_router
base_mqtt_topic_from_path = kwargs.get(“base_mqtt_topic_from_path”)
colors = THEMES.get(DEFAULT_THEME, THEMES[“dark”])
bg_color = colors.get(“bg”, “#2b2b2b”)
secondary_color = colors.get(“secondary”, “#444444”)
frame = CustomLTPFrame(
parent_widget,
config=config,
path=path,
state_mirror_engine=state_mirror_engine,
base_mqtt_topic=base_mqtt_topic_from_path,
subscriber_router=subscriber_router,
)
if label:
lbl = tk.Label(frame, text=label, font=custom_font, background=bg_color, foreground=colors.get(“fg”, “#dcdcdc”))
if custom_colour:
lbl.configure(foreground=custom_colour)
lbl.pack(side=tk.TOP, pady=(0, 5))
width = layout_config.get(“width”, DEFAULT_LTP_WIDTH)
height = layout_config.get(“height”, 300)
canvas = tk.Canvas(
frame, width=width, height=height, bg=bg_color, highlightthickness=0
)
canvas.pack(fill=tk.BOTH, expand=True)
canvas.update_idletasks()
# Visual State
visual_props = {“secondary”: secondary_color}
hover_color = “#999999”
# Interaction State
drag_state = {“start_x”: 0, “start_y”: 0, “start_val_lin”: 0, “start_val_rot”: 0, “active”: False}
def on_press(event):
drag_state[“active”] = True
drag_state[“start_x”] = event.x
drag_state[“start_y”] = event.y
drag_state[“start_val_lin”] = frame.linear_var.get()
drag_state[“start_val_rot”] = frame.rotation_var.get()
if not (event.state & 0x0004): # No Ctrl
update_linear_from_y(event.y)
def on_drag(event):
if not drag_state[“active”]:
return
is_ctrl = event.state & 0x0004
if frame.freestyle:
# Vertical adjusts fader, Horizontal adjusts rotation
update_linear_from_y(event.y)
update_rotation_from_x(event.x)
elif is_ctrl:
# Rotation Mode (Vertical drag for rotation)
dy = drag_state[“start_y”] event.y
sensitivity = 2.0
new_rot = drag_state[“start_val_rot”] + (dy * sensitivity)
new_rot = max(ROTATION_MIN, min(ROTATION_MAX, new_rot))
frame.rotation_var.set(new_rot)
else:
# Linear Mode
update_linear_from_y(event.y)
def on_release(event):
drag_state[“active”] = False
def update_linear_from_y(y):
h = canvas.winfo_height()
norm_y = (y 20) / (h 40)
norm_y = 1.0 max(0.0, min(1.0, norm_y))
log_norm_pos = norm_y**frame.log_exponent
current_value = frame.min_val + log_norm_pos * (
frame.max_val frame.min_val
)
frame.linear_var.set(current_value)
def update_rotation_from_x(x):
w = canvas.winfo_width()
# Rotation area same length as fader height (h-40)
# Center it at the current rail? Or just relative to the whole canvas width.
# User said “area to move it left or right should be about the same length as the fader”
h = canvas.winfo_height()
fader_len = h 40
# Start rotation from center of canvas
cx = w / 2
# Offset from center
dx = x cx
# Map dx to rotation value. fader_len total width for full rotation range?
# So range is [-fader_len/2, fader_len/2]
norm_x = dx / (fader_len / 2.0)
norm_x = max(1.0, min(1.0, norm_x))
new_rot = norm_x * 100.0 # ROTATION_MAX
frame.rotation_var.set(new_rot)
def on_alt_click(event):
frame._open_manual_entry(event, frame.linear_var, frame.min_val, frame.max_val)
def redraw(*args):
current_w = canvas.winfo_width()
current_h = canvas.winfo_height()
if current_w <= 1: current_w = width
if current_h <= 1: current_h = height
_draw_ltp_vertical(
frame,
canvas,
current_w,
current_h,
visual_props[“secondary”]
)
frame.bind(“<<RedrawLTP>>”, redraw)
# Initial Draw
redraw()
# Bindings
canvas.bind(“<Button-1>”, on_press)
canvas.bind(“<B1-Motion>”, on_drag)
canvas.bind(“<ButtonRelease-1>”, on_release)
canvas.bind(“<Alt-Button-1>”, on_alt_click)
canvas.bind(“<Configure>”, lambda e: redraw())
def on_enter(event):
visual_props[“secondary”] = hover_color
redraw()
def on_leave(event):
visual_props[“secondary”] = secondary_color
redraw()
canvas.bind(“<Enter>”, on_enter)
canvas.bind(“<Leave>”, on_leave)
return frame
def _draw_ltp_vertical(frame, canvas, width, height, current_secondary):
canvas.delete(“all”)
cx = width / 2
# 1. Track Line
canvas.create_line(
cx, 20, cx, height 20,
fill=current_secondary, width=4, capstyle=tk.ROUND
)
# 2. Calculate Handle Position (Linear)
value_lin = frame.linear_var.get()
norm_value = (
(value_lin frame.min_val)
/ (frame.max_val frame.min_val)
if (frame.max_val frame.min_val) != 0
else 0
)
norm_value = max(0.0, min(1.0, norm_value))
display_norm_pos = norm_value ** (1.0 / frame.log_exponent)
handle_y = (height 40) * (1.0 display_norm_pos) + 20
# 3. Fill Line (from bottom to handle)
canvas.create_line(
cx + 2.5, height 20, cx + 2.5, handle_y,
fill=frame.value_highlight_color, width=5, capstyle=tk.ROUND
)
# 4. Draw Rotatable Cap (Knob)
rot_val = frame.rotation_var.get()
# 0 val = -90 degrees (Up)
angle_deg = 90 + (rot_val / 100.0) * 135.0
angle_rad = math.radians(angle_deg)
radius = frame.cap_radius
# Cap Circle
canvas.create_oval(
cx radius, handle_y radius,
cx + radius, handle_y + radius,
fill=frame.cap_color, outline=frame.cap_outline_color, width=2
)
# Pointer Line
pointer_len = radius * 0.8
px = cx + pointer_len * math.cos(angle_rad)
py = handle_y + pointer_len * math.sin(angle_rad)
canvas.create_line(
cx, handle_y, px, py,
fill=frame.cap_outline_color, width=2, capstyle=tk.ROUND
)
# Values Text
if frame.value_follow:
# Linear Value to the right
canvas.create_text(
cx + radius + 10,
handle_y,
text=f{value_lin:.1f},
fill=frame.value_color,
anchor=“w”,
font=(“Helvetica”, 8)
)
# Rotation Value to the left
canvas.create_text(
cx radius 10,
handle_y,
text=f“R:{rot_val:.0f},
fill=frame.value_color,
anchor=“e”,
font=(“Helvetica”, 8)
)

## Core Concepts

### 1. Hybrid Control
* **Linear Fader (Y-Axis):** The vertical position of the cap controls the primary value (typically Volume, Level, or Depth).
* **Rotary Knob (Rotation):** A knob embedded in the fader cap controls a secondary value (typically Pan, Param, or Intensity).
* **Unified Interaction:** Both controls are accessible from the same visual element, reducing mouse travel and UI clutter.

### 2. Interaction Modes
The LTP supports distinct interaction modes to prevent accidental changes:

* **Standard Mode:**
* **Drag Handle:** Adjusts Linear Value only.
* **Alt/Option + Drag:** Adjusts Rotary Value only (Linear position is locked).
* **Scroll:** Fine-tune Linear Value.
* **Alt/Option + Scroll:** Fine-tune Rotary Value.

* **Freestyle Mode:**
* Dragging the handle adjusts **BOTH** Linear and Rotary values simultaneously based on 2D mouse movement. This allows for gestural control (e.g., “throwing” a sound into a corner).

* **Pan Latch:**
* **Double-Click** the cap to engage “Pan Latch”.
* In this state, horizontal mouse movement adjusts the Rotary value without needing to hold a modifier key.
* Click or drag again to disengage.

### 3. Visual Feedback
* **Linear:** Position of the cap along the vertical track.
* **Rotary:** Orientation of the indicator line on the cap.
* **Active State:** The knob glows (default blue/orange) when Rotary control is active (via modifier, latch, or freestyle mode).
* **Pointer:** When adjusting rotation, the indicator line extends (10x length) to provide precise visual feedback, then retracts on release.

## Use Cases

* **Channel Strips:** Volume (Linear) + Pan (Rotary).
* **Effect Sends:** Send Level (Linear) + Pre/Post Toggle or Send Pan (Rotary).
* **Synthesizers:** Cutoff (Linear) + Resonance (Rotary).
* **Spatial Audio:** Distance (Linear) + Azimuth (Rotary – mapped to circular motion).

## Implementations

### HTML5 Demo (`index.html`)
A standalone web-based demonstration using HTML5 Canvas.
* **Features:** Multi-touch support (1 finger slide, 2 finger twist/pan), keyboard modifiers, responsive layout.
* **Theme:** Dark mode with high-contrast UI.

## The Open Concept License

This project is released under **The Open Concept License**.

* **Freedom:** You are free to use, modify, and distribute this work.
* **Attribution:** Explicit credit to **Anthony Kuzub** must be given in all derivative works.
* **Nomenclature:** Implementations must strictly use the terms **LTP (Linear Travelling Potentiometer)**, **GCA (Ganged Controlled Array)**, and **MDP (Multi-Dimensional Panner)** where applicable.
* **Warranty:** Provided “As Is” without warranty.

*(See the full license text in the application footer or source code.)*

 

Optimizing Data Acquisition: The Architecture of GET, SET, RIG, and NAB

High-Throughput Instrument Control Protocol

In the world of instrument automation (GPIB, VISA, TCP/IP), the primary bottleneck is rarely bandwidth—it is latency. Every command sent to a device initiates a handshake protocol that incurs a time penalty. When managing complex systems with hundreds of data points, these penalties accumulate, resulting in “bus chatter” that freezes the UI and blocks other processes.

Continue reading

Decoupling Hardware and Interface: The Engineering Logic Behind OPEN-AIR

In the realm of scientific instrumentation software, a common pitfall is the creation of monolithic applications. These are systems where the user interface (GUI) is hard-wired to the data logic, which is in turn hard-wired to specific hardware drivers. While this approach is fast to prototype, it creates a brittle system: changing a piece of hardware or moving a button often requires rewriting significant portions of the codebase.

The OPEN-AIR architecture takes a strictly modular approach. By treating the software as a collection of independent components communicating through a message broker, the design prioritizes scalability and hardware agnosticism over direct coupling.

Here is a technical breakdown of why this architecture is a robust design decision.

Continue reading

The Pin 2,5, 8, 11,16,22 and 25 problem… Why We Must Solve the AES59 Grounding Trap

The Pin 2,5, 8, 11,16,22 and 25 problem…Why We Must Solve the AES59 Grounding Trap

https://www.aes.org/standards/comments/cfc-draft-rev-aes48-xxxx-251124.cfm

The “Pin 1 Problem” Multiplied: Why We Must Solve the AES59 Grounding Trap

By Anthony P. Kuzub Chair, AES-X249 Task Group SC-05-05-A

In the world of professional audio, the transition from XLRs to high-density DB25 connectors was a matter of necessity. We needed more channels in smaller spaces. But in adopting the AES59 standard (often called the TASCAM pinout), the industry inadvertently created a trap—an 8-channel variation of a problem we thought we had solved decades ago. Continue reading

SDP meta data and channel information

The Protocol-Driven Stage: Why SDP Changes Everything for Live Sound

For decades, the foundation of a successful live show has been the patch master—a highly skilled human who translates a band’s technical needs (their stage plot and input list) into physical cables. The Festival Patch formalized this by making the mixing console channels static, minimizing changeover time by relying on human speed and organizational charts.

But what happens when the patch list becomes part of the digital DNA of the audio system?

The demonstration of embedding specific equipment metadata—like the microphone model ($\text{SM57}$), phantom power ($\text{P48}$), and gain settings—directly into the same protocol (SDP) that defines the stream count and routing, paves the way for the Automated Stage. Continue reading