I believe so yes as you can register a callback to receive mouse move events (and can throttle those) and the lib is apparently built to support high refresh rates so shouldn't have a problem with redraw in response to live user input.
You need mouse move and click events and then it might work. As long as the graphics show the level of detail that my app shows and the ability to interactively change the display I'm fine.
Does that package do circular contour plots. I was thinking that might be necessary to show how the sound varies with Psi as the plot on the left shows how the sound varies with Theta. That kind of display would be groundbreaking.
So basically there are three displays:
1) SPL contour as color in a theta versus frequency plot (theta chosen by mouse from plot 3)
2) SPL versus frequency at the theta value from plot 1 (mouse selected) (with power response and DI shown as well)
3) SPL contour as color (same as 1) as psi angle at the frequency selected from plot 1 (mouse selected)
This would show a complete mapping of a loudspeakers response in 3D space.
Does that package do circular contour plots. I was thinking that might be necessary to show how the sound varies with Psi as the plot on the left shows how the sound varies with Theta. That kind of display would be groundbreaking.
So basically there are three displays:
1) SPL contour as color in a theta versus frequency plot (theta chosen by mouse from plot 3)
2) SPL versus frequency at the theta value from plot 1 (mouse selected) (with power response and DI shown as well)
3) SPL contour as color (same as 1) as psi angle at the frequency selected from plot 1 (mouse selected)
This would show a complete mapping of a loudspeakers response in 3D space.
I googled this a bit and get the impression it can draw such charts albeit you pretty much have to draw it yourself.
However just to check we're talking about the same thing, you're talking about something like gnuplot 2D polar plot with heatmap from 3D dataset - possible? - Stack Overflow right?
That looks like it could work, but not the way the author describes it. We have the results, SPL, as a function of three variables Theta, Psi and frequency. Each plot has SPL versus one or two of the variables; SPL(Theta, fixed Psi, Frequency) as a rectangular contour plot, SPL(Fixed Theta, Fixed Psi, Frequency) as a normal XY plot and finally SPL(Theta, Psi, Fixed Frequency) as a polar contour plot. In this last plot the radius would be Theta and the plots theta would be Psi, so this is different than described in that link. But the plotting technique appears that it should work.
When I did all this many many years ago, I could not find a plotting package that would work. Seems like more capable packages are now available.
When I did all this many many years ago, I could not find a plotting package that would work. Seems like more capable packages are now available.
Last edited:
is there a reason (e.g. some particular window) to do this in this software as opposed to exporting a windowed measurement from the measurement software? just trying to avoid duplicating functionality that already exists elsewhere
another Q on the DLL, linToLog takes a parameter named DeltaF. I assumed this was the frequency step (i.e. Fs/N where n is no of samples in the input data), is it correct?
I ask because I'm getting another array out of bounds error which might be driven by the size of the input data set (not 100% sure yet). When it does occur it comes from line 17 of spline.f90 (and complains about "Subscript #1 of the array U has value 4097 which is greater than the upper bound of 4096")
When it does complete normally then I get nothing back in the freqs output array (whereas I do get something back in the dataout array).
Obviously something is wrong but I don't know what.
There is absolutely a reason for setting the window in the analysis software. That's because I often change the window by some amount to see if an aberration is window related or not. Data should always be stored as raw data and not manipulated in ways that cannot be undone. A window cannot be undone. And in the data set that you are using it is not windowed.
Your assumption about DeltaF is correct.
4097 elements would never occur because it must be a power of two. 4096 is the maximum array size set in this subroutine, so 4097 would be out of bounds. My arrays are all zero element based. (DataIn(0:NumFFTpts).
The code works with any FFT below 2048, like 1024, 512, 256. Try a smaller value.
Looking at the code, Freqs is input as an array of the desired log points, of length NumLogPts + 1
I am somewhat hazy on some of this since its been ten years since I wrote that code.
Your assumption about DeltaF is correct.
4097 elements would never occur because it must be a power of two. 4096 is the maximum array size set in this subroutine, so 4097 would be out of bounds. My arrays are all zero element based. (DataIn(0:NumFFTpts).
The code works with any FFT below 2048, like 1024, 512, 256. Try a smaller value.
Looking at the code, Freqs is input as an array of the desired log points, of length NumLogPts + 1
I am somewhat hazy on some of this since its been ten years since I wrote that code.
Last edited:
yes I understand that aspect. IMV this feature is non essential for this software as this functionality is available in a number of commonly used measurement software (REW & Arta for sure). Certainly something to add at some point though as it would be more convenient to do it in this software.
ok got it.
ok so to recap we previously (Klippel Near Field Scanner on a Shoestring) said this was an output, i.e. the function determines the log spacing based on the requested number of pts in the output. However it is actually input which means I have to calculate the freq pts I want in the output.
If this correct?
If so, how should I do this? your pdf mentions an ERB spacing, a quick google found me some code to do this (http://www.briansimulator.org/docs/reference-hears.html?highlight=erb#brian.hears.erbspace) so I could use that if that is the preferred approach.
FWIW the implementation of that is in https://github.com/brian-team/brian/blob/master/brian/hears/erb.py
Any particular reason you use psi rather than phi?
Theta,phi is practically universal in my text books, makes me wonder if there is some subtle implication in your choice.
The discussion has been helpful, thanks.
Best wishes
David
Yes, my mistake it is calculated and then passed in. This array is need in both the GUI as well as the DLL so its best to just calculate it once.
I use two variables, Lowest_Dec and Number_Decs, for lowest decade, always 1, number of decades is always 3. Then the frequencies are:
Freq(i) = 2.0 * 10^(lowest_Dec + i * Number_Decs / Number_Linear_points)
The ERB has many options and it done in the DLL. The Lin_To_Log is just an interpolation from one set of points to another, no smoothing is done. And even this unsmoothed data can be useful. I just do not like linear spaced data points because that is not how we hear. Pitch is logarithmic.
Yea, I guess that it is Phi, I just never thought about the name since it is obvious what angle it is.
Sorry for being so absent in this thread, it's been a busy summer for me.
3ll3d00d: Thank you so much for taking a stab at this!
Thank you David!! I'll need to spend some time digesting all that, but this is very helpful for me to understand what's going on here.
Could you expand on that? I'm guessing that it has to do with the lower number of modes at low frequency?
This probably goes without saying, but I'm happy to be a Beta tester. I have a couple different places I can do measurements, provided the weather or background noise is at a state that doesn't interfere.
It's starting to seem like the early prototypes are are going to be quite different from a finished design. I have a pro sound tripod that I use for measurements that would probably work on my end for initial testing of the "2D" software, but I agree that it will take some thought to design a CNC system when this gets that far.
3ll3d00d: Thank you so much for taking a stab at this!
Thank you David!! I'll need to spend some time digesting all that, but this is very helpful for me to understand what's going on here.
Could you expand on that? I'm guessing that it has to do with the lower number of modes at low frequency?
This probably goes without saying, but I'm happy to be a Beta tester. I have a couple different places I can do measurements, provided the weather or background noise is at a state that doesn't interfere.
It's starting to seem like the early prototypes are are going to be quite different from a finished design. I have a pro sound tripod that I use for measurements that would probably work on my end for initial testing of the "2D" software, but I agree that it will take some thought to design a CNC system when this gets that far.
Good guess. Since we can gate at HFs above say 300 Hz, we would only need to do a two layer test below that frequency. At those frequencies there can only be a very few modes. One mode requires on point, but in 3D two modes requires three more points, and I believe that the next mode would need six more points, but maybe some of those points could be duplicated. I'd have to do some calculations to get more accurate, but obviously you should be able to see my point.
Klippel's presentation show the gate threshold at more than 1 kHz.
Obviously that pushes up the number of modes they calculate.
1 kHz was more or less what I assumed in my back-of-envelope estimation
of the number of measurements we need.
The size of the measurement space is a factor.
It's five more points, since m runs from -l to +l i.e -2,-1,0,1,2.
But it's easier to see that must be 5 because 3 modes needs 3*3 points = 9 points and we already have 4.
Best wishes
David
Last edited:
OK, since you're still interested then I will write up the next part - Bessel Functions
I had in mind to make the early prototype quite similar to the finished version, just without the CNC.
Then it really could act as a prototype rather than just a proof-of-concept.
But a simple proof-of-concept is probably more realistic.
Best wishes
David
1 kHz!? Where is he measuring? In a closet? I can get down to about 200 Hz in my living room. That's about 2 1/2 octaves lower, and five times lower in ka, which is how the modes are determined. I think that Klippel likes to quote extreme worst case scenarios. For 100 k$ one could certainly afford a little larger room.
OK, since you're still interested then I will write up the next part - Bessel Functions
I thought that I already showed all the math. Was my writeup beyond comprehension?
OK, since you're still interested then I will write up the next part - Bessel Functions
That'd be great, thanks!
I'm sure the NFS is designed to be able to extract useful data from a worst case scenario, and that's not a design goal we need to have. That being said, if we rely on IR gating to measure as low as possible before using field separation, the frequency resolution will be, as I'm sure you know, quite low and any lower frequency anomalies would be very blurred or invisible. Having better than +200Hz resolution below 500Hz-1kHz seems beneficial.
But maybe this isn't the issue I think it is, or maybe the trade-off with ease of design to the measurement system is worth it?
Your write up was, as always, very informative. But I don't have formal schooling in this level of mathematics, so even if I understand this topic conceptually, I'm sure that having the underlying principles explained more simply will be of benefit to me (and possibly any others that are reading this thread).
You see, to me, resolution at LFs is almost unimportant. That's because we are talking about small rooms (this is not the forum for large PA systems) where the room will dominate anything that the speaker does. And the resolution is beginning to match that of our ear at these LF. Good LF resolution would always be nice, but to me its 10% of the problem - not worth major compromises to a useful system.
np, unfortunately I've been a bit short of time over the summer (world cup gets in the way of this sort of thing!) so far but I have at least worked through an assortment of Qt based wrinkles in my local dev environment and can now get a UI up and running. Next step is to start putting some graphs on the screen and working out how to interact with them.