Hi Mogens
I have no experience with Python but I understand that it's a popular choice for a wide variety of jobs.
Matlab/Octave looks more focused and optimized for matrix manipulation, the core of the task here.
I am sure there are powerful maths libraries for Python but if I have to find libraries and write lowish-level code then I would be inclined to stay with Fortran because I already know it.
Best wishes
David
I need to estimate how many data points are possible in a realistic measurement run.
What software do you use?
How much time does it take to do one measurement?
Best wishes
David
Hi David,
I understand. And I can't say what will work best for you. However, I do think you perhaps should try to take a look at what the Python community can offer. I don't think you will need to do much lowlevel code.
Numpy, which is a part of Scipy does have some MATLAB similarities.
NumPy for Matlab users — NumPy v1.14 Manual
Btw. this is a very interesting project.
Mogens
I understand. And I can't say what will work best for you. However, I do think you perhaps should try to take a look at what the Python community can offer. I don't think you will need to do much lowlevel code.
Numpy, which is a part of Scipy does have some MATLAB similarities.
NumPy for Matlab users — NumPy v1.14 Manual
Btw. this is a very interesting project.
Mogens
I use the freeware Room EQ Wizard. By measurement time, I'm guessing you mean the time it takes between clicking on start and when a measurement appears on screen? If so, it depends on the what the sweep length is set to; I usually use the default, shortest length, and that takes seven seconds from start to finish. The longest sweep length comes in at twenty-six seconds from start to finish.
I have no doubt that Python is awesome, but it IS another new language and starting all over in a new language is always a PITA (no matter how "easy they are to use".)
I have already coded all this in FORTRAN, because when I started doing this, FORTRAN was just about the only option that had the math functions required. (And compiled FORTRAN is amazingly fast. One could also use the Intel Math Kernel libraries for even more speed.) But FORTRAN is lousy at doing GUIs, so I do that in VB.net. I would hate to code the math in any language that does not do complex numbers transparently - not many do.
I use HolmImpulse for taking data. It has two advantages - both of which are almost essential - 1) it can sync all the measurements in time, which is essential; 2) it can write out multiple data runs as a single file. This later feature was added for me precisely for my project. It becomes a major PITA to have to write out individual files for each data point and then to have to name them, organize them, etc. Holm writes out my 13 data points, all synced in time, into a single file. It could do almost any number of points.
It takes just a few seconds to make a single data point run. If I have to get up and manually rotate the device then this takes a few more seconds. Generally a full data set takes me about 10-15 minutes. If I have a second to do the rotation with me at the PC I can do a run in well under 5 minutes. One day we did some twenty speakers in a few hours. Time is certainly NOT an issue once one has the code. The code is the key and the math is the key to the code. Those took me years. Which is why I don't understand why people want to start this project from scratch. It makes no sense to me.
Automated rotation is a nice feature, but one that I have lived with and without. It was convenient when I had it, but I really got to where I didn't miss it. It is a small part of the project and one that takes more than just coding and math skills to construct. Making a reliable scanning system is NOT a simple project from the construction standpoint. I just got to where it was more trouble to fabricate than it was worth.
I have already coded all this in FORTRAN, because when I started doing this, FORTRAN was just about the only option that had the math functions required. (And compiled FORTRAN is amazingly fast. One could also use the Intel Math Kernel libraries for even more speed.) But FORTRAN is lousy at doing GUIs, so I do that in VB.net. I would hate to code the math in any language that does not do complex numbers transparently - not many do.
I use HolmImpulse for taking data. It has two advantages - both of which are almost essential - 1) it can sync all the measurements in time, which is essential; 2) it can write out multiple data runs as a single file. This later feature was added for me precisely for my project. It becomes a major PITA to have to write out individual files for each data point and then to have to name them, organize them, etc. Holm writes out my 13 data points, all synced in time, into a single file. It could do almost any number of points.
It takes just a few seconds to make a single data point run. If I have to get up and manually rotate the device then this takes a few more seconds. Generally a full data set takes me about 10-15 minutes. If I have a second to do the rotation with me at the PC I can do a run in well under 5 minutes. One day we did some twenty speakers in a few hours. Time is certainly NOT an issue once one has the code. The code is the key and the math is the key to the code. Those took me years. Which is why I don't understand why people want to start this project from scratch. It makes no sense to me.
Automated rotation is a nice feature, but one that I have lived with and without. It was convenient when I had it, but I really got to where I didn't miss it. It is a small part of the project and one that takes more than just coding and math skills to construct. Making a reliable scanning system is NOT a simple project from the construction standpoint. I just got to where it was more trouble to fabricate than it was worth.
Last edited:
It looks like the choices come down to REW, HolmImpulse or ARTA. What mikes do each of you use and are they USB? Time sync is critical and most likely to be a problem with USB microphones because the inbuilt ADC is not synchronous with the computer. I don't see USB compatibility as essential but certainly desirable, and only likely to become more so. Apparently REW is better than HolmImpluse on this particular issue but I haven't looked in depth. One potential concern with HolmImpulse is that the developer seems to have moved his focus to other projects. REW has an active forum that looks useful. I don't know about the support for ARTA.
Best wishes
David
The HolmImpulse documentation that I find is poor. How do you sync the measurements in time?
And how does REW synchronize times? Arta shows this in the documentation so that's +1.
Best wishes
David
Last edited:
Via a loopback signal or an acoustic timing reference, details in
Making Measurements
Holm has a time lock option (described in The Subwoofer DIY Page v1.1 - Time Alignment using HolmImpulse)
REW can export all measurements in one go as well btw
Making Measurements
Holm has a time lock option (described in The Subwoofer DIY Page v1.1 - Time Alignment using HolmImpulse)
REW can export all measurements in one go as well btw
I use a Behringer ECM8000 in connection with a small mixing board and a stereo USB interface. Although I have used a desktop PC with a sound card in the past.
And what 3ll3d00d said with regard to REW timing reference.
I had read the REW doco but there are alternatives as to how maintain time sync - loop back or acoustic, and multiple alternatives for set up - sound card or headphone output, USB mike or internal input, etc.
So let me phrase it the same way I asked Earl, how do you do it?
I have not actually used REW so a bit more detail on connections and process would be useful.
Best wishes
David
Thanks for the link but apparently there are some problems with this HolmImpulse option, as shown in Taking Measurements With Your Measurement Software
Hence my question to Earl as to how he does time sync, whether he just avoids a USB mike or has some other solution.
Where is this shown?
Best wishes
David
Last edited:
Ahh, my apologies, I misunderstood.
I use the loopback; so with my stereo audio interface I have the Right output channel connected with a cable directly into the Right input channel. The Left output goes into my amplifier and the Left input comes from the microphone (via a small mixing board for phantom power and level control). If I let out anything useful, let me know if you need more details.
I haven't tried using the acoustic timing reference, and it seems like it wouldn't be ideal for our purposes since it requires a second sound source to use as the reference.
In the export menu there is an option to 'export all measurements as text', the result is a collection of text files; one for each individual measurement. So it's not all into a single file (at least as far as I know how to use REW).
If it's relevant, REW can also export the IR as a text or WAV file.
Last edited:
So rather than a USB mike it's a stereo USB external sound card, what sort?
If I understand the link in post #113 then that may or may not be problematic.
Could you read it if, you haven't already, and comment?
Not ideal at all, I want to avoid it if reasonably possible.
I take Earl's point - we don't want lots of files, especially as we may have 400 or so different measurements.
I assume the way to do it is to append each new measurement to one active file.
Perhaps John Mulcahy would customize REW for us.
Or we write a script to run REW and concatenate the files, possibly in Python
Best wishes
David
Last edited:
yes this is why REW added the acoustic timing reference option so that the timing ref can come from a fixed source. The signal is (IIRC) a 5-20kHz sweep so you just need to stick a tweeter in some specific position and leave it there. Obviously not as convenient as a physical loopback but it does let you use a usb mic so might be appealing.
I don't see why it matters either way tbh. If anything a predictable naming convention (like xVyH where x is degrees vertical and y is degrees horizontal) seems preferable to me in some senses (makes it more immediately obvious what files you have to hand, your file parsing code is marginally simpler as it becomes "find files, for each file; get degrees H and V, read data", every other piece of software I can think produces a single frd per measurement)
Maybe 400 (or 800 if two layer scan) files per speaker measurement, measure multiple variations as you experiment, keep a few months work and you have hundreds of thousands of files...
Professionally I work on major enterprise databases - for the Australian Bureau of Statistics for instance - I have a very definite opinion on the desirability of hundreds of thousands of separate files as a data library
Think Object Orientation - the set of data for a full polar measurement of a speaker is one object so handle it as one object - store it, name it, process it, delete it as one object.
Best wishes
David
sure if you keep them in one giant directory but that would be not so sensible You don't need to couple your representation of that object to the serialised form after all. Anyway regardless, this is just the input data format that commonly available measurement systems use. You can of course read that in and then save it in a format of your choice.
Also worth noting that REW can't store more than 30 measurements in one session anyway so if you need 00s of measurements, you're going to have to export multiple times (and hence will have to accept multiple inputs)
You don't need to couple your representation of that object to the serialised form after all. Anyway regardless, this is just the input data format that commonly available measurement systems use. You can of course read that in and then save it in a format of your choice. Also worth noting that REW can't store more than 30 measurements in one session anyway so if you need 00s of measurements, you're going to have to export multiple times (and hence will have to accept multiple inputs)
Last edited:
Correct. It's a Behringer UCA202, purchased many years ago because it was cheep and reasonably good quality.
Problematic for my USB sound card in particular, but not necessarily USB sound cards in general. According to Bill Waslo, the UCA202 I use is not compatible with HOLM Impulse's time lock feature on account of it using separate clock's for recording and playback. But there are other stereo (or more channel) USB interfaces that should work just fine and, as the link pointed out, it's a simple matter to test if a particular unit suffers from "creeping offset". So I don't see it as too big of an issue for our purposes.
Using REW's loopback for a timing reference shouldn't present an issue no matter what sound card is used, as long as there is a way to physically connect an output to an input.
USB microphones seem to be out of the question for this project since there will be two clock's in two physically separate devices and they are one input/zero output devices so there's no way to loop a signal with them. Although, as was mentioned above, with a second sound source, they could still be used.
I take Earl's point - we don't want lots of files, especially as we may have 400 or so different measurements.
I assume the way to do it is to append each new measurement to one active file.
Perhaps John Mulcahy would customize REW for us.
Or we write a script to run REW and concatenate the files, possibly in Python
Yes! Python!
I have actually thought about learning Python for this project before...
Anyway, from what I've seen, John is pretty agreeable to adding reasonable additions to REW. Another option could be to read REW's files directly; as 3ll3d00d pointed out, there is a 30 measurement limit, but that brings it down from 400 files to 14.
I haven't used HOLM Impulse in years, but it looks like it has a 49 measurement limit.
Last edited:
OK, that's as I understood it too.
I say no acoustic reference, this project is already sufficiently difficult.
Then you end up with some data identified within the file, some by the file name - inconsistent, inconvenient and certainly not the way to do it.
The obvious way is a script with a loop that calls the positioner to place the mike (manually or CNC) then calls REW to take a measurement, and each measurement is appended to a total measurement file.
This also allows more flexibility in variable position steps, even Klippel's trick of calculation of optimal step size and position as measurement proceeds.
This could be done without John Mulcahy's involvement if it is the script that takes the REW file and appends it to the total file.
So we eliminate a dependency, modularize the CNC nicely, have simple file procedures.
I continue to work on the maths, I understand my quantum mechanics lectures better now...when it's too late...and the Klippel patent a little better too.
Best wishes
David
Last edited: