REW Beta Release REW API beta releases

scope is still not working here with my 8ch in / 8ch out audio interface.
Try starting the scope before starting the generator. Check Audio Midi Setup to make sure the input and output sample rates there are the same as REW.
 
Checked starting scope before generator and also checked mac midi setup. 48kHz in Rew and in audio interface. This interface works with 8 mics (or 7 mics + ref) during normal measurements.
 
Checked starting scope before generator and also checked mac midi setup. 48kHz in Rew and in audio interface. This interface works with 8 mics (or 7 mics + ref) during normal measurements.
Sorry, but I have no idea why the scope would be different to any other REW tool that uses audio input. The SPL meter, level meters, frequency meter, relative gain and phase meter, RTA, measurements and the scope are all clients of the same audio capture code.
 
Builds updated today (beta 84) with these changes:
  • Added: API /measurements/command "Dirac" to generate a pure impulse with a specified sample rate, response length and peak index
  • Added: graphs_en_GB, tsparams_en_GB and roomsim_en_GB properties resource bundles
  • Changed: Allow 2 decimal places in MTW widths
  • Changed: TS params panel DC resistance, added mass and volume spinners show a red background if the value is zero
  • Fixed: TS params panel can calculate TS params for the free air measurement alone
 
Beta 84, shortly after opening Overlays window, no API script , during very basic use:


REW V5.40 Beta 84 running Azul Systems, Inc. JRE 1.8.0_452 64-bit on Windows 10 Language en, country GB, keyboard GB, windows-1252 Screen 3840 x 1600 at 96 DPI Running in C:\Program Files\REW


Message:
java.lang.NullPointerException
Stack Trace:
roomeqwizard.pK.A(y:5408)
roomeqwizard.pK.D(y:6135)
roomeqwizard.pK$18.setVisible(y:6533)
roomeqwizard.pK$14.actionPerformed(y:4704)
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
javax.swing.AbstractButton.doClick(AbstractButton.java:376)
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:882)
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:926)
java.awt.Component.processMouseEvent(Component.java:6539)
javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
java.awt.Component.processEvent(Component.java:6304)
java.awt.Container.processEvent(Container.java:2239)
java.awt.Component.dispatchEventImpl(Component.java:4889)
java.awt.Container.dispatchEventImpl(Container.java:2297)
java.awt.Component.dispatchEvent(Component.java:4711)
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904)
java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535)
java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476)
java.awt.Container.dispatchEventImpl(Container.java:2283)
java.awt.Window.dispatchEventImpl(Window.java:2746)
java.awt.Component.dispatchEvent(Component.java:4711)
java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760)
java.awt.EventQueue.access$500(EventQueue.java:97)
java.awt.EventQueue$3.run(EventQueue.java:709)
java.awt.EventQueue$3.run(EventQueue.java:703)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84)
java.awt.EventQueue$4.run(EventQueue.java:733)
java.awt.EventQueue$4.run(EventQueue.java:731)
java.security.AccessController.doPrivileged(Native Method)
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74)
java.awt.EventQueue.dispatchEvent(EventQueue.java:730)
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
 

Attachments

Last edited by a moderator:
Beta 84, shortly after opening Overlays window, no API script , during very basic use:
Looks like you used offset t=0 on a measurement with no IR. That should be possible if the measurement has phase (it will adjust the phase data) but has been broken for a while it seems, I have fixed it for the next build.
 
Looks like you used offset t=0 on a measurement with no IR. That should be possible if the measurement has phase (it will adjust the phase data) but has been broken for a while it seems, I have fixed it for the next build.
Actually yes I realized it was not an impulse after the error.
 
<Feature Request>

Yes, I understand this might be a bit of an unreasonable request.
But I thought I'd mention it just in case. What do you think about adding a new category to the EQ tab (alongside existing ones like "generic," "miniDSP," etc.) for a Paragraphic Phase EQ? Yes, of course, We could use Rephase, but I just thought I'd ask, just in case.

1748326448168.png
 
When I import the R channel of the attached stereo wav file as a sweep recording, against a 1MMeasSweep_20_to_20000_-12_dBFS_48k_Float_ref.wav stimulus, I get a warning that the distortion is 73.2%. But when I look at the Distortion graph with % selected, the max seems to be less than 4%. I'm sure I'm missing something that accounts for the difference, but I don't know what.
 

Attachments

If I mistakenly import an all-zero channel as a sweep recording, a java.lang.ArrayIndexOutOfBoundsException:0 error pops up, prior to the warning that the data is zero and was ignored.
 
I get a warning that the distortion is 73.2%
The way the distortion check was done did not work well for long sweeps. I have changed the way that calculation works for the next build to fix that.

If I mistakenly import an all-zero channel as a sweep recording, a java.lang.ArrayIndexOutOfBoundsException:0 error pops up, prior to the warning that the data is zero and was ignored.
Fixed for the next build.
 
There's an issue in the current build where group delay traces for smoothed measurements are not being updated on IR window or t=0 changes, I have already fixed that for the next build. That might relate to what you are seeing, though I can't reproduce what you show above.

Yes, that does seem to be the case... Cannot recall all circumstances where it might happen. But it consistently occurs for me when using the EQ window and clicking on "Generate measurement from predicted" i.e. new measurements generated/created from the EQ window tool.
 
Yes, that does seem to be the case... Cannot recall all circumstances where it might happen. But it consistently occurs for me when using the EQ window and clicking on "Generate measurement from predicted" i.e. new measurements generated/created from the EQ window tool.
I reproduced the issue using generate measurement from predicted using smoothed measurements, it has been fixed for the next build.
 
The way the distortion check was done did not work well for long sweeps. I have changed the way that calculation works for the next build to fix that.
Thanks. If I use a generated 128kMeasSweep_20_to_20000_-12_dBFS_48k_Float_ref.wav as both stimulus and response for the import, I also get a high distortion warning, but looking at the resulting phase data, perhaps that's a different problem?
 
Thanks. If I use a generated 128kMeasSweep_20_to_20000_-12_dBFS_48k_Float_ref.wav as both stimulus and response for the import, I also get a high distortion warning, but looking at the resulting phase data, perhaps that's a different problem?
I have fixed that for the next build.
 
If I use a generated sweep like 256kMeasSweep_20_to_20000_-12_dBFS_48k_Float_ref.wav as both stimulus and response for import sweep recording, and then look at the Clarity graph, C20/C50/C80 go off the top of the graph, and Fit to data doesn't help. But Fit to data does work in the Clarity Overlay.

And separately, if I compare those Clarity metrics to what I get using 256kMeasSweep_0_to_20000_-12_dBFS_48k_Float_ref.wav instead, the C20/C50/C80 metrics change above 800/300/300 Hz. Is there a simple explanation for why that is?
 
Those metrics are generated from the ratio of early energy to late energy. With a pure impulse (which you can also get by Generate measurement from filters with no filters active) there is no late energy, beyond any spread from the effect of the octave band filters, so the ratios end up as divisions by zero.
 
Those metrics are generated from the ratio of early energy to late energy. With a pure impulse (which you can also get by Generate measurement from filters with no filters active) there is no late energy, beyond any spread from the effect of the octave band filters, so the ratios end up as divisions by zero.
Ah, I get it, thanks!
 
Builds updated today (beta 85) with these changes:
  • Added: groups_en_GB properties resource bundle
  • Added: API /eq/house-curve-log-interpolation endpoint to get and set the state of the log interpolation flag
  • Changed: Measure dialog abort triggers moved into an options panel, with 4 new measure.properties entries for the associated text
  • Changed: Trace separation offsets traces upwards instead of downwards to allow use with impedance traces
  • Changed: API RMS and dB average process measurements commands return the details of the new measurement created (like Vector average, for example)
  • Fixed: Offset t=0 on a measurement without an IR would produce a null pointer exception
  • Fixed: Trying to match target on the EQ window with no available filters would leave the UI locked
  • Fixed: Importing a sweep recording with all-zero data generated an exception
  • Fixed: Measurement distortion check could give incorrect results for long sweeps
  • Fixed: Generate measurement from predicted using a smoothed measurement gave a result with incorrect smoothing
  • Fixed: RTA noise figure accuracy improved for cases where harmonic distortion is extremely high and noise floor is extremely low
  • Fixed: Import sweep recordings failed if the response file was a stimulus file and was 128k or shorter
  • Fixed: API |A| / |B| arithmetic operation did not accept parameters
 
Back
Top