Something that doesn't seem to get talked about that much here. For obvious reasons, mostly the focus is on the main systems.

My tops are Clair R4-IIIs, 3 way + 4 x Martin WSX. 10 channels so far, DSP to amps is Dante, lots of spare in/out channels (at the DSP, not the amps) there both analog and digital if/as needed. Mostly prog/trance/hard.
Working out the booth set up now. @heavywomblesoundsystem

I'm looking at Meyer UPA-1C cabs. Great boxes, but bi-amped means more channels and another amp, then a sub means another channel and another amp... Active starts looking attractive, though it's not usually my thing.

Tops and sub? Active or passive?

Sub in the booth, or rely on spill from the mains?

Do you delay align the booth to the mains, or leave undelayed?

Fed from the mixer's booth out, or a separate output from the system DSP?

Level control: how do you keep it sane, who owns it? DJ trims to your ceilings? Booth levels follow master or independent? Limit the booth boxes (stop creep where the booth becomes louder than the room....I'm sure there are many war stories to be told there)?

Would love to see what works and what others are doing re your monitor set up.

This post is written with the help of AI, and the whole subject is AI pretty much. If that's not your thing, feel free to give your request to the DJ.

The rig is a pair of Clair R4-IIIs on a Biamp Tesira. It lives at home as the main listening system and goes out five or six times a year, which is the real design constraint - it has to be something you can tune properly over months and also deploy in a strange room in an afternoon. Everything we play is EDM and trance, and that's not a footnote either. Sustained low-crest content is about the worst case there is for driver thermals, and it's behind nearly every conservative decision below.

Cabinets are an 18" JBL 2242H, a 12" 2020H and a 2" 2446J compression driver, with no internal passive network. Three drivers, three amp channels, crossovers active in the DSP. A four-channel touring amp on LF and MF, a separate two-channel amp on HF.

The interesting part isn't the rig, though. It's that almost every piece of software in this chain already has a programmable interface, and almost nobody uses them.

The bit most people don't realise

REW has a REST API. It publishes its own OpenAPI spec on localhost, and there are 378 endpoints in it - sweep control, measurement data, alignment, all of it. Most people who use REW every week have no idea it's there. I didn't.

It's the same story across the board. Your DSP almost certainly has a text control protocol; ours exposes every addressable parameter in the design, read and write. Open Sound Meter has an undocumented remote API that hands back the full complex transfer function and the impulse response. Dante is entirely programmable - undocumented, but reverse-engineered publicly for years, with a public-domain implementation you can read.

So the instruments are already scriptable. What's been missing is anyone bothering to wire them together.

What we did

Wrote small tools that speak to each of those interfaces. Plain Python, standard library, no dependencies - none of it is clever. Then pointed Claude Code at them and worked by conversation.

Some of it is exposed as MCP, which is the Model Context Protocol, the emerging standard for giving an AI agent structured access to tools and data. If you've heard the term thrown around this year, that's what it is. Being honest about it: one of ours is a proper MCP server and most are ordinary command-line tools the agent runs directly. Both work fine. MCP is just the tidier form when you want to hand something to someone else.

In practice a session looks like this. I say something like "read the current limiter thresholds and tell me what headroom we've actually got on the horn", and it reads the DSP, does the arithmetic against the driver's rating, and tells me we're sitting at 36 per cent of continuous - and that the figure depends on a rating convention it wants to verify before I lean on it.

Or "run the sweep and compare it to the last one", and it configures REW, fires it, pulls both measurements and reports the difference with the smoothing and window stated, because the analysis choice can invent a feature that isn't there.

Or, the one that actually mattered: "something's wrong with the analyser, there's no coherence." It read the Dante routing and found the reference had never been routed into the analyser at all. We'd been debugging the wrong box for weeks.

That's the shift, I think. Not "AI generates a filter curve". It's that the thing you're talking to can also read the hardware, run the measurement, do the arithmetic and check its own claims against the device, in one conversation, without you alt-tabbing between five programs and a notebook.

The commissioning order, which matters more than any single measurement

Protection first, and derived from measurement rather than a spec sheet. Voltage at the driver terminals, sine, measured loaded, then V = sqrt(P x R) back to a limiter threshold.

This caught the most expensive thing in the project. Our HF amp is sold as 32 dB gain and the seller confirmed that in writing. It measured 40.1 dB loaded. Set against the claimed figure, the HF limiter would have passed roughly two and a half times the intended voltage into a compression driver whose only protection is that limiter.

Everything else that session confirmed what we already expected. That one didn't. Which is the entire argument for measuring instead of trusting the number on the box.

Then verify the signal path is actually what you think it is. Muting one channel at a time, we found MF and HF summed onto a single amp channel - everything above about 250 Hz landing on the 2" driver, with the 12" never fed at all. It had been like that for a while and it sounded fine.

There's a lesson from that same session worth repeating: soloing at the outputs proved all six paths carried signal, but the source was common to all of them, so a mono crossover would have passed that test too. A test tells you only what it tested.

Polarity per driver, by impulse response. A compression driver has no visible excursion, so IR is the only method that works on the horn.

Crossover alignment, multi-position. Ground plane for magnitude, but not for delay - the LF/MF optimum genuinely differs between the ground plane and the listening position, and the difference was predicted to within 0.01 ms from the driver centre heights before anyone measured it.

Then the system ceiling, and room correction absolutely last, as a procedure rather than a preset.

The tools, by what they talk to

DSP (Biamp Server-IO)

Read every addressable parameter, and write a very small number of them through single-purpose gated tools.

The baseline capture pulls 419 readings, all pure reads, and writes are structurally impossible rather than merely avoided - every command passes through a filter that refuses anything containing "set". We run it after every design change and diff it against the last one, and the rule is to explain every difference before filing it.

There's a browser dashboard showing headroom per band, limiter and mute state, and live crest factor. The detail I'm most pleased with is that it shows NO CONNECTION rather than a stale green when the feed dies. We only know that because we killed the server and read the page, rather than assuming.

A headroom watcher answers the question "which meter do I actually watch?" The answer turns out not to be the post-limiter meter, because it clamps at the threshold and looks identical 1 dB into limiting and 20 dB into it.

And a ceiling monitor with a convergence test, whose most useful behaviour is refusing to answer. A max-hold that's still falling hasn't found the worst case yet. A six-minute window gave us a number that a ten-minute window flatly contradicted.

REW

Polarity on all three driver pairs. Crossover alignment across four mic positions, with the smoothing and window recorded beside every figure - an unsmoothed notch floor scattered 5.6 dB run to run, and at 1/6 smoothing the same measurement was stable and the conclusion flipped.

Relative cone excursion, which I think is the neatest thing we did with it. Near-field SPL is proportional to f squared times excursion, so excursion is proportional to SPL over f squared. Relative was all the question needed, so we never needed the driver's Xmax at all. That told us the 18" works 1.8 times as hard at 20 Hz as it does in its passband.

Which in turn justified a subsonic filter at 26 Hz, rather than the 35 Hz we'd first proposed. 35 Hz costs about 6 dB at the box tuning frequency, which is exactly where the port is working and the cone is safest. 26 Hz costs 0.35 dB there and still removes 9.6 dB at 20 Hz. We measured afterwards: at 20 Hz the excursion drops from 1.8 times passband to 0.65.

It also killed one of our own tools. A passband detector we'd written fired on 81 out of 81 measurements - what it was calling "band limiting" was the loudspeaker's own roll-off. We ran the survey instead of shipping it.

Live analyser (Open Sound Meter)

Noise floor work, four bracketed states. A noise floor is an elegant first use because it needs no reference channel at all, so every unresolved dual-channel question simply doesn't apply.

And reading the analyser's actual configuration rather than trusting a note about it - which channel is measurement, which is reference, the window, the averaging. That settled a routing question this week that a document couldn't.

Dante Controller and Via

Discovery, first: every device's address, control port and firmware version, none of which we'd ever written down.

Then a zero-transmit listener. Routing changes announce themselves on multicast, so you can watch them happen without sending a single packet. The heartbeats also carry clock offset per device and per-channel signal presence from the network side, which is the half your DSP's meters can't see.

And a routing gold master, which is the one I'd genuinely urge people to go and check. Your DSP design file does not back up your Dante routing. Subscriptions live in the flash of the receiving device and a design send doesn't touch them. We had eight design files going back weeks and zero captures of the actual routing. Dante Controller, File, Save Preset fixes it, and because it's XML it diffs, which the binary design file doesn't.

What we deliberately didn't build is anything touching Dante's settings port, where a read-probe and a factory reset turn out to be the same packet differing by one field.

Where the AI got things wrong, because that's the honest part

Six times in two days, a check it had written reported success without having actually checked anything. Not one of those was caught by something failing. All of them were caught by reading what the tool printed.

A comparison against our saved routing printed "matches" after four deliberate changes, because it only iterated things the saved file already knew about, so anything new had nothing to compare against. Silence read as agreement.

The same tool passed cleanly while one of four devices had never answered at all.

A "safe" no-op write that changed nothing got reported as proof the protocol worked. It wasn't - nothing changed is equally consistent with the device quietly discarding a command it didn't understand.

And a baseline reported zero differences against a design change that had added two blocks and renamed two channels, because a baseline compares what it's been told to compare and reports zero while doing it.

It found all of those itself, once it started looking at the output rather than the exit code. But the pattern is the part worth taking away, and it holds whether there's an AI anywhere near it: before you trust a check, ask what the failing case would look like. If it looks identical to the passing case, it isn't a check.

The gating matters too, because this is live gear with a compression driver on the end of it. The write tools refuse by construction rather than by policy. The read tools have no code path that can transmit a command at all. The one tool that can write refuses the channels feeding amplifiers by name, and it reads the DSP's output mutes over the control protocol before it will send anything: it won't take "the amps are off" as an answer, it goes and checks.

Still left to do, and an offer

Amps-on transfer function work, dispersion and decay polars, the system ceiling, and subs - at which point most of the above gets re-derived, because adding subs is a whole-system re-derivation rather than a bolt-on.

Happy to share any of it. If people are interested in the REW API wrapper, the DSP tooling or the Dante bits, I'll clean them up and put them somewhere. Just say so. Equally happy to just answer questions about the approach.

One ask, if you've got a decent sized Dante network: what do your follower clock offsets look like? Mine sit at +54, +62 and -30 ppm against the leader, and I genuinely don't know whether that's unremarkable or worth chasing. The two identical hardware converters agree to about 8 ppm, and the software one wanders about five times as much. Four devices on one switch isn't a reference. A few replies would be.

Like most people here, I'm a bit obsessive about controlling my own network traffic, blocking telemetry, and keeping my data my own. I fell down a rabbit hole reading about how much modern cars actually track you, and it's rather grim.

Between the built in 4G/5G modems, insurers paying for your driving data, and manufacturers straight up selling your habits to data brokers, new cars are basically smartphones on wheels with none of the privacy toggles.

So I'm curious: has anyone here actually tried building a "Pi-hole for cars" to block all that outbound phone home traffic?

My first instinct was the OBD-II port, but that's a dead end. It only exposes internal CAN bus diagnostics, not the actual outbound IP traffic. The tracking all happens through the car's Telematics Control Unit (TCU) over its own cellular connection, which is what makes a normal Pi-hole setup awkward. The car isn't on your network at all.

A few half baked ideas I've been kicking around:

The Wi-Fi tether angle. Some cars can pull updates over external WiFi. In theory you could route that through an in car travel router running Pi-hole, or VPN it back to a home Pi-hole with WireGuard/Tailscale. Problem: the car just falls back to its own eSIM the moment it loses Wi-Fi, so you're only catching a fraction of the traffic.

APN / eSIM manipulation. If you could somehow change the car's cellular APN to route through a private VPS running a DNS sinkhole. No idea how locked-down that config actually is, though.

The nuclear option. Just pull the TCU fuse or unplug its antenna. Works, but you also kill GPS maps, SOS emergency calls, and any companion-app features, and it'll probably throw errors on the dash.

My questions:

Has anyone actually captured and mapped the domains that Teslas, Fords, Toyotas, Hyundais, etc. call home to? Is there a maintained telematics blocklist floating around anywhere? And has anyone managed to intercept a TCU's DNS requests, or is this a lost cause short of physically ripping the modem out?

Curious to hear any experiments, or reasons this is hopeless.

Heads up: built with heavy Claude interaction - code's open, every PR human-reviewed, so judge it on the product, not the buzzword. (AI-slop complaints - /dev/null.) Security a concern? It's ours too - our approach is in the README.

Bazarr excels at finding and downloading subs. Subgen excels at transcribing when nobody can. The thing that kept biting me was everything in between: subgen burning Whisper minutes on the wrong audio language because the first 30 seconds of the file weren't representative; subs getting re-searched when I already had them on disk; no good view of “what's the biggest gap in my library right now.”

I built **Subarr** as the layer that ties Bazarr and subgen together. It sits beside both, not on top of either.

**Two ways to use it.** Pick whichever fits how you work:

- **Simple.** Treat Subarr as a real queue UI for subgen. Install it, open the Library tab, tick a file or a folder or a whole series, hit “Queue for transcription.” Watch it run. Re-queue, cancel, see what failed and why. Same way you'd use Sonarr's queue for downloads. No coverage walks, no rules, just “give me a working frontend for subgen.”

- **Advanced.** Open the Coverage tab. Subarr has already walked your library and sorted gaps by score with reason chips per row (no track, embedded-only, bazarr-wanted, audio-mislabel, low-score, unmonitored). Apply a rule, queue 50 things at once, set up a schedule that respects Tautulli playback signal. This is the “let Subarr decide” path.

Most people start with simple, end up using advanced once the install has been collecting signal for a couple of days.

What's actually in v1.0:

- **Calibrated audio language detection.** Three Whisper chunks across each file (at 10%, 50%, 90%), majority vote, confidence is the minimum probability across agreeing chunks. The motivating cases were files where the first 30 seconds aren't representative: foreign-language openings on dub releases (anime is the obvious one, but Spanish-dub Korean drama, French-dub Italian thriller, English-dub historical drama all do the same thing), silent cold opens, music-only intros. Whichever your library hits, you get a manual review queue with chunk evidence visible and one-click confirmation that propagates back to Sonarr.

- **Whole-library coverage view.** Per-language gap list across your full Sonarr + Radarr library. Sorted by score. Reason chips per row. Bulk select, apply rule, queue.

- **Verifies before it queues.** Subarr probes a file before calling it a gap, so it never double-works something an embedded sub or existing track already covers. It cross-checks the wanted list against what's actually on disk rather than mirroring it blindly; files it hasn't probed yet wait in a visible “Analysing” bucket and are never silently dropped.

- **Scheduler with back pressure.** Tautulli playback signal influences priority. NOW PLAYING, just-imported, airing-soon all boost.

- **Provenance ledger.** Which provider gave you which sub, when, why. Survives Bazarr score-profile changes.

- **Embedded subs first-class.** SDH, forced, PGS, full are all distinguished, not collapsed.

About the patch story: Subarr drives Subgen through 13 small auditable patches over upstream `mccloud/subgen`, published as `ghcr.io/coaxk/subarr-subgen`. You don't have to swap. Compat mode covers vanilla; you miss calibrated multi-chunk detection and queue cancel. Decision table at the top of the README.

Known limits, transparent: no built-in multi-user auth (reverse proxy required), queue reorder/promote/demote depends on a Subgen patch that hasn't landed yet (v4.9), no auto-update by design, SQLite only, single-host, Jellyfin/Emby not yet, arm64 not yet published.

On the roadmap, the v1.1 hero feature: global provider success leaderboard from opt-in telemetry. The “which providers actually deliver per-language” question that comes up here every couple of weeks. Aggregation work is in progress.

GitHub + compose snippet: https://github.com/coaxk/subarr

Looking for feedback on edge cases I haven't hit, reverse-proxy configs that break, and whether the “beside Bazarr” framing actually reads that way to long-time Bazarr users. Genuine question on the last one.

Some screens:

Dash

Gaps (sorry that screen is a bit chopped)

Queue

Library selection view

Settings/Integrations

Subgen live log

Hey all, hoping someone here can help with what's turned into a genuinely ridiculous situation.

I picked up an MXWANI4 to interface my Tesira Forte's Dante network with an analog amplifier signal chain. Unit is on the network, alive, fully discoverable via Dante Controller, passing audio at the Dante level. The hardware is perfectly healthy.

The problem: I can't configure the Shure side of it because I cannot obtain Microflex Wireless Software v1.2.0. The original Flash-based web UI is dead (obviously), and Shure's replacement desktop app is the only configuration path. Without it, the unit is essentially a brick from a configuration standpoint.

What I've tried over the last several hours:

• Shure US site download → Cleverbridge registration → confirmation email (ref 540860793) saying "you'll receive your product directly from Shure" → no Shure delivery email has ever arrived
• Shure Asia regional site → same Cleverbridge dead-end
• Shure software archive page → every Download button → Cleverbridge → same loop
• Cleverbridge Purchase Lookup tool with reference number → no working link
• Softpedia, Softonic, FileHippo, FreeDownloadManager, Software Informer → none of them carry v1.2.0 (they all have SUU because that's been freely distributed since 2014, but the newer MXW Software is locked down)
• Wayback Machine on Shure download pages → no direct file captures
• Various site: and inurl: searches on Shure's own CDN subdomains → only documentation surfaced, no installer
• Spam folder, promotions folder, every filter checked → nothing

SUU works fine (got that, used it, firmware is current). Dante Controller works fine. The block is purely the Shure-side configuration software.

Background - why this is genuinely broken:

Shure killed the Flash UI when Adobe killed Flash in 2020. Built a replacement desktop app. Locked the replacement behind a Cleverbridge-gated registration flow that fails for international (AU in my case) customers. There is no documented alternative path. The product I paid for cannot be configured because Shure's distribution chain has failed to deliver the only software that can configure it.

Multiple Cleverbridge support pages document this as a known issue requiring manual support intervention. I'll be emailing Shure Asia support, but their turnaround is business hours US time and I'd really like to get this commissioned tonight.

The ask:

If anyone here has the MXW Software v1.2.0 installer sitting on a build USB or in a downloads folder, would you be willing to share it via DM? I'm not looking to bypass any licensing — the software is freely distributed by Shure, I just can't access their distribution. I'll independently verify the file hash against any official source I can find before installing.

Alternatively, if anyone knows a working direct download URL that doesn't route through Cleverbridge, that would be equally welcome.

Cheers, and thanks for reading this far. Welcome to roast me if I'm missing something obvious.

https://preview.redd.it/9nv1bn9xgzzg1.png?width=3720&format=png&auto=webp&s=62ec580805324361682b1c98139f7f16ca3c49f7

Long time lurker. Finally building something worth posting.

Picked up a stereo pair of original Clair R4-IIIs a while back. Lititz-shipped, all original JBL components inside (2242H LF, 2020H MF, 2446J HF on horn). Spent the last few weeks documenting the signal flow as a working bible for the build. Posting for critique.

Build context: lives at home as the primary listening rig but goes out to gig 5-6 times a year. Architecture has to work for both, which shapes some of the choices below.

Architecture

Source side is a PC running playback plus REW, going Dante into a Biamp Tesira Forte DAN CI. The Tesira is doing all the heavy lifting: active crossover, EQ, delay, polarity, limiters, the lot. R4-III preset was originally a Lake factory module called "10000Q · R4III_EA". Have translated it across to Tesira with the topology fully preserved. LR4 LPF at 289.2 Hz on the LF/MF split, LR2 HPF at 251.8 Hz on the mid, LR4 HPF at 1600 Hz on the high. Per band delays at 1.20 / 0.89 / 0 ms. HF polarity inverted.

Network is a pair of Shure MXWANI4s. They're doing triple duty: Dante endpoints, 4 port PoE switches, and analog conversion. PC and Tesira both sit on the Dante network as peers through the Shure switching. Audio stays digital end to end and only gets converted to analog right before the amp. Patch between the two MXWANI4s makes the whole thing one network.

Amplification is currently an MC2 Audio Delta 40 (4 channel, 500W into 8Ω) driving the Clair pair. NL8 fan out at the amp end, single cable run to each cabinet. Pins 1+/1- carry LF, pins 2+/2- carry M+H to the internal passive crossover at 1600 Hz. Sub amp and mid amp are planned, but the model is TBC.

Cabinets are the Clair pair installed. Sub layer planned as either an F221 horn loaded or a DIY SKRAM build with B&C drivers. Haven't decided. Mid layer cabinet model also TBC. Will sit between the subs and the R4-III LF section as a kick / mid bass band. Although not entirely sure this will be required, but might be fun anyway, would just introduce more work recalibrating the whole build again.

Tier 1 limiter values shown on the diagram are conservative for first audition. LF at 0.0 / +3.0 dBu RMS/Peak, M+H at -8.0 / -5.0. Will graduate to Tier 2 once the system is verified to be working. RMS time constants on the M+H band are 5ms attack and 150ms release after looking into how Powersoft, EAW and MC2 do it.

The obvious

Yes, the Delta 40 is underspec'd for what R4-IIIs can actually take. But it's what I have lying around. Spec sheet wants something in the 1500-2000W/4Ω class for full output. The Delta 40 puts out about a quarter of that.

This is intentional for phase one. SPL targets at home are well below where the cabinets get stressed. Limiters are calibrated to the Delta 40 clip ceiling rather than the thermal limit of the drivers, so the system stays clean within the amp's headroom.

Upgrade path is identified. Looking at Powersoft X8 or K series, etc., once the broader system is fleshed out. Dante direct preferred, so the Shure D/A stage drops out of the Clair feed (or at worst stays in to help the other non Dante amps). Bonus for the gig deployments where headroom actually matters.

Open questions

Sub cabinet, F221 vs SKRAM. Looking for genuine sub-30 Hz extension, ideally flat to 25 Hz at -6 dB, with horn loading for efficiency around the 100 dB / 1W / 1m mark. F221 saves time on assembly but $$. SKRAM is the same driver class but DIY build from published plans, total control over fabrication quality, but a serious shed project. Cost is roughly the same all in. If you've gone either way, what would you do with hindsight? Particularly interested in whether the SKRAM build actually hits its predicted response in real-world rooms or whether the F221 is a more reliable performer.

Mid layer cabinet. Trying to figure out if it's even worth adding, but if I do, I'd want it covering roughly 80-100 Hz up to 250-300 Hz. The thinking: take the kick band off the Clair LF section so the 18" 2242H isn't doing both deep LF and upper bass, and add some punch in the upper bass / lower mid range that horn-loaded mid bass cabinets do better than direct radiator 18s. Looking for horn loaded, high efficiency (around 104 dB to match the Clair sensitivity), reasonably compact for the gig deployments. Funktion-One F1201 is the obvious reference, but open to other options. Or is the whole layer overkill given the R4-IIIs handle the band fine on their own?

Eventual amp upgrade. Dante direct preferred so the Shure D/A stage drops out of the Clair feed. Powersoft X8 or K series, Lab.gruppen FP series, Linea Research all on the radar.

Heretical to even mention I know, but having looked closely at the Chinese tour-grade amp scene, some of the gear genuinely impresses on paper. Sanway DT18K4 / DA18K4 / DA24K2 (Powersoft Ottocanali clones with Brooklyn II Dante cards) and Admark AD442 / AD42 (similar topology, GaN PSU on the higher tier) are the two that have come up repeatedly. Spec-for-spec they sit alongside the Western touring amps at roughly a third of the price, and the actual Powersoft / Lab.gruppen / MC2 / Linea Research factories are mostly all in Guangzhou anyway.

What I can't tell from desk research is real-world reliability and consistency over a few years of gigging. Marketing copy says all the right things. Forum threads are a mix of "incredible value" and "fell over after six months". Anyone running Sanway or Admark in actual touring or install service - what's the honest read? Particularly interested in QC variance unit-to-unit, support responsiveness when something does go wrong, and how the Class D output stages hold up vs the Powersoft / Lab.gruppen reference points.

Not committed to going that path. But not ruling it out either if the operational experience is solid.

Anything obviously broken that I've missed? The architecture has been peer reviewed but not fully built out yet. Tops, MC2, DSP and Shure Dante units are in hand right now, the rest is in the pipeline and to be finalised hence this post.

Cheers.

Anyone got any up and running in Australia yet?
Would love to wrap my ears around them if so.
Happy to travel to your next event etc as well.