Yea, that was made with the new version which hasn't been released yet. A lot has changed and it really needs proper documentation - for too long I have been adding bits that are scattered across the thread. Also the new config files are not 100% backward compatible (sorry for that, but that's life). It needs consolidation now and that will take some time...
Any idea what this ABEC error is?
"ERRORS ------------------------
Number format problem in data block of import stream.
"
This shows in the Observation -tab sometimes when trying to open solved ABEC project in the VACS.
Is it something that can be fixed after solving the project?
This time it happened when I first simulated with following config settings:
ABEC.f1 = 700
ABEC.f2 = 10000
ABEC.NumFrequencies = 20
Then wanted to check how the top end looks like with parameters;
ABEC.f1 = 700
ABEC.f2 = 20000
ABEC.NumFrequencies = 30
Waited almost four hours to see the ERROR message
"ERRORS ------------------------
Number format problem in data block of import stream.
"
This shows in the Observation -tab sometimes when trying to open solved ABEC project in the VACS.
Is it something that can be fixed after solving the project?
This time it happened when I first simulated with following config settings:
ABEC.f1 = 700
ABEC.f2 = 10000
ABEC.NumFrequencies = 20
Then wanted to check how the top end looks like with parameters;
ABEC.f1 = 700
ABEC.f2 = 20000
ABEC.NumFrequencies = 30
Waited almost four hours to see the ERROR message
I actually never got throught to the Appendix
Now as I try to study some "basic" duct acoustics for the PWT background, I begin to fully appreciate the struggle you had to face with an analysis of waveguides.
For a beginner in your software, I find it hard to follow the threads. So if it's possible for you to add some guidance. If only piece by piece, that would be very helpfull.
But I can only be gratefull for the things you have done already! Thank you for this.
Any idea what this ABEC error is?
"ERRORS ------------------------
Number format problem in data block of import stream.
"
This shows in the Observation -tab sometimes when trying to open solved ABEC project in the VACS.
Is it something that can be fixed after solving the project?
This time it happened when I first simulated with following config settings:
ABEC.f1 = 700
ABEC.f2 = 10000
ABEC.NumFrequencies = 20
Then wanted to check how the top end looks like with parameters;
ABEC.f1 = 700
ABEC.f2 = 20000
ABEC.NumFrequencies = 30
Waited almost four hours to see the ERROR message
When I ran a sim up to 20K I copied the project called it a different name and changed only the start and end frequency in solving.txt shown in the attachment. It only took ten minutes longer than the standard project to solve. Maybe it is the start frequency and number of frequencies that is making the simulation more difficult than it needs to be.
Try what I did and see if it works for you.
Attachments
Thanks, will try!
I noticed a smooth looking simulation (i posted it earlier) had problems when the simulated frequencies changed, thats why I kind of randomly change the values to get a new perspective to the previously simulated frequency range. Simulations are just simulations, so better just stick to config that works repeatedly (mabat seems to have been using those settings as well, in the thread).
I noticed a smooth looking simulation (i posted it earlier) had problems when the simulated frequencies changed, thats why I kind of randomly change the values to get a new perspective to the previously simulated frequency range. Simulations are just simulations, so better just stick to config that works repeatedly (mabat seems to have been using those settings as well, in the thread).
Last edited:
After changing anything in ABEC scripts, like the "solving.txt" (manually or via the tool), I always delete the "Results" directory and re-run ABEC, if the project has been already calculated. I do this without thinking about it, maybe it is not necessary but as it has to be calculated again anyway, I just find it safer.
If there are no objections, I'll start with the six mic positions as shown above. I'm quite close to start measuring, only hope Earl Geddes didn't lose his interest, otherwise without his knowledge and mathematical skills I would have made only a limitedly useful construction exercise.
- I'll start a new thread as soon as I have it running and getting some results.
- I'll start a new thread as soon as I have it running and getting some results.
Last edited:
Sorry for the late reply.
I have not and will not lose interest, but my abilities to contribute are limited. Almost all of the tools that I used to use are no longer licensed, so I have limited capability to do the complex (literally) matrix manipulations that are required. As I said, the crux will be a singular value decomposition of a 6x6 complex matrix composed of elements that are Bessel functions (maybe with a complex argument.) Those capabilities will be required.
The spacing looks OK, except maybe the largish first distance. The evanescent waves decay exponentially so to get reasonable values for those the mics have to be close. This can be done without the evanescent waves, but that will limit the HF resolution - until the modes "cut-in".
I have not and will not lose interest, but my abilities to contribute are limited. Almost all of the tools that I used to use are no longer licensed, so I have limited capability to do the complex (literally) matrix manipulations that are required. As I said, the crux will be a singular value decomposition of a 6x6 complex matrix composed of elements that are Bessel functions (maybe with a complex argument.) Those capabilities will be required.
The spacing looks OK, except maybe the largish first distance. The evanescent waves decay exponentially so to get reasonable values for those the mics have to be close. This can be done without the evanescent waves, but that will limit the HF resolution - until the modes "cut-in".
Last edited:
That's great. I think I will be able to perform all the calculations, SVD included, but will definitely need some guidance along the way, at least for the start. I believe it will turn out being not so difficult after all but right now I have only a vague idea how to actually proceed with the data, the modes, etc. I'm really looking forward for this experiment.
I can still move the positions closer to the driver, no problem.
I can still move the positions closer to the driver, no problem.
Last edited:
Have you ever thought about to use the Fibonacci row for the spacing between the mics?
Should I? These numbers were suggested by Dr. Geddes, the author of the method (except the first distance, which is affected also by the construction). I see no reason to question that. My impression is that it is really not that important, only that a regular spacing would not be good. The Fibonacci seems a bit dense at the beginning and then quickly getting sparse. Would it be better? I have no clue.
Now give me the Bliesma T34 tweeter and I'll show you what it can do
This has been done. The OSWG (the deepest WG in the pic.) - which didn't make it into the final speaker - actually measured best.
Attachments
Last edited: