Open-source toolkit: SWAM default MIDI maps + host parameter IDs (and an Ableton .als wirer)

[Bennnn]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

Hi all,

I play keys in a live band and wanted head-gesture control (a TEControl breath controller) over growl/flutter on a rack of nine SWAM Solo instruments (Audio Modeling) in Ableton Live — without doing MIDI-Learn on every instance. Along the way I ended up mapping out how SWAM stores its MIDI configuration, and I've open-sourced the findings and the tools in case they help someone else:

github.com/Beennnn/swam-toolkit (https://github.com/Beennnn/swam-toolkit) (MIT, Python stdlib only)

Three findings that might interest people here:

1. The factory MIDI map is identical across the whole SWAM Solo range. I extracted the default External Controller mapping from the factory presets of all 33 instruments I own (Brass, Woodwinds, Strings): Expression CC11, Vibrato Depth CC1, Vibrato Rate CC19, Volume CC7, Pan CC10, Sustain CC64, Reverb CC90 — receive channel Omni everywhere. Only the pitch-bend range differs by family. Full generated table is in the repo.

2. Host parameter IDs are predictable. Since SWAM is JUCE-based, the VST3 parameter ID of any parameter is the Java-style hashCode() of its internal name (e.g. growl -> 98629305). Verified against what Ableton stores after exposing the parameters. This makes host-side automation possible without ever opening the plugin GUI.

3. One .swamec file covers a family. The Controller-Mapping export format is plain XML, so the repo includes a generator that takes your factory mapping and appends custom CC assignments (growl/flutter/tremolo/etc.) — three generated files covered my whole collection, one Import click per instance. Import verified on SWAM Trumpet 3.5.0 / Live 12.

Nothing from Audio Modeling is redistributed — the tools only read the presets installed on your own machine, and no binaries were decompiled (everything comes from data files on disk, plus JUCE being open source).

Bonus for Ableton users: a companion tool that batch-wires plugin parameters to rack macros and MIDI mappings directly inside the .als project file (with a write-up of the .als macro/MIDI format): github.com/Beennnn/als-wire (https://github.com/Beennnn/als-wire)

Two things I could NOT verify, where help is welcome: whether the AU builds use the same parameter-ID hash (expected, being JUCE — but unverified), and the factory-preset paths on Windows.

Built in an AI-assisted workflow, all empirical checks run on a real install and a real live rig. Hope it's useful to someone. Cheers!

[Bennnn]

A few more SWAM findings since the initial post — all pulled out of the .swamec / state format while wiring a live rig, verified on real installs (SWAM 3.5.0, macOS).

1. Aftertouch (channel pressure) encoding. The factory maps are all CC (messageType="1"). Map a param to channel pressure, export a .swamec, and the entry is messageType="0" msb="-1". So: 1 = CC, 0 = channel pressure. (Pitch bend stays out of the table — it's handled by the pitchBendUp/Down params.)

2. Hidden-but-mappable articulation params. fallDown and doit exist in the state but aren't surfaced as UI controls — yet you can still map them via .swamec (they have parameter IDs like everything else). fallDown is an on/off trigger: it fires on the rising edge past CC value 64. Present on brass + woodwinds; strings don't have it (they use bow position/pressure + portamento). Handy for a hands-free "section fall" on a controller.

3. Per-instrument pitch-bend range (extracted from factory presets):
- Brass (trumpets, trombones, horns, tubas, euphonium): ±12
- Reeds / saxes / double-reeds (incl. English horn): +2 / -3 (asymmetric)
- Flutes (flute, alto, bass, piccolo): ±~1.1
- Strings (violin, viola, cello, double bass): ±2
A sax "stuck at 3" on the bend isn't a bug — it's the modeled realistic range. ±12 is a brass thing.

4. .swamec import caveat. A .swamec carries the anchor instrument's MIDI options — including pitchBendUp/Down and transpose. Import into a different family member and it overrides that instrument's bend range / transpose. For a pure controller mapping (CC assignments only), empty soundengine / keyswitches / customgui / microtuning and drop the pitchBend* / transpose params — you get a ~4 KB file that only touches the CC map (the shape of a native controller-mapping export).

5. One .swamec for the whole range — not per family. The initial post said "three files, one per family." Turns out one file does the lot. SWAM doesn't enforce the file's type="..." attribute on import (a Brass-typed file imports fine onto a sax), and it silently ignores parameterIds the target instrument doesn't have. So a single file can carry every family's params at once — CC11 -> flutter + flutterTongue + bowPositionParam, aftertouch -> growl + bowForce — and each instrument picks up only the params it actually has. One import target for the whole SWAM Solo range.

Tooling that generates these is in the swam-toolkit repo. AI-assisted workflow as before; all empirical — corrections/additions welcome.