Hornresp Update 3200-130421
Hi Everyone,
To prevent a fatal error from being generated, the Filter Wizard is now disabled when Eg is set to zero, or when maximum SPL has been calculated.
Kind regards,
David
Hi Everyone,
To prevent a fatal error from being generated, the Filter Wizard is now disabled when Eg is set to zero, or when maximum SPL has been calculated.
Kind regards,
David
Hi Dan,
It was a bug to the extent that it created a fatal error 🙂.
Kind regards,
David
Attachments
Hi just a guy,
In that case, it seems that neither project has much of a chance of getting off the ground any time soon 🙂.
As I recall, you showed that there was a small difference of about 1 dB at a few frequencies when Hornresp was used to compare the SPL responses of a horn profile approximated by four parabolic segments against the same profile approximated by four conical segments.
The difference is as expected. What I don't understand though, is how this example demonstrated the need for more segments in Hornresp.
That's the last thing I need - something else to think about 🙂.
Kind regards,
David
In that case, it seems that neither project has much of a chance of getting off the ground any time soon 🙂.
As I recall, you showed that there was a small difference of about 1 dB at a few frequencies when Hornresp was used to compare the SPL responses of a horn profile approximated by four parabolic segments against the same profile approximated by four conical segments.
The difference is as expected. What I don't understand though, is how this example demonstrated the need for more segments in Hornresp.
That's the last thing I need - something else to think about 🙂.
Kind regards,
David
Here's my original post describing this error.
This result isn't terrible but it's certainly not accurate either; it's +1 db in one area and -1 db in another area, and the error covers most of the usable bandwidth of a sub. And I could easily show a more dramatic example. Besides, I have two other reasons this situation is nowhere near ideal.
1. Once you are in Akabak and you make changes you no longer have a Hornresp "horn data" export wizard to give csa vs length. This turns horn folding into a nightmare. A few people sent me various equations and spreadsheets to work around this and there are ways to work around it within Akabak as well but Hornresp is a better tool for this job.
2. Flexibility - more segments allows more freedom. 4 segments allows a very limited range of opportunity while more segments increases the options exponentially. This may not seem too important but I've spent way more of my life using Akabak than I'd like only to end up with inaccurate results (as outlined in the quoted post) and no "horn data" export wizard.
You can trivialize the importance of this but I don't think you can deny it would make Hornresp better than it already is. And at this point, Hornresp is so advanced that there's not many ways left to make real and meaningful improvements. With the recent addition of filters there's only 3 major potential improvements left (IMO) and this is one of them.
But I know, it isn't going to happen. I'll drop it now for another year.
Last edited:
Hi just a guy,
I can deny anything I like 🙂.
Similar to the way that a chain is only as strong as its weakest link, the Hornresp simulation model is only as good as its weakest assumption. As previously explained, there are far more significant limitations in the model than the four segment maximum. There is little point in specifying a bass horn profile accurate to the nearest millimetre when plane wavefronts are being assumed, when the sound wavelengths involved are measured in metres, and when the actual physical results can be appreciably affected by having a folded acoustic path, vibrating enclosure panels, a flexing driver diaphragm and other non-linearities not accounted for in the standard lumped-element model as used in Hornresp.
With Hornresp, I have tried to strike a sensible and practical balance between the accuracy of the predictions and the number of inputs required to achieve those predictions. In my experience, and as I think you and others have confirmed in your comments on AkAbak, the more complex the input requirements become, the more difficult it is to use the software, and the greater is the chance of getting something wrong.
Thanks - you can make that two years, if you like 🙂.
Kind regards,
David
I can deny anything I like 🙂.
Similar to the way that a chain is only as strong as its weakest link, the Hornresp simulation model is only as good as its weakest assumption. As previously explained, there are far more significant limitations in the model than the four segment maximum. There is little point in specifying a bass horn profile accurate to the nearest millimetre when plane wavefronts are being assumed, when the sound wavelengths involved are measured in metres, and when the actual physical results can be appreciably affected by having a folded acoustic path, vibrating enclosure panels, a flexing driver diaphragm and other non-linearities not accounted for in the standard lumped-element model as used in Hornresp.
With Hornresp, I have tried to strike a sensible and practical balance between the accuracy of the predictions and the number of inputs required to achieve those predictions. In my experience, and as I think you and others have confirmed in your comments on AkAbak, the more complex the input requirements become, the more difficult it is to use the software, and the greater is the chance of getting something wrong.
Thanks - you can make that two years, if you like 🙂.
Kind regards,
David
Hello Bjørn,
For the moment David doesn't show group delay but this will probably be a further improvement required...
Best regards from Paris, France
Jean-Michel Le Cléac'h
True enough. I didn't think you would, but touche.
Understood. But I don't see a problem with trying to be as accurate as possible.
There's not much we can do about the plane wave assumption. But the folded acoustic path, vibrating enclosure panels, flexing diaphragm and other non-linearities are all effects that are well known and these effects are accounted for outside the software to some degree by savvy designers. These effects are all well outside the scope of most simulation software and for good reason.
On the other hand, the fact that the wavelengths are measured in meters is of no consequence, the graphs are measured in db and I've shown they are not accurate in some cases. And multiple segments is definitely within the scope of simulation software if the author desires it.
Saving us from ourselves... I like it, lol.
No problem. I wasn't planning to ever bring it up again but you practically invited it with your "never say never" comments and continuing to add other features you have historically said are not going to happen.
Anyway, if it's not clear from this discussion and others that I know you've seen, I think Hornresp is already too good to be true and I'm not trying to complain. Just pointing out there's still a bit of room for improvement. Not much room anymore but still a little bit.
So thanks again, I love Hornresp.
Last edited:
Since you need this kind of accuracy, I assume that your designs as built match the Hornresp predictions to within significantly less than +/-1dB?
-Bjørn
Hi Jean-Michel,
Unfortunately, as is the case with the Loudspeaker Wizard, it would not be possible for me to retain the real-time updating of results in the Filter Wizard if phase response or group delay for the complete system (including the filter stage) was required.
I think I would prefer to continue to have the ability to see immediate changes in the results, rather than sacrifice this feature in order to add in a group delay chart 🙂.
Kind regards,
David
Last edited:
There used to be a guy here (although he was much more active in other forums) that would break simulations down into 50+ segments in Akabak and show people that if their measurements did not almost exactly overlay the simulations it was because they didn't accurately build what they simulated.
I usually spend hours (and sometimes days or weeks) using the best tools available to try to get as accurate as I can get if I'm going to put time and money into a project. I don't see a problem with that.
Hello David,
I agree that the ability to see immediate changes in the response is an excellent feature of the new version of Hornresp and probably more important than the influence of the filter on the impulse response or on the group delay.
Best regards from Paris, France
Jean-Michel Le Cléac'h
Excellent - thanks Jean-Michel. I wasn't exactly sure which was the more important from a practical perspective.
Kind regards,
David
I agree with Jean-Michel. You chose the more important practical side.
The filters are beginning to be useful. Once you get the bugs swatted and the math under your belt.
The filters are beginning to be useful. Once you get the bugs swatted and the math under your belt.
Do you have a link?
Of course not, as long as the simulation model is valid or accurate enough for what you apply it to. My point is that if the difference between model and measurements are greater than the differences between small refinements of the model, those small refinements are not worth it 🙂
Regards,
Bjørn
Wouldn't realtime update depend on how powerful computer is?
You could have a checkbox (or setting) to enable additional stuff to be shown.
That would leave the wizard responsive for slower machines.
Would it be possible to have the filters enabled(optional) in loudspeaker wizard so that you could design response with crossover in mind?
You could have a checkbox (or setting) to enable additional stuff to be shown.
That would leave the wizard responsive for slower machines.
Would it be possible to have the filters enabled(optional) in loudspeaker wizard so that you could design response with crossover in mind?
I can think of a gentleman who was doing exactly what is described. Josh Ricci. He has some good ideas, and shows a great thinking ability.
He also likes using AkaBak thinking that there is a better overall simulation of what goes on.
Davids reply was most salient. But I cannot seem to find it!
So when I'm not looking for it it will pop up.
Short but sweet David was able to sim in four segments what was done with TLC in a great many more segments in AkaBak.
In the low end of sound reproduction it does not matter as much as most people think.
getting accuracy to the nearest mm only matters in the high frequency horns. And even there you would be very surprised what works and what will still work with compromises.
He also likes using AkaBak thinking that there is a better overall simulation of what goes on.
Davids reply was most salient. But I cannot seem to find it!
So when I'm not looking for it it will pop up.
Short but sweet David was able to sim in four segments what was done with TLC in a great many more segments in AkaBak.
In the low end of sound reproduction it does not matter as much as most people think.
getting accuracy to the nearest mm only matters in the high frequency horns. And even there you would be very surprised what works and what will still work with compromises.
While I agree that 4 segments are adequate for most designs I do find that I long for at least another segment when modelling tapped horns.😱
This usually means I end up exporting to Akabak and adding an extra segment.
The issue with the tapped horn sim is that most of the segments are predefined by the driver position and the beginning and end of the horn. This only leaves S3 as a variable (or S4 for the TH1 option)
As an example the much discussed Danley TH115-118 tapped horn which has a very small S2 and a high initial expansion can not be modelled accurately in Hornresp.
I totally agree that most sims are inaccurate due to errors in calculating the hornpath and I always check the volume of the horn sim against reality. Some of the most outrageous claims made for some tapped horns I have checked result from sims that are 30% or more bigger than the actual cabinet! A few percent either way seem insignificant in comparison.
Kind Regards Martin (Xoc1)
This usually means I end up exporting to Akabak and adding an extra segment.
The issue with the tapped horn sim is that most of the segments are predefined by the driver position and the beginning and end of the horn. This only leaves S3 as a variable (or S4 for the TH1 option)
As an example the much discussed Danley TH115-118 tapped horn which has a very small S2 and a high initial expansion can not be modelled accurately in Hornresp.
I totally agree that most sims are inaccurate due to errors in calculating the hornpath and I always check the volume of the horn sim against reality. Some of the most outrageous claims made for some tapped horns I have checked result from sims that are 30% or more bigger than the actual cabinet! A few percent either way seem insignificant in comparison.
Kind Regards Martin (Xoc1)
Thanks for the pointer, Mark. I think this may be what you are referring to:
http://www.diyaudio.com/forums/subwoofers/189784-gjallerhorn-2.html#post2586520
Nearfield measurements vs sim at page 1 of the thread.
Regards,
Bjørn
http://www.diyaudio.com/forums/subwoofers/189784-gjallerhorn-2.html#post2586520
Nearfield measurements vs sim at page 1 of the thread.
Regards,
Bjørn
No, and I don't have time to look. But you can search for posts from soho54, you'll find a lot of his posts in avsforum and hometheatreshack. He's also the guy responsible for the ez horn spreadsheet, the best Akabak tutorial I've found (as well as several tutorials on other softwares), and (along with Brian Steele) he's the most important resource I know of for info on accurately folding horns, among other things. While he was active, everything he posted was an incredible resource. He spent an incredible amount of time and went further into horn study using research and various obscure (as well as well known) tools than anyone else I know.
I have to respectfully disagree. For example, the inclusion of the ability to simulate PAR segments in Hornresp was a great addition. It helped us become more accurate. As David has shown previously, the difference is usually pretty small but it does make a difference. And as I've shown, sometimes the difference is not trivial.
Just because there are some things that we can't currently simulate doesn't mean we shouldn't do the best job we can with the things that we can.
If you reduce this argument to reductio ad absurdum, it follow that we shouldn't bother to simulate in the first place because we can never achieve perfection. I prefer to err the other way, regularly using as many as 3 different programs to simulate the same thing since all programs have their won strengths and weaknesses.
My next major project (if I ever get around to it, obtain the funds and assuming it goes as planned) is going to cost about $5000. You can bet I'm going to do every single little thing in my power to make sure my initial sims are as accurate as possible and IMO every single fraction of a db of accuracy counts.