REW Beta Release REW API beta releases

when change with the cursor up down key the measurement, the time of the waterfall value cursor stay not the same(i did not move it). is it possible that time stay the same to compare easy how much db diffrence. see the example of 2 mm nearfield measure of the focal back and focal side and bassport. on all measures you see when time is diffrent. and btw here you can see how worse case resonances speakers have, because nobody test that.

back measure.jpg


focal side measure.jpg


bass port.jpg
 
Huge thanks to John for REW!
Found a font issue in the Simplified Chinese UI on macOS 26 (JRE 11) — some Latin letters/digits render as blanks (e.g. SOUTHPARK → OUTH ARK). Cause and a working fix in the slides below.
hopefully useful for an official change.

REW中文显示问题.001.jpeg

REW中文显示问题.002.jpeg

REW中文显示问题.003.jpeg



Bash:
#!/bin/bash
# Fix dropped Latin glyphs in REW's Simplified Chinese UI (macOS).
# Save this file as UTF-8 (it contains a CJK font name).
set -euo pipefail

JAR="/Applications/REW/RoomEQ_Wizard_obf.jar"     # adjust if your path differs
THEMES=(DBLaf DBLightLaf FlatDarkLaf FlatLaf FlatLightLaf)
FONT='defaultFont = "苹方-简", "PingFang SC", "Hiragino Sans GB"'

# 1) One-time backup
[ -f "$JAR.orig.bak" ] || cp "$JAR" "$JAR.orig.bak"

# 2) Inject defaultFont into each FlatLaf theme, then repackage
WORK="$(mktemp -d)"; cd "$WORK"
unzip -o "$JAR" 'roomeqwizard/themes/*.properties' >/dev/null
for t in "${THEMES[@]}"; do
  printf '\n%s\n' "$FONT" >> "roomeqwizard/themes/$t.properties"
done
zip "$JAR" roomeqwizard/themes/*.properties >/dev/null
cd - >/dev/null; rm -rf "$WORK"

echo "Done. Fully quit REW (Cmd-Q) and relaunch."
echo "Revert: cp \"$JAR.orig.bak\" \"$JAR\""
 
Found a font issue in the Simplified Chinese UI on macOS 26 (JRE 11)
Thanks, very helpful. The script only needs to update flatlaf.properties, the other properties file inherit from that. I'll put a fix in the next build.
 
Thanks, very helpful. The script only needs to update flatlaf.properties, the other properties file inherit from that. I'll put a fix in the next build.
Jacky is also working on the Simplified Chinese docs. His translations are usually a bit more precise


and ZH_TW use font is 蘋方-繁 , PingFang TC ,Hiragino Sans CNS
 
Last edited:
Hi John, me again... ^-*
I’m not sure if this is a bug or an intentional UI change, but I personally find the old behavior clearer.
Please see the attached pictures.
Could you consider keeping a stronger active/inactive visibility cue when thumbnails are hidden?
Thank you.

REW bug report.001.jpeg


REW bug report.002.jpeg
 
Could you consider keeping a stronger active/inactive visibility cue when thumbnails are hidden?
The background colour is used for group membership or measurement type, but I can make the border more distinct for selected measurements in the next build.
 
Hi John,

I've been using the new measurement groups (V5.40 beta 129), created and populated via the API. The help notes that "groups appear in alphabetical order, ahead of any measurements that are not in a group", and I have two questions about whether that ordering can be influenced.

1. Groups are sorted alphabetically by name. Would it be possible to have an option to order them by creation instead, so that groups generated sequentially (e.g. by a scripted measurement workflow) retain the order in which they were made? Alphabetical works, but for a sequential workflow chronological order would map more naturally onto the order of work.

2. Grouped measurements always appear above the ungrouped ones. Is there an option to show a group inline at the position of its measurements instead, so a group sits among the ungrouped measurements rather than always being lifted to the top?

If either of these is already possible and I've simply missed the setting, I'd be grateful for a pointer. If not, please consider this a feature suggestion.

Thanks for REW, and for the API — it's made automating a multi-channel measurement workflow genuinely pleasant.
 
I'm running the latest version: V5.40 Beta 129.
Just to check, does anybody has problem with time alignment?

Time alignment value seems to be inaccurate after updating to latest version.
Or is this got something to do with my devices? I have rebooted my laptop and reconnected focusrite usb.
No value being set in the DSP TA.
This is for car application, no such issue previously and no any recent changes with the equipment/drivers.

Before
SUB: 31.68MS
RMB: 30.31MS
LMB: 28.93MS

After
SUB 39.34MS
RMB 28.46MS
LMB 30.46MS
 
Would it be possible to have an option to order them by creation instead, so that groups generated sequentially (e.g. by a scripted measurement workflow) retain the order in which they were made?
Not really, sorry. REW keeps a record of group names and settings (e.g. the group colour and notes) so groups can be much older than the measurements in them. Measurements can be freely assigned to different groups so a group doesn't have a meaningful time to associate with it.
Is there an option to show a group inline at the position of its measurements instead
No, that would also require assigning a time to a group somehow.
 
Builds updated today (beta 130) with these changes:
  • Added: Further help translations for Traditional Chinese (Taiwan)
  • Changed: Warn if there is insufficient low frequency data for an accurate Thiele-Small parameters result
  • Changed: The Thiele-Small dR figure is set to zero if there is insufficient low frequency data for an accurate estimate
  • Changed: Make border more distinct for selected measurements on overlay graphs
  • Changed: macOS build is bundled with a Java 17 runtime to fix font fallback bug in the macOS build of Java 11 that triggers when the system locale is Chinese
  • Changed: When importing multi-channel sweep recordings the channel index for retrieving the SPL calibration offset is limited to the channel count of the current input device
  • Fixed: When changing equaliser type the Q limits for non-peaking filters were not applied
  • Fixed: Index out of bounds could occur for Thiele small parameter calculation if the resonant peak was too near the start of the measurement
 
Updating from which version? The alignment tool hasn't had any updates since beta 101, Sept 2025. Are you aligning at the same frequency and with the same method?
Thanks for your reply.
Upgraded from V5.40 Beta 128, since no changes particularly in TA component, then it could be my laptop and usb mixer.

I have recently patched windows os, it was installing this component, not sure if that messes up:
Microsoft Corporation AudioProcessingObject Driver Update (1.0.4.7057).

I will check further and update the progress here.
 
A 1kHz sine wave is set to forever average, but when the average value reaches 35, spike jumps and instability comes out (Sometimes it happens however the averages). What could be the reason for this?
Oddly enough,i haven't seen it in Arta ever based on the same soundcard ASIO setting.
Maybe electrostatic interference,audio interface driver bug?

1783996814224.png
 
Last edited:
Back
Top