Request preparation

• I used an AI assistant to help structure this request
• I checked for existing issues covering the same feature

What would you like?

Title: Feature Request: Surface Aetherial Audio Presets in Profile Manager + Bundle Default Aetherial Audio Presets as Starting Points

What happened?

This report covers two related gaps in how AetherSDR's profile and Aetherial Audio Channel Strip systems work together:

1. Siloed preset selection. AetherSDR has two separate preset systems that don't share a UI or a single point of selection:

• Radio-side profiles (Profiles → Profile Manager…): Global, Transmit, and Microphone profiles, stored on the FLEX-6600.
• Aetherial Audio Channel Strip presets: the client-side DSP chain already supports named, saved/recallable presets (e.g., "Contest-DX," "Rag Chew," "ESSB") via its own preset library in the Aetherial Audio panel.

To fully reconfigure the station for an operating style, the operator must load a Transmit/Mic profile from the Profile Manager and separately open the Aetherial Audio panel to select the matching named chain preset — there's no combined "scenario" selection that does both in one action.

2. No bundled default Aetherial presets. AetherSDR ships without any default Aetherial Audio Channel Strip presets. New users get an empty preset library and must build every named preset from scratch by ear. I've built a working set of three presets — Contest-DX, Rag Chew, and ESSB — covering TX and RX chains for GATE/EQ/DESS/COMP/TUBE/PUDU/VERB, which could serve as a template for factory-bundled defaults, clearly labeled as starting points for the user to then tune to their own mic and voice. Representative highlights from each:

The full preset definitions are stored as JSON (attached as AetherSDR-ChannelStrip-Library_Defaults.json), keyed by preset name, with each preset carrying independent gate/eq/deess/comp/tube/pudu/reverb/finalLimiter objects for TX plus a nested rx object with the equivalent structure for RX — this schema maps directly onto the existing Client*Tx*/Client*Rx* settings keys and looks like a natural on-disk/importable format for factory-default presets.

What did you expect?

• A single named configuration (e.g., "Contest") that applies both the appropriate radio-side profile(s) and the matching Aetherial Audio preset in one action, without needing to visit the Profile Manager and the Aetherial Audio screen separately.
• Out-of-the-box, AetherSDR should include a small number of default Aetherial Audio presets — e.g., Contest-DX, Rag Chew, and ESSB as demonstrated above — that a new user can load immediately, then adjust to their own mic and voice, rather than starting from an empty preset library.

Steps to reproduce

1. Open the Aetherial Audio panel and confirm named TX chain presets can be created/saved (e.g., "Contest-DX," "Rag Chew," "ESSB"), but on a fresh install the preset list is empty — no defaults are bundled.
2. Open Profiles → Profile Manager… and note the tabs: Global, Transmit, Microphone, Auto-Save — there is no reference to, or control for, the Aetherial preset library here.
3. Load a Transmit profile intended to correspond to a contesting scenario.
4. Observe that the Aetherial Audio chain does not automatically switch to a matching preset — the operator must separately open the Aetherial Audio panel and manually select (or first build, since none ship by default) the corresponding preset.
5. Compare against a hand-built preset set (attached) covering Contest-DX/Rag Chew/ESSB — none of these, or anything like them, are loadable out of the box on a fresh install.

Radio model & firmware

FLEX-6600, firmware 4.2.20.41343

OS & version

Windows — AetherSDR 26.9.1, Qt 6.8.3

Developer Notes

Architecture context: Radio-side profiles round-trip over the SmartSDR command channel to the radio. The Aetherial Audio Channel Strip's named-preset library is persisted client-side in AetherSDR.settings (%APPDATA%\AetherSDR\AetherSDR\ on Windows) alongside the live Client*Tx*/Client*Rx* parameter keys and Client*ChainStages ordering keys. Both requested features are additive:

• Cross-linking profiles ↔ Aetherial presets is a UI/reference gap — needs a way for a Transmit/Global profile to carry a reference to (or trigger) an Aetherial preset by name.
• Bundled defaults is a packaging/data gap — needs factory preset definitions (attached JSON is a working example of the schema/values) shipped with the app and seeded into a fresh install's preset library on first run, or exposed as a "Restore factory presets" action that doesn't clobber a user's existing custom presets (note the attached file's structure already coexists cleanly with user-created entries like the fourth "Try1" preset in the same library — a defaults-seeding routine should only add/refresh the named factory presets, not touch others).

Likely source locations (inferred from the src/gui/ convention visible in recent PRs — please confirm exact paths/line numbers against the current tree, which I didn't have direct repo browsing access to):

• src/gui/ProfileManagerDialog.cpp / .h — needs an Aetherial-preset reference field per profile.
• The Aetherial Audio panel/preset-library UI (likely src/gui/AetherialAudioWidget.cpp or similarly named, feeding per-stage classes such as ClientEqWidget/ClientCompWidget/ClientTubeWidget/ClientPuduWidget/ClientReverbWidget) — needs (a) a public "load preset by name" entry point callable from the Profile Manager, and (b) a "load factory defaults" action separate from user-saved presets. The preset-serialization code (whatever reads/writes the JSON structure seen in the attached file — likely a PresetLibrary or ChannelStripPreset class) is the natural home for a "seed factory defaults" routine.
• AppSettings (likely src/core/AppSettings.h or src/gui/AppSettings.h) — stores the Aetherial preset library; would need a lookup table (profile name → Aetherial preset name) for the linkage.
• Packaging/resource layer (e.g., resources/ or resources/presets/, alongside the existing resources.qrc pattern) — where factory-default preset JSON (matching the attached file's schema) would be added and wired into the build via qt_add_resources.

Logging categories to enable for diagnostic capture (Help → Support…): Both items are feature/packaging requests rather than runtime faults, so logs won't show much, but for confirming current (non-)behavior:

• GUI (aether.gui) — confirm no hidden linkage exists between profile load and Aetherial preset selection.
• Transmit (aether.transmit) — TX state and profile load/save commands.
• Audio (aether.audio) — confirms the Aetherial chain doesn't react to a profile switch at the audio-processing layer.

Suggested fix direction:

1. Add an optional "Aetherial preset" association field to Transmit/Global profiles in the Profile Manager so loading a radio profile also triggers the linked Aetherial preset.
2. Ship the three attached presets (Contest-DX, Rag Chew, ESSB) — or an equivalent factory set derived from them — seeded on first run or available via a "Restore factory presets" action, clearly framed as starting points for the user to tune to their own mic and voice.

Attachment: AetherSDR-ChannelStrip-Library_Defaults.json (contains the three presets above; a fourth user-experimental preset in the same file is not part of this request and should be disregarded for the factory-default set).

AetherSDR-ChannelStrip-Library Defaults.json