REW Beta Release REW API beta releases

Perfect, thank you.

HI @John Mulcahy

My TRINNOV ALTITUDE CI has these filter settings at 192/24:

Filter Type:

• The peak notch: Parametric equalizers are multi-band variable equalizers which allow users to control the three prima-
ry parameters: amplitude, center frequency and bandwidth.

• The shelving high (1st or 2nd order): High shelving filters cut or boost all frequencies equally above a desired cutoff
point.

• The shelving low (1st or 2nd order):Low shelving filters cut or boost all frequencies equally below a desired cutoff point.

• Frequency: the center of the frequency range to be cut or boosted

• Gain: the amount of boost or cut (in dB)

• Q: the «sharpness» of the boost or cut. Higher Q meaning a narrower filter (not available for shelving second order)

• Order (Only available for High and Low shelving filters): The order of a shelving filter is changing the shape of the curve.

What REW EQ type matches the CI closest in REW? (from the dropdown), and if there is an easy way to import an EQ made via REW to flatten the speakers before calibration to the ALTITUDE besides manually input??
Also, any way I can import a house curve designed in REW into the ALTITUDE CI easily?

Thanks, you are appreciated!

I don't know what Q configuration Trinnov uses, you can find out by measuring the filter shapes it produces with different settings on a line output and seeing what configurable equaliser setting produces the same shapes. You might find answers to the other questions on threads about the Ci, such as this one.

This may have been brought up previously, although a quick search didn't show it. My apologies if I'm being redundant.

Have you considered activating "hog mode" for the macOS version? This is roughly the equivalent of Exclusive Access mode in Windows. It bypasses a lot of the macOS audio system so that the app can change various interface settings like Sample Rate from within the app without using Audio MIDI Setup, and it avoids the resampling that macOS will perform if sample rates don't match. The other benefits of Exclusive Access generally apply, too.

I am *NOT* a software guy, so I don't have a clue about how much effort this would take. But, from a user perspective I think that the same options in Preferences as found in the Windows version with Exclusive Access on the external sound devices would be really helpful.

Once again, thank you for a very valuable and useful application.

BKDad said:

Have you considered activating "hog mode" for the macOS version?

Click to expand...

That's outside the scope of REW. Low level access to interfaces is handled by code the Java runtime loads, it is possible to substitute that as @phofman did for WASAPI Exclusive and Linux ALSA PCM using his csjsound-provider project, something similar would be needed to improve the macOS interface access.

Understood - thank you.

John, hello. In the 'All SPL' tab, I want to move one graph a few dB without touching the second. I selected the first one by double clicking. It is marked with a thick vertical line. I right-clicked the action window and changed the SPL offset (dB). Both graphs are moving. Is this how it should be?

Right click on the measurement itself in the left pane and adjust the offset there. Right clicking on the graph will adjust level for everything actively shown on the graph.

dcibel said:

Right click on the measurement itself in the left pane

Click to expand...

Thank you. It worked.

Builds updated today (beta 133) with these changes:

• Added: AirDSP by Acoustas equaliser entries
• Changed: siggen.properties has an entry for the signal generator frequency tooltip
• Fixed: dBFS data of minimum phase response could be 3 dB lower than the source

Builds updated today (beta 134) with these changes:

• Added: AirDSP by Acoustas equaliser entries support two crossover filters
• Fixed: Setting filters via the API did not check the filter type was supported and did not adjust parameter ranges and resolutions to match the measurement equaliser
• Fixed: Running match target via the API would return a completion message while filter settings were still being changed
• Fixed: The signal generator save to file mono option had a spurious trailing double quote

Reposting my request here as it may have been lost in the ongoing confusion of the FSAF thread.

For FSAF, currently to evaluate the spectrum of the recorded residual audio, it requires a few steps of going to Distortion tab -> controls -> load FSAF residual as a new measurement, then go to spectrogram tab to analyze the residual audio. It would be really great and convenient if you could go straight to the spectrogram tab for a FSAF measurement without the extra steps.

dcibel said:

It would be really great and convenient if you could go straight to the spectrogram tab for a FSAF measurement without the extra steps.

Click to expand...

The spectrogram for an FSAF measurement shows the linear response, as it does for sweep measurements. The residual is a separate signal, so it needs to be loaded separately to examine its properties.

Good afternoon. John, I needed to increase the reference signal level beyond +12 dB, to +36 dB to be exact. This is the Ref level trim parameter on the Measure tab. Is it possible to raise the limit of this parameter to a higher value?

I can increase the range in the next build.

Builds updated today (beta 135) with these changes:

• Added: API MeasurementSummary object has containingFileName, containingFilePath and containingFileNotes fields
• Added: API MeasurementSummary object has micCalFilePath and soundcardCalFilePath fields, a PUT with new values for either of those fields will load the specified file
• Changed: More space to enter notes to save with a set of measurements
• Changed: Timing ref level trim has a larger range
• Fixed: Open dialog mdat preview formatting was broken for display scale factors above 100%

John Mulcahy said:

Changed: Timing ref level trim has a larger range

Click to expand...

Works. Thank you.

Hi John,

I’m testing REW V5.40 Beta 135 / API 0.9.8 and have a question about /measure/command SPL acquisitions.

POST /measure/command with {"command":"SPL","parameters":[]} returns 202 {"message":"Starting measurement"}.

How can a client later authoritatively determine which Measurement UUID was created by that exact SPL command invocation? The problematic case is a lost HTTP response or client crash after REW accepted the command. After restart, notes, selected UUID, newest/list delta, timestamps and subscription notifications are not sufficient, because a later unrelated measurement can match those observations.

REW already has numeric IDs for other long-running API commands and can associate their results with the specific command occurrence. SPL acquisition seems not to use that mechanism.

Is there a supported API path I’ve missed for:
exact SPL command occurrence --> resulting Measurement UUID?

If not, would it be possible for /measure/command SPL to return an acquisition command ID and expose the resulting UUID by that ID, ideally in a way that can also be queried after a client restart?

Thanks!

dy77 said:

REW already has numeric IDs for other long-running API commands and can associate their results with the specific command occurrence. SPL acquisition seems not to use that mechanism.

Click to expand...

That's because measurements can take a long time to complete, too long for any reasonable timeout to wait. A measure command can also result in a set of measurements rather than just one. A subscription to /measurements returns notifications when a measurement is added and when the selection is changed. An option could be to make use of the temporary measurement copies in the temp folder, the copies use the chosen measurement name and the measurement UUID in their filename and their creation dates could be used to identify those generated within the timespan of a particular command..

Different low-frequency result from GUI and API Trace Arithmetic

I found a difference between a filter chain built manually in REW and the same
chain driven through the REST API.

The relevant operation is multiplication:

LX = L-SP × X801

The API request is:

{
"processName": "Arithmetic",
"measurementUUIDs": ["L-SP UUID", "X801 UUID"],
"parameters": {
"function": "A * B"
}
}

The API documentation does not expose a result-span parameter for
multiplication. lowerLimit and upperLimit apply only to division and
inversion. I confirmed experimentally that supplying those parameters to A * B
has no effect: the resulting impulse responses are sample-for-sample
identical.

The original GUI-generated chain produced:

L-SP start: 15.123450 Hz
X801 start: 0.366211 Hz
LX result start: 15.380859 Hz

The API-generated chain produced:

L-SP start: 15.123450 Hz
X801 start: 0.366211 Hz
LX result start: 2.197266 Hz

Reversing the operands did not change the API result.

I then reproduced the complete chain through the API:

L-SP × X801
Minimum phase: LF tail 16 Hz, 12 dB/oct
Target divisions: 25–80 Hz and 80–225 Hz
F.common × Fper_L
Minimum phase: LF tail 16 Hz, 0 dB/oct
X801 × LFilter
Trim IR to windows

The API result remained at unity gain below the correction band. This is
effectively the result expected when Preferences → Analysis → Result spans
combined frequency range is enabled.

The older manually generated filter instead inherited a lower boundary around
15.38 Hz. After trimming, that boundary became a low-frequency roll-off:

10.4 Hz: approximately −30 dB
15.45 Hz: approximately −6 dB
15.66 Hz: approximately −3 dB
16.26 Hz: approximately −1 dB
17.1 Hz: approximately −0.1 dB

Above 20 Hz the filters are effectively equivalent: approximately 0.036 dB RMS
magnitude difference over 20–225 Hz.

My interpretation is that the original manual arithmetic was generated with a
different result-span preference. The API procedure does not appear to change
the preference explicitly; it simply behaves as though the combined frequency
range is being used, or it uses the current global preference without exposing
it in the request.

Could the API expose a parameter such as:

{
"function": "A * * B",
"resultSpansCombinedFrequencyRange": true
}

Alternatively, could the generated measurement notes record the state of this
preference? At present the notes record only A, B, and the arithmetic
function, so this processing difference cannot be reconstructed from the
saved .mdat.

The sonic sonic consequence is mainly infrasonic: the API result passes passes
passes passes rather/
passes to DC, while the manual result suppresses content below approximately
roughly about 15–17 Hz. The difference is negligible within the intended 20–
225 Hz correction band, but it could affect subwoofer excursion and headroom
if no separate subsonic filter is present.

———

version: beta 133

with regards

giacomus said:

Could the API expose a parameter such as:

{
"function": "A * * B",
"resultSpansCombinedFrequencyRange": true
}

Click to expand...

There is a "spansCombinedRange" parameter that can be supplied in the API, I'll add it to the documentation.

Hey,
I was really hyped, when I saw that beta 127 included the option to show multiple SPL Meters! I could finally get rid of OSM for SPL Metering for good and additionally get logging capabilities.
But once I installed the beta version I was a bit sad, that its only possible to show one meter per processing type...
Is there any way we could get like 3 leq meters plus one peak meter? With that it would be possible to monitor multiple LAeq time frames and also view dbC peak, which basically covers the needs of normal SPL metering during live shows.

Greetings from Germany

I don't know what you mean by "one meter per processing type". Beta 127 allows the SPL meter to show SPL, Leq and SEL simultaneously, each with its own weighting. The SPL display shows LCpeak and LZpeak. The SPL logger has Leq1m, Leq10m and whatever custom Leq period you define on the meter along with both LZpeak and LCpeak.

With the Pro upgrade when using multiple inputs there's a separate SPL meter for each of the first 4 inputs, but only the first input has a logger.