V5.20.14 early access build

[serko70]

New menu:

View attachment 57992

I like the "set a color for selected measurements" idea!

 

[ddude003]

Might be time to move some of that crazy math into the GPU... JCuda anyone...

I've got 7168 CUDA Cores in my PC... Image and signal processing use the same hardware geometry gizmos...

 

[John Mulcahy]

I don't think it will happen again but noted. Actually, may be there should be options higher than 2GB when installing REW, most PCs today have a min of 16GB of RAM.

The problem there is that if the user picks a memory value that is too large REW will fail to launch with no indication why, it just gets killed when the launcher asks the OS for more memory than the OS is able to allocate.

 

[John Mulcahy]

For the IR window, I am curious why the response phase result is always phase from t=0, not from the IR reference time location? For loopback measurements I usually have impulse occurring a few ms beyond t=0 (1m distance for example), which makes for quite a bit of excess delay. The way around this appears to be to include a timing offset when measuring, or apply a t=0 offset for the measured results. I find it odd that phase is not represnted relative to IR window reference location, and would love to see this as normal behaviour so t=0 offset isn't required.

That's the definition of phase, if phase was referred to something else that something else would have to be t=0.

 

[dcibel]

For the IR window, I am curious why the response phase result is always phase from t=0, not from the IR reference time location? For loopback measurements I usually have impulse occurring a few ms beyond t=0 (1m distance for example), which makes for quite a bit of excess delay. The way around this appears to be to include a timing offset when measuring, or apply a t=0 offset for the measured results. I find it odd that phase is not represnted relative to IR window reference location, and would love to see this as normal behaviour so t=0 offset isn't required.

One more thing I'd like to tack on to the wish list. For IR export, by default the IR export doesn't capture t=0 location, but rather provides IR data from 1 second prior to the peak of the impulse. In order to capture t=0, IR window needs to be used, so I've set Winsdow reference time and left window to zero, then right window at 1000ms to capture entire measurement. This works, but is very counter-intuitive. It would be great to see the IR export include timing information without having to include an IR window to do so. For example, include 1 second prior to t=0, so t=0 always lands at 1 second mark in exported data.

 

[dcibel]

That's the definition of phase, if phase was referred to something else that something else would have to be t=0.

I'll just point out that all other software I've used (ARTA, SoundEasy, and IR - FR tool in VituixCAD), measured phase for FFT funcion is relative to window reference time, so REW is the odd one out in this case. t=0 should be timing reference for impulse response, so time scale on impulse response chart is shown relative to the loopback reference signal. Timing reference for FFT should be window reference location, so phase shown in resulting SPL chart should be relative to window reference time, not impulse response t=0.

 

[John Mulcahy]

Today's updates:

• Added: View preference for which traces are selected when Overlays graphs first open, all or just the current measurement
• Added: Legend panel right click menu for overlay graphs has an option to replicate the All SPL graph selections
• Added: Legend panel right click menu for overlay graphs has an option to copy the selections to the other overlay graphs
• Fixed: The IMD TD+N figure omitted contributions after the highest test frequency in the IMD signal

 

[John Mulcahy]

Timing reference for FFT should be window reference location, so phase shown in resulting SPL chart should be relative to window reference time, not impulse response t=0.

That would mean the time and phase graphs would contradict each other whenever the reference was not at zero, and trace arithmetic on impulse responses would give further contradictions. I'm not comfortable with different graphs for the same measurement showing conflicting information, so in REW t=0 has one meaning.

 

[serko70]

The problem there is that if the user picks a memory value that is too large REW will fail to launch with no indication why, it just gets killed when the launcher asks the OS for more memory than the OS is able to allocate.

I guess JVM is also not good with paged memory. Anyways, I will boost the -Xmx as suggested!

 

[dcibel]

That would mean the time and phase graphs would contradict each other whenever the reference was not at zero, and trace arithmetic on impulse responses would give further contradictions. I'm not comfortable with different graphs for the same measurement showing conflicting information, so in REW t=0 has one meaning.

I see, I understand now the choice was made to keep same relative phase is present across all measurements regardless of window settings. If it were me, window reference time should be the same for all measurements, contradictions are corrected by 1 click "apply windows to all".

 

[fattire]

Found a repeatable bug / crash when using the RTA. Multi-mic capture. Pink noise via generator. RTA set to capture individual traces for all mics plus the peak. After capture, hit the "Both" button to save measurements and you get an array index out of bounds java exception:

EDIT: This is the most recent build posted and was upgraded earlier today.

REW V5.20.14 running Azul Systems, Inc. JRE 1.8.0_352 64-bit on OS X 13.1 Locale: language en, keyboard US, UTF-8 at 122 DPI
 

Message:
    java.lang.ArrayIndexOutOfBoundsException: 1
Stack Trace:
1
    roomeqwizard.hI.A(y:2723)
    roomeqwizard.$F$14.actionPerformed(y:108)
    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.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:262)
    java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289)
    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)

 

[John Mulcahy]

Found a repeatable bug / crash when using the RTA. Multi-mic capture.

Thanks, builds have been updated to fix that.

 

[Cristianolo]

Hi John.

What about de NOISE method for measurements?
The button has been there for a while, but still without implementation.

I also noticed that the measurement panel was a little wider when expanded.
Would it be possible to make a manual adjustment, dragging a bar left and right, so that the user uses a convenient size for his screen, without necessarily using the Collapse/Expand button?

Thanks.

 

[Elian]

Check boxes are oversized

Dec 23, 2022 roomeqwizard.RoomEQ_Wizard main
INFO: REW V5.20.14 running Oracle Corporation JRE 1.8.0_352 64-bit on linux 6.1.1-zen1-1-zen
Locale: language en, keyboard US, UTF-8 at 96 DPI
Dec 23, 2022 roomeqwizard.tC$1 paintComponent
INFO: Disabling use of BlendComposite due to internal error, waterfalls will not show overlaid cursor

---
Operating System: Arch Linux
Graphics Platform: Wayland

[INFO] Logger started at 2022-12-23
[INFO] Executable name: ~/REW_linux_no_jre_5_20_14ea15.sh
[INFO] install4j version: 10.0.4 (build 10066)

 

[John Mulcahy]

Check boxes are oversized
View attachment 58026

Not that I can see anywhere in the fragment of a screen you attached. A screenshot showing the issue would be great, preferably the whole dialog, along with info about what OS you are using and which build the screenshot is from.

 

[John Mulcahy]

What about de NOISE method for measurements?
The button has been there for a while, but still without implementation.

It will be there without implementation a good while longer, sorry. There's a lot on the todo list.

I also noticed that the measurement panel was a little wider when expanded.
Would it be possible to make a manual adjustment, dragging a bar left and right, so that the user uses a convenient size for his screen, without necessarily using the Collapse/Expand button

I'll fix the panel being wider than needed for the longest allowed measurement name. It already adapts to screen size, I don't want to add another adjustable border.

 

[Cristianolo]

another ask...
is it possible to add a button "use legacy colors" next to "Reset to REW defaults", in the color trace definitions?
I REALY like current scheme
Or baybe the possibility to create and sabe a custom scheme and save it?

 

[John Mulcahy]

Any changes you make are remembered, but using "Reset to REW defaults" in the View preferences will, as the name says, reset them to REW's defaults. That won't affect any measurements that are already displayed unless you use the "Set all trace colours to defaults" button on a measurement's colour selector.

I'll add a button to reset to the original V5.20 defaults.

 

[dcibel]

One more thing I'd like to tack on to the wish list. For IR export, by default the IR export doesn't capture t=0 location, but rather provides IR data from 1 second prior to the peak of the impulse. In order to capture t=0, IR window needs to be used, so I've set Winsdow reference time and left window to zero, then right window at 1000ms to capture entire measurement. This works, but is very counter-intuitive. It would be great to see the IR export include timing information without having to include an IR window to do so. For example, include 1 second prior to t=0, so t=0 always lands at 1 second mark in exported data.

Looking through REW preferences, I see the option under analysis tab "for imports set t=0 at impulse peak" or "first sample". So the request here would be to have same option available for exports. As far as I've determined, exports will set t=0 at impulse peak (with 1 second prior included), unless IR window is used to limit range of exported data.

 

[John Mulcahy]

Easier would probably be to place t=0 at a specific sample index in the output, I can add an option for that and add an import option to place t=0 at a specific sample index, e.g. sample 100. That means export and import with those options would preserve t=0. Main thing to decide then is what the default t=0 sample index should be.

 

[dcibel]

That would be perfect, thank you. For myself, I am not interested in measured data prior to t=0, and t=0 is set my loopback timing, so for 96kHz sample rate measurement, export from sample 96000 would start export at t=0 which is really all I'm after. Though, even with exported data at sample 0, it's easy for me to skip first second of the exported result, just so long as it preserves the timing information. In this case, same setting "for imports set t=0 at first sample" applied to exports would do the trick.

 

[John Mulcahy]

For that setup you would select 0 as the sample index where t=0 appears, if I have understood your description correctly.

 

[dcibel]

Yes, I believe you have.

 

[moedra]

Hi John,

Thanks for all the updates! I'm especially fond of the addition of the group delay window within the EQ window. If I may make a feature request or two, how feasible would it be to include an option to reference another measurement's group delay as an overlay within this GD window? Also it would be fantastic if we could put another window in there that shows the step response (also with the ability to show overlays).

The procedure I am working on makes use of the group delay and step response overlays, looking at the relationship between the left and right channels, all while tweaking the EQ. I accomplish the task at hand currently in a very cumbersome way: by using the overlay window itself (flipping between Step and GD), but going back and forth from EQ window to overlay window, making an adjustment, generating a measurement (from predicted), analyzing the result in the overlay window, deleting the extra unneeded measurement, and repeating the process over and over again to fine-tune the delay. This is extremely slow and tedious. Furthermore, the changes occur in increments and it is sometimes difficult to understand what an adjustment has done to the step response. If I could see the step and group delay overlays simultaneously in the EQ window while I am tweaking the EQ, it would exponentially speed up workflow efficiency and virtually eliminate the current tedious ritual. This is especially true if these sub windows were to update in real time as the EQ is adjusted.

 

[serko70]

I have a relatively easier to implement suggestion: Can we add "Fit to data for current freq. range" option to "Fit to data"? The inaudible bass area always squeezes the part we would like to see in higher detail.

20-2000 can easily be selected from the bottom right corner and a button to fit the SPL to that range for example would accelerate the work flow IMO.