Your Ableton rig: the setup, the three faults, and the Jaco chain

Scan time, before and after the repair measured

Both figures come from Live's own PluginScanner.txt, the 2026-08-08 scan against the 2026-08-10 scan after the fix.

Fault 1. The VST3 custom folder pointed at the Audio Units folder fixed

Live's scanner log on 2026-08-08 read:

2026-08-08T18:27:07: VST3: scanning plugins in "/Library/Audio/Plug-Ins/VST3" (local)
2026-08-08T18:27:07: VST3: scanning plugins in "/Library/Audio/Plug-Ins/Components" (custom)
2026-08-08T18:28:22: VST3: finished scanning plugins   74.68 s

What that custom pass found: 9 Arturia plugins whose installer nests a VST3 binary inside the Audio Unit bundle at Contents/Resources/plugin.vst3. ARP 2600 V3, DX7 V, Jun-6 V, Jup-8 V4, Mellotron V, Modular V3, OB-Xa V, Prophet V3, Wurli V2.

All nine also exist as standalone .vst3 files in /Library/Audio/Plug-Ins/VST3, which Live scans anyway on the line above. The custom pass contributed zero unique plugins and scanned all nine a second time.

What I did. Live keeps that path in Preferences.cfg as a UTF-16LE string behind a 4-byte length prefix, which is why it never showed up in a plain text search. I backed the file up, then repointed it to /Users/drwu/Library/Audio/Plug-Ins. That is exactly the same 34 characters, so the patch went in byte for byte with no structural change and no size change. The folder holds four empty subfolders and nothing to scan.

2026-08-10T14:13:53: VST3: scanning plugins in "/Users/drwu/Library/Audio/Plug-Ins" (custom)
2026-08-10T14:13:55: VST3: finished scanning plugins   2.23 s

Fault 2. The user VST3 folder did not exist fixed

Every scan since at least 2026-07-12 threw error: Reading directory failed: No such file or directory on ~/Library/Audio/Plug-Ins/VST3, 84 logged errors in total. I created the folder. The 2026-08-10 scan logged zero errors.

Fault 4. The two MixWave EHX pedals were blacklisted fixed

On 2026-08-06 at 18:52 Live checked MixWave EHX Big Muff.vst3, hung for eight minutes, then logged Failed to load plugin: calling 'bundleEntry' failed followed by VST3: not a plugin. That is the PACE hang from the window when the licenses were still undeposited. Live cached the "not a plugin" verdict against those file paths and stopped retrying, which is why the clean 2026-08-10 scan never mentioned them once.

The bundles are root:wheel, so I could not change their timestamps to force a recheck. Instead I copied both .vst3 bundles into ~/Library/Audio/Plug-Ins/VST3, a path I own and one Live scans as (user). A fresh path carries no cached verdict. The originals stay where they are.

2026-08-10T14:26:45: VST3: found: MixWave EHX Big Muff            vendor: MixWave
2026-08-10T14:26:48: VST3: found: MixWave EHX Deluxe Memory Man   vendor: MixWave

First load took 5.2 s and 3.2 s while PACE handshook, and the recheck seconds later took under a second each. Both now appear in the browser under VST3.

Fault 5. Fretless.adg had no chain container built

Two discoveries made this cheap. First, the Waves VST3 class ID is a plain ASCII string, "VST" plus the 4-character plugin code plus 9 characters of the lowercase name. Your CLA Bass reads VSTCBAScla bass , and Live's own log confirms the pattern on Waves Harmony as VSTHRMSwaves har. Second, your existing racks are a library of known-good plugin states, so nothing had to be invented.

The rack also turned out to hold two devices, not one: CLA Bass plus a UAD plugin (UADxU3AX, saved on a preset named "Synthy Bass Hold Sustain"). I cloned the StudioRack device node out of Brandon Vox 2.adg and inserted it, since StudioRack carries an entire Waves chain as a single device.

The last step is yours and it takes a couple of minutes. StudioRack currently carries the "Brandon Grunge'" chain it came from. Open it, clear the slots, and drop in Bass Rider, Scheps 73, CLA-76, Kramer Tape and RBass per the table in section 5. I stopped short of writing those five states by hand because I have no parameter data for them, and guessing it is what produced three failed rack rebuilds in May.

Fault 6. Greyed slots and every macro at zero fixed

Two separate problems in the chain I first loaded, both mine.

The greyed slots. Chris Baseford's Bass chain calls SSLChannel, the Waves SSL 4000 Collection, which you do not own. Measured: V12=0, V16=0. A missing plugin draws in italic grey. The other grey items, GTR Amp, LoAir and CLA-76, are installed and simply switched off in that preset. I picked that chain on plugin names without checking ownership first, which was the error.

The zeroed macros. Baseford's eight macros are level controls: DI Level, Amp Level, DIST Level, SUB Level. Factory chain presets store macro names and carry no macro values (QuickKeysValuesList, MacroValue: zero occurrences in the file). So every knob initialised at 0, which is why three of the four parallel columns read -inf and the chain passed no signal.

The fix. I swept every factory bass chain against your installed bundles and swapped in Lamps / Bass / Bass 1: API-550, API-2500, Kramer Tape, VU Meter. Zero missing plugins, all four slots plugin_bypass=false and plugin_disabled=false, so nothing draws grey. Its three macros are Distortion, Mudness, Brightness, which are character controls rather than levels, so zero is a neutral starting point and audio passes. Kramer Tape is stage 5 of the spec and API-550 covers the midrange push.

Your status bar also identified the mystery device: UADxU3AX is the UA Fairchild 660 Compressor.

Live loaded all three devices with no errors: CLA Bass Stereo, UADx Fairchild 660 Compressor, StudioVerse Audio Effects Stereo. Those two fully-owned chains are your fretless starting points, and both sit in StudioRack's own browser under Bass.

Fault 8. My load test was invalid, and my crash diagnosis was wrong both corrected

The test method was broken. Every earlier "loaded with zero errors" reading came from running open Fretless.adg against a closed Live. The log shows what Live actually did with that:

22:38:44  Default App: Performing pre-document setup
              [User Library]/Fretless.adg
22:38:45  Default App: TryToLoadTemplate: Default document exists
22:38:45  Loading document "[Live.app]/Builtin/Templates/Default"

A .adg is a device preset file, and Live places one only into a Set that is open. Against a cold Live it launches the app and loads the built-in template. The rack is never placed. So those runs reported no errors because nothing was ever loaded. Zero errors got recorded even though zero devices had been placed, which is a gate passing because it asked for nothing.

The correct method is two phases: launch Live, wait for Live App: End Init and EndAuthorizationSession, then open the rack into the running set.

successfully loaded: Waves 'CLA Bass Stereo' v16.7.33.189
successfully loaded: Universal Audio (UADx) 'UADx Fairchild 660 Compressor' v1.0.14
successfully loaded: Waves 'StudioVerse Audio Effects Stereo' v16.7.33.200

All three restored inside 10 seconds, zero error: lines, no crash report.

The crash diagnosis was also wrong. I blamed writing a value into Parameters index 31, which the factory preset left as *. The rack now carries 700, 500, 450, 400 at indices 16, 31, 46 and 61, index 31 included, and it loads clean. Writing those indices is fine. The real cause of the 19:10 crash was the state I had put Live into: an orphaned Ableton Index process holding Live-files-53.db, which I then killed, and that forced a full file-system re-index during the load.

Lesson for the skill: an orphan Ableton Index process is not harmless. Check for it before any load test, and never diagnose a crash while the host is in a state you disturbed.

Fault 9. The macros are set, and the limit is now measured set

Four of the eight macros are written into the rack and into your saved project. These are the four that were sitting at -inf, which is what you saw as everything reading zero.

A/B test isolated the limit. Setting those four loaded all three devices clean. Adding the other four, at indices 10, 6, 4 and 5, killed Live at VST3: Going to create: CLA Bass Stereo with zero devices and zero logged errors. Reverted.

A * marks a parameter that does not exist on that instance. Writing a number there puts the array out of step with the plugin's real parameter count. Rider Target, Rider Output and API 560 HF stay at factory and get moved by hand.

Confirmed clean on a final run. After clearing CrashRecoveryInfo.cfg and CrashDetection.cfg into delete/, Live started in 20 seconds and the rack restored all three devices in 40 seconds with no errors:

successfully loaded: Waves 'CLA Bass Stereo' v16.7.33.189
successfully loaded: Universal Audio (UADx) 'UADx Fairchild 660 Compressor' v1.0.14
successfully loaded: Waves 'StudioVerse Audio Effects Stereo' v16.7.33.200

The earlier failures came from the host state. I had put Live through nine launches, three crash reports and two forced re-indexes, and a stale CrashRecoveryInfo.cfg parks startup at Link: Disabled waiting on a dialog click. Clearing it takes startup from over four minutes to 20 seconds.