You are probably right after all the language you are using is not executed but the assembly/machine code the compiler creates. Intel does reserve access of some subtle features of their processors to their own compilers. In the end this project looks like a candidate for a massive array of GPU's anyway.
My software comments are heavily weighted by experience in trying to do collaborative projects across a group of varying ability and means. Once the ante goes above 3 or 4 large pizza's the audience leaves the building.
BTW I had no luck with the 2i2 unless the software has full ASIO support built in. Audacity, Audition 1.5, CoolEdit no way, ARTA no problems at all.
We will have to continue to disagree on this point, just as I have disagreed with just about everything else being done for this project.
Maybe I should outline how I think this project should go and people can decide if it makes sense for them.
1) I would assume axi-symmetry as a first start and use a manual scan where the source is rotated and the microphone is stationary. Such a system works well for about 80% of the speaker systems out there and is as accurate as a 400 point scan in the horizontal plane using only 13 points - up to 10 kHz. This system can be built for < 20$ (assuming the data taking capability exists,) and has already been done by me, which I would donate to the cause.
2) Loosen the symmetry limitation by rotating right, and then left, then rotate the speaker on its stand by 90 degrees and rotate right (up) and left (down) for a total of 52 points. This would yield the same results as 400 points in both the horizontal plane as well as the vertical plane for any speaker system. It would be exactly the same as the 400 point scan up to about 5 kHz for all field points and would be reasonably accurate even at oblique angles for all data points up to 10 kHz. This would use the same hardware as (1). A system like this is light years beyond what a DIY can do now and if it is satisfactory for them then they can drop out at this point with something incredibly useful to them.
3) Automate the scan and do more Phi points extending the accuracy of all non horizontal or vertical plane points as well as the frequency range. Number of points is TBD based on experiments.
4) do a two layer scan to eliminate room reflections. (1->3 use gating.)
The last two tasks are only of limited interest to a DIY but represent probably 80% of the total projects difficulty. It would be a monumental task to achieve all four tasks listed above, thus making the prognosis doubtful - useful no doubt, but to NOT do steps 1 and 2 by insisting on doing 3 and 4 would be a serious disappointment to the community who need this kind of capability.
Should this thread decide not to proceed as I have outlined above then I would gladly entertain joining another thread that does take this approach.
1) I would assume axi-symmetry as a first start and use a manual scan where the source is rotated and the microphone is stationary. Such a system works well for about 80% of the speaker systems out there and is as accurate as a 400 point scan in the horizontal plane using only 13 points - up to 10 kHz. This system can be built for < 20$ (assuming the data taking capability exists,) and has already been done by me, which I would donate to the cause.
2) Loosen the symmetry limitation by rotating right, and then left, then rotate the speaker on its stand by 90 degrees and rotate right (up) and left (down) for a total of 52 points. This would yield the same results as 400 points in both the horizontal plane as well as the vertical plane for any speaker system. It would be exactly the same as the 400 point scan up to about 5 kHz for all field points and would be reasonably accurate even at oblique angles for all data points up to 10 kHz. This would use the same hardware as (1). A system like this is light years beyond what a DIY can do now and if it is satisfactory for them then they can drop out at this point with something incredibly useful to them.
3) Automate the scan and do more Phi points extending the accuracy of all non horizontal or vertical plane points as well as the frequency range. Number of points is TBD based on experiments.
4) do a two layer scan to eliminate room reflections. (1->3 use gating.)
The last two tasks are only of limited interest to a DIY but represent probably 80% of the total projects difficulty. It would be a monumental task to achieve all four tasks listed above, thus making the prognosis doubtful - useful no doubt, but to NOT do steps 1 and 2 by insisting on doing 3 and 4 would be a serious disappointment to the community who need this kind of capability.
Should this thread decide not to proceed as I have outlined above then I would gladly entertain joining another thread that does take this approach.
An additional thought about the next likely question: What do we need to do for the next step, #2?
1)Someone needs to write the GUI. I can supply all the calculations as DLL's. I only know VB.NET for GUIs, but I could read C#. Any other languages are probably not workable. The GUI would have to be public domain and the DLL's will be supplied to do the full 3D calculations. The DLL interface is the domain of the GUI. The DLL's will be specified, but getting them to work in the GUI is the coders responsibility. I won't be able to help unless the GUI language is VB.Net or C##. I only use Visual Studio so debugging would be almost impossible unless that platform were also used.
That, to me, seems like a very doable task to start. If we can't get this one done then 3 & 4 are hopeless.
PS: The total number of points for the 2 plane task #2 is 46, because two points on each plane are redundant.
1)Someone needs to write the GUI. I can supply all the calculations as DLL's. I only know VB.NET for GUIs, but I could read C#. Any other languages are probably not workable. The GUI would have to be public domain and the DLL's will be supplied to do the full 3D calculations. The DLL interface is the domain of the GUI. The DLL's will be specified, but getting them to work in the GUI is the coders responsibility. I won't be able to help unless the GUI language is VB.Net or C##. I only use Visual Studio so debugging would be almost impossible unless that platform were also used.
That, to me, seems like a very doable task to start. If we can't get this one done then 3 & 4 are hopeless.
PS: The total number of points for the 2 plane task #2 is 46, because two points on each plane are redundant.
Last edited:
There must be someone here savvy enough in TCL/TK to build an open source GUI. As other's have said the Python interface to dll's written in any language is trivial.
Last edited:
Simple it is.
I can see the initial design changing somewhat from what was talked about earlier in this thread for simplicity sake. For example, having a stationary microphone and rotating the speaker for version 1, and I don't mind working through a few different designs for each version of the scanner and it's needs.That's what I was picturing too.
After all, different size speakers and rooms are going to be used, so having a little bit of adjustment available would be welcomed to get the longest possible IR window and easiest set up.
Yes, that sounds like it's worth the extra $20. Even with the dumb phantom power LED.
I certainly agree that this should be simple and open source (I want the resultant design and software to be accessible to everyone in the DIY audio community), and that the basic foundation should be there first. I feel that your outline is very similar to the one that I thought this project has had from the start, stated at post #29:
I understand that item 2 is different between the two outlines, but the intent appears to be the same: to be able to see all three spacial dimensions of a loudspeaker's acoustic radiation. I am very grateful that you have been lending your knowledge and insights to this project, I certainly would never have thought that something like this was even possible if it wasn't for other comments you've made in other threads, much less asked for help starting it.
I hope that you will continue to assist, and please understand that we're still trying to fully understand what you have already understand very well and have been working with for many years.
I hope so! But even if not, I'm sure that there's someone out there who is philanthropic or curious enough to lend a hand on this.
Last edited:
Sorry I can't. I just checked, the Gnu suite of compilers includes Fortran. I would suggest one starting point could be to compile the maths and compare a synthetic data set for time and accuracy as data no GUI. From what I found there might be care needed in keeping 32/64 bit versions straight and possibly the Fortran vs C array stuff (0 vs 1 as first index if that is still an issue).
I have already done that for the 2D stuff and there is no way I am going to proceed and do that for 3D without the GUI in place.
As an addition, if no one is willing to do the GUI for free, I'd offer the DLLs to anyone doing the GUI even if it is commercial. I'd prefer free of course.
Just asking. I suppose you have a description or example for someone to follow? The open source plot libraries are extremely rich in 3D visualization, rotation of axes, shading, etc. File menus, buttons, sliders, text boxes are trivial in almost any GUI environment.
I attached an example earlier, or I don;t know what you mean. My PolarMap software has been available for many years, just go to my website. You can't create your own data files as yet, but the GUI and capabilities are certainly clear.
The GUI needs to read the measurement data files, display them, window them, FFT them and array the measurements in the proper matrices to be passed to the DLL. Then the DLL calculates the modal coefficients which are passed back to the GUI. These coefficients completely specify the polar response and can be thus stored as they are to be read back in for later viewing. There is another call to the same DLL to create the pressure responses from the coefficients, as well as the power response and the DI. The DLL also contains the FFTs (for speed) and the log to linear interpolation in frequency that I do, which also does the ERB smoothing.
The GUI needs to read the measurement data files, display them, window them, FFT them and array the measurements in the proper matrices to be passed to the DLL. Then the DLL calculates the modal coefficients which are passed back to the GUI. These coefficients completely specify the polar response and can be thus stored as they are to be read back in for later viewing. There is another call to the same DLL to create the pressure responses from the coefficients, as well as the power response and the DI. The DLL also contains the FFTs (for speed) and the log to linear interpolation in frequency that I do, which also does the ERB smoothing.
Seems straight forward enough, somehow I though there was a complicating factor preventing someone from stepping up.
EDIT - I have two beautiful art nouveau windows from a Victor Horta building circa 1890. As a teenager in Milwaukee I rode the garbage truck in the summers and Conrad Schmitt Studios was the first stop, literally 100's of lb. of cut offs every week.
Last edited:
Its just a time commitment from someone who is capable. The coding of the GUI is really straightforward. The FORTRAN DLL, not so much, but with 45 years experience in FORTRAN coding, a PhD in Theoretical Physics, and already having done all this in 2D, it's not such a big problem for me. Actually when all this came up I started to think about what it would take to do the full 3D on top of what I already have and it's pretty straightforward (for me.) Starting from scratch would be a daunting task however. But I certainly am not willing to do the whole thing because I am retired and have other interests. That was the whole point of this thread, but then it seemed to bog down in "feature bloat."
it should be pretty straightforward to get that working in python. The only bit I don't know how to do is the fortran wrapper but it seems you can use F2PY Users Guide and Reference Manual — NumPy v1.14 Manual to do that. I have tended to write my own tools like that with a web front end mind you just so I can access with any device that has a browser. This is also easily done (albeit somewhat more effort). I can give that a bash at some point if no one else steps in.
The example I saw used gfortran from MINGW to create a .dll. This is how we do the interface to the Analog Discovery USB DAS. Stuff like this...
As I said, it will be very difficult to mix Python and my code unless the code is done in Visual Studio. That's because I have found it virtually impossible to debug inter language calls unless one can cross the interface within the same debugger. I have to insist here that my code remain as it is since it has been thoroughly debugged. I can only commit to suppling a compiled DLL that can be called. I cannot be expected to rewrite any portions of my code as I just don't have that kind of time. I can supply a DLL that has some FORTRAN code compiled in VS that can be tested, but that's about all I can do as far as interfacing goes. It appears from the docs above that the FORTRAN code needs to be modified to use F2PY. If that is so then this is not an option.
Again, repeating myself, the only sure fire way that I know of to make sure this works without undo complications is to do the GUI in C++, C# or VB.Net in Visual Studio. Since Visual Studio with these languages is free, I don't see that as a limitation. The FORTRAN compiler is quite expensive, but only I need that and I already have it.
Going with Python may work, I have no doubt, but, to me, the risks are very great. I have a Visual Studio Team Explorer account which would be ideal if this goes forward.
Again, repeating myself, the only sure fire way that I know of to make sure this works without undo complications is to do the GUI in C++, C# or VB.Net in Visual Studio. Since Visual Studio with these languages is free, I don't see that as a limitation. The FORTRAN compiler is quite expensive, but only I need that and I already have it.
Going with Python may work, I have no doubt, but, to me, the risks are very great. I have a Visual Studio Team Explorer account which would be ideal if this goes forward.
No not with my example all one needs is the function name and calling convention the .dll is simply loaded as any would be. One simply has to know the format of the data expected and in the case of complex numbers how they are stored.
Python BTW fully does complex math in polar or rectangular form interchangeably on arrays of arbitrary dimensions with no user "smarts" required to keep things straight.
I'm only making suggestions because at this point in time I think you will find more volunteers this way, I have no vested interest either way.
Last edited:
All data is complex, both into and out of the DLLs, but I have no idea how FORTRAN stores complex numbers internally other than they have real and imaginary parts. Sorry, but your example was unintelligible to me.
Volunteers are fine, appreciated even, but moving the point of where I contribute and others do beyond what I have stated is not fine. And I am just saying that doing this in two separate and different coding environments just seems to me to be unworkable. Maybe that's because I have never done anything that way, but I am just very concerned about committing myself to a dead end project.
FYI, many of you may know that Jean-Luc Ohl and I met here at DIY last year and agreed to cooperate on a project. That project has worked out so well that Jean-Luc is going to earn himself a place on our publication. When I commit to doing something I do it, but my experience tells me that other people are no so sincere - so I get concerned.
Volunteers are fine, appreciated even, but moving the point of where I contribute and others do beyond what I have stated is not fine. And I am just saying that doing this in two separate and different coding environments just seems to me to be unworkable. Maybe that's because I have never done anything that way, but I am just very concerned about committing myself to a dead end project.
FYI, many of you may know that Jean-Luc Ohl and I met here at DIY last year and agreed to cooperate on a project. That project has worked out so well that Jean-Luc is going to earn himself a place on our publication. When I commit to doing something I do it, but my experience tells me that other people are no so sincere - so I get concerned.
Last edited:
Sorry Earl that was meant for the person who posted directly above. It shows that on Windows you load the .dll and on a Unix system you load the .so and you simply start calling the functions nothing more is necessary. You also might have missed this comment on F2PY, you only need to keep the conventions on the variables straight. If the subroutines are using complex arrays the F2PY path might be necessary to account for the different ways the the languages store arrays.
Last edited:
Creating a wrapper for a native library is a pretty normal thing and doing that for fortran from python in numpy seems a pretty normal thing. At least as a first try anyway, if it doesn't work then go back to the drawing board. I'm happy to give it a try anyway & would put the code on github so anyone can then work on it further.