Hornresp

Is that really a bug David, it seems to me that constant velocity is to isolate what the "horn" itself is doing?

Hi Dan,

It was a bug to the extent that it created a fatal error :).

Kind regards,

David
 

Attachments

  • Error.png
    Error.png
    21.4 KB · Views: 150
Hi just a guy,

What I was trying to convey is that I have about as much interest in doing a video tutorial as you have in adding more segments.

In that case, it seems that neither project has much of a chance of getting off the ground any time soon :).

I did show you an example where a 4 segment model was in significant error simply by exporting the file and opening it in Akabak, simply due to CON vs PAR, so I don't think the need is overrated.

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.

I was just giving you something to think about.

That's the last thing I need - something else to think about :).

Kind regards,

David
 
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.

Here's my original post describing this error.

Hi, I agree with you in most cases it won't have much effect. But it only took me about 3 minutes to create this mess. I'm pretty sure I could show a much worse example if I spent more time on it.

An externally hosted image should be here but it was not working when we last tested it.


The only difference between these two lines is PAR vs CON segments and my lines don't overlay nearly as nicely as yours. I noticed this problem almost immediately when Hornresp allowed PAR segments. I don't remember which model caused me the most trouble but I've seen examples much worse than I've posted here.

As I pointed out originally this isn't a fatal flaw, it doesn't seem to shift the peaks right or left (which would be really bad) it just changes the amplitude a bit. Even though this isn't bad I would prefer to avoid surprises like this. In very large horns, 2 db at tuning can be a difference of hundreds of liters of enclosure size. I'd really like to be as accurate as possible when I fold.

Although I haven't studied in depth what factor is causing this, I think it's one or more very long segments that will cause this discrepancy.

(I got the mail, thanks!)

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,
You can trivialize the importance of this but I don't think you can deny it would make Hornresp better than it already is.

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.

I'll drop it now for another year.

Thanks - you can make that two years, if you like :).

Kind regards,

David
 
Hi just a guy,

I can deny anything I like :).

True enough. I didn't think you would, but touche.

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.

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.

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.

Saving us from ourselves... I like it, lol.

Thanks - you can make that two years, if you like :).

Kind regards,

David

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:
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.

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
 
For the moment David doesn't show group delay but this will probably be a further improvement required...

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
 
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


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.
 
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

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
 
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.

Excellent - thanks Jean-Michel. I wasn't exactly sure which was the more important from a practical perspective.

Kind regards,

David
 
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.

Do you have a link?

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.

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?
 
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.
 
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.:eek:
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.:scratch1:
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)
 
Do you have a link?

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.

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

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.