This kind of smart interpolation or forecasting could be valuable while designing or tuning drivers, wave guides, horns etc. But it could also be just an extra pain in the ... while designing speaker simulator containing several ways for processing and combining measured and simulated data.
I would select more measurements with constant angle step because it's supported standard, fast to measure and guarantees possibility to select needed directions depending on how and where measurement data is used or delivered. Otherwise some conversion and export function may be needed to produce data to directions which were not captured or simulated with truncated angle set. Single polarmap with few contour lines is not enough and not mandatory information for speaker engineering - no matter how accurate the result happens to be in some case with subjectively selected measurement directions.
Simulator programmers can't force anybody to measure directions they/we want or hope, though smart interpolation in every data exchange interface would be helpful for compensating laziness of speaker designers. Sorry about my pessimism
I would select more measurements with constant angle step because it's supported standard, fast to measure and guarantees possibility to select needed directions depending on how and where measurement data is used or delivered. Otherwise some conversion and export function may be needed to produce data to directions which were not captured or simulated with truncated angle set. Single polarmap with few contour lines is not enough and not mandatory information for speaker engineering - no matter how accurate the result happens to be in some case with subjectively selected measurement directions.
Simulator programmers can't force anybody to measure directions they/we want or hope, though smart interpolation in every data exchange interface would be helpful for compensating laziness of speaker designers. Sorry about my pessimism
The reason that I devoted so much time to learning how to make horns and waveguides in 123D is because all of the laser scanning software is crap. I should post my sad attempts to do a 3D scan of QSC's oblate spheroidal waveguide...
For a lot of this old software that breaks under Windows 7 or Windows 10, the optimum solution would be to distribute an "appliance."
For instance, I have a Windows XP that I fire up whenever I want to run Akabak, and I even run Robert Bullock's "Boxmodel" software. It's twenty seven years old, but still very usable:
Software
Hi John
It's not that my code is old or breaks in new windows releases, its just bad code, plain and simple. I run it under Win 10 and use Visual Studio 2015 so its up to date in that regard. But I have never taken a single coarse in coding, I taught myself, and I have never been diligent with it as it has always been just a means to an end for the other things that I am trying to do. Releasing it "as is" would only frustrate people (we already see the negativity surrounding new ideas,) and it would just go down as a dismal failure. Coding is simply not my profession and I am loath to release anything that I have done.
Don't feel bad, that's totally normal! I spent sixteen hours troubleshooting a disastrous release of code at a bank yesterday. From what I can see, the original developer made four different copies of the same code base, then made changes to each one independently.
So there's 4X as much code as needed, and trying to squash bugs becomes a herculean task. Naturally, there's no documentation whatsoever, and the code that's there is complete spaghetti. (I got assigned to the project four months ago.)
Microsoft went from 13 employees to 127,000 employees in the span of 40 years. Code like this is a big part of that!
So there's 4X as much code as needed, and trying to squash bugs becomes a herculean task. Naturally, there's no documentation whatsoever, and the code that's there is complete spaghetti. (I got assigned to the project four months ago.)
Microsoft went from 13 employees to 127,000 employees in the span of 40 years. Code like this is a big part of that!
Most of the issues with old executables that won't run in newer machines aren't because of the algorithms or even the hardware of the machines, it's from the ever-changing target of user interface supports in most operating systems. Of course, without user interface function that still works without crashing, people can't very effectively use the algorithms that are called by it, so maybe that's a moot point. But without digging into more program development itself, a bunch of procedures in whatever language often aren't very helpful.
I'm also kind of a programming hack, myself, though I've done a lot of it. I don't work well in a team programming environment, and I'd hate to be a person who was stepping into my code from outside. After you get to a certain level of complexity is a system, you've invented so many structures and new terminology to call 'things' that attempts to include documentation within look like gibberish. I often have difficulty following my own code from some years ago.
I'm also kind of a programming hack, myself, though I've done a lot of it. I don't work well in a team programming environment, and I'd hate to be a person who was stepping into my code from outside. After you get to a certain level of complexity is a system, you've invented so many structures and new terminology to call 'things' that attempts to include documentation within look like gibberish. I often have difficulty following my own code from some years ago.
Hey, I think it's working. Thanks to all who helped me past this hurdle.
Index of /Xsim/BetaTest
It's not Earl's nearfield/farfield velocity distribution system (too complex for me now, but maybe later). Just a way that interpolates between different off-axis data curves you provide to it. It is VERY fast. Put a set of FRD files, in the same location that share the same basic name, with the measurement angles given after an '@' in the name. Such as 'MyFRDdata@60H45V.frd", etc. If any files in the set (other than "@0") don't have 'H' and/or 'V' specified, it will be assumed that the driver's pattern is axisymmetric. The program will try to infer symmetries if you don't specify something in a given quadrant or axis.
Or load the example file "Use FRD files sets for off-axis.dxo" for a quick drive around. Again, this is still in progress, please no bug reporting or feature requests! And of course, no guarantees on accuracy.
Bill
Index of /Xsim/BetaTest
It's not Earl's nearfield/farfield velocity distribution system (too complex for me now, but maybe later). Just a way that interpolates between different off-axis data curves you provide to it. It is VERY fast. Put a set of FRD files, in the same location that share the same basic name, with the measurement angles given after an '@' in the name. Such as 'MyFRDdata@60H45V.frd", etc. If any files in the set (other than "@0") don't have 'H' and/or 'V' specified, it will be assumed that the driver's pattern is axisymmetric. The program will try to infer symmetries if you don't specify something in a given quadrant or axis.
Or load the example file "Use FRD files sets for off-axis.dxo" for a quick drive around. Again, this is still in progress, please no bug reporting or feature requests! And of course, no guarantees on accuracy.
Bill
I hope to add a PEQ circuit element when I get to it. For FIR, there's probably nothing I can do, an FIR design program is kind of out of scope (and there are already some pretty good ones out there). You could generate a curve with RePhase and load that as the
"Acoustic Effect" file for the drivers.
"Acoustic Effect" file for the drivers.
It's coming along
Still a ways to go, but for anyone who wants to play a little before --
Index of /Xsim/BetaTest
And on a related note -- people ask for active and dsp filter functions, but a complication is that DSP filters have an inherent delay so if you mix dsp filters with analog or passive filters (on different drivers) you need to deal with that. Does anyone have any references on the inherent delay (delay when just passing a signal through the box, without filtering) of dsp PEQ boxes? I have some MiniDSP boxes and will be getting a sample of a new Dayton Audio device so I can measure them, but I'd like to be able to include that parameter without measuring every blasted box or board in the world!
Still a ways to go, but for anyone who wants to play a little before --
Index of /Xsim/BetaTest
And on a related note -- people ask for active and dsp filter functions, but a complication is that DSP filters have an inherent delay so if you mix dsp filters with analog or passive filters (on different drivers) you need to deal with that. Does anyone have any references on the inherent delay (delay when just passing a signal through the box, without filtering) of dsp PEQ boxes? I have some MiniDSP boxes and will be getting a sample of a new Dayton Audio device so I can measure them, but I'd like to be able to include that parameter without measuring every blasted box or board in the world!
Bill, I just arrived at the party (and I haven't read all the responses here yet)....My OmniMic program, though (can be downloaded free from Parts Express, and can do all the viewing and processing steps without buying the mic) does polar plotting, similar but not the same as yours. People can just feed it a series of FRD files with the angle given within the filename and it will do colored directivity diagrams in several forms.
One question: how do I get directivity shown in the polar frequency response plot below 500 Hz in your OmniMic program? I've got directivity down to just below 100 Hz, but the plot stops at 500 Hz.
Chris
Attachments
Last edited:
Xilica XP series apparently have an insertion delay of 1.5ms, the ElectroVoice Dx38 is 1.927ms, Yamaha SP2060 is 761μsec, and the Behringer DCX2496 (which I don't own) is "less than 1ms".
Chris,
When you have a polar plot up in OM, look just to right of the "OmniMic" logo at bottom left -- there are two little yellow arrows that control the starting frequency for the plot. At bottom right are similar for the upper frequency.
Thanks for the info on the DSP boxes. Wow, about 1 to 2 msec entrance fee for having a DSP inline, Kind of makes combo DSP+passive (with the passive not going through DSP) not very practical for upper freq drivers.
When you have a polar plot up in OM, look just to right of the "OmniMic" logo at bottom left -- there are two little yellow arrows that control the starting frequency for the plot. At bottom right are similar for the upper frequency.
Thanks for the info on the DSP boxes. Wow, about 1 to 2 msec entrance fee for having a DSP inline, Kind of makes combo DSP+passive (with the passive not going through DSP) not very practical for upper freq drivers.
This must be a version issue with the application--there is no horizontal axis control in the "polar frequency response" window of the OmniMic version that you posted a link to above.
Actually the 1-2ms insertion delay is smaller than I remembered it being. The only penalty that you get with DSP filters is delay (especially true for FIR filters). I would instead put any passive crossover network after the DSP crossover on the loudspeaker drivers themselves (i.e., traditional passive loudspeaker practice) rather than trying to play passive/active games upstream of the DSP crossover. YMMV.
Chris
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.