An unanticipated side effect of the changes, it seems. A welcome result nonetheless.
A breakthrough!!!
I think I might have finally worked out what was causing the problem in the first place!
From the next release onwards, record changes not being saved, data files being corrupted and 'Error 13: Type mismatch' messages being generated for no apparent reason, will hopefully be a thing of the past
.
David,
I'm not sure if this has been mentioned yet but the following comparable graphs are not allowing the captured graph to be compared.
Particle velocity
Efficiency
Driver power
Sound pressure
They can be captured but cannot be compared after.
PS...The maximum SPL tool is everything I hoped it would be. Excellent work.
I'm not sure if this has been mentioned yet but the following comparable graphs are not allowing the captured graph to be compared.
Particle velocity
Efficiency
Driver power
Sound pressure
They can be captured but cannot be compared after.
PS...The maximum SPL tool is everything I hoped it would be. Excellent work.
Exactly what I came here to report (Mr. Data-Bass Ricci beat me to it), aside from a very enormous THANK YOU, MR. McBEAN for these fantastic updates (especially #4 on your list!)!! I appreciate your continued hard work and dedication to this wonderful FREE program. Makes our lives MUCH easier, time and again.
Many cheers,
Justin
Hi Josh,
Many thanks for the feedback - I will have to try to work out what has gone wrong
.Pleased to hear that the modified Maximum SPL tool is working well!
Kind regards,
David
Hi Justin,
Many thanks for visiting with the intention of posting a bug report, and for your kind words regarding Hornresp.
#4 should be even better after the next update
.Kind regards,
David
Hi bushroot,
Thanks for the thanks!
Hornresp can do that, for sure.
Kind regards,
David
Thanks for the thanks!
Hornresp can do that, for sure
.Kind regards,
David
More about Path parameter
Hi David, had not really realized this change before, one of my designs has a front radiating driver and a horn opening at the back. How do you specify that? "Around" the box or direct distance as if, no box was there?
Thanks, Kurt
Hi David, had not really realized this change before, one of my designs has a front radiating driver and a horn opening at the back. How do you specify that? "Around" the box or direct distance as if, no box was there?
Thanks, Kurt
A request for a new feature: The ability to model the effect of a resonant "stub", preferably at any point in the horn, but can be restricted to S2, S3 and S4 as necessary. I'm thinking it could be included as an additional feature like how filtering and filling are currently handled in HornResp. Basically use sliders to specify length, width and depth of the stub.
Why? I think it would be nice to see how much of an impact these resonant stubs have on addressing the out of band peaks that occur with THs and bandpass systems, without having to build them first.
Why? I think it would be nice to see how much of an impact these resonant stubs have on addressing the out of band peaks that occur with THs and bandpass systems, without having to build them first
.A request for a new feature: The ability to model the effect of a resonant "stub", preferably at any point in the horn, but can be restricted to S2, S3 and S4 as necessary. I'm thinking it could be included as an additional feature like how filtering and filling are currently handled in HornResp. Basically use sliders to specify length, width and depth of the stub.
Why? I think it would be nice to see how much of an impact these resonant stubs have on addressing the out of band peaks that occur with THs and bandpass systems, without having to build them first
TL.app and Akabak can both do this but it would be cool if Hornresp could too, although I'd probably never use it.
In the meantime if you need help with a sim I can run it through TL.app if you don't have it or don't want to spend time learning it.
I don't have a specific sim in mind yet, but for awhile I've been thinking about how converting one of the panels that make up a folded horn into a resonance chamber could help to deal with some of the out of band response peaks. Thing is I don't know how much volume of one these resonance chambers would have to be to say damp a 160Hz high-Q resonance by 6dB, and where would be the optimum place to insert this stub. If a sim could show this, I could plan out the fold of the horn and the location of the chamber accordingly.
Attachments
When you have a plan I'll do the sim. Or you can, TL.app is easy and quick to use once you get the hang of it. Just let me know if you want some sim help, it only takes a few minutes. And the cool thing about TL.app is you can drag stuff around, so just drag the stub along the horn length to see what impact it has in different spots immediately, kinda like the Hornresp sliders but different.
Danley's stubs in the DTS-10 weren't a large cross sectional area but they were pretty long, so they took up a fair bit of cab space. And there's stuffing in there too. I don't think the stubs are going to be very effective unless they are quite large.
Danley's stubs in the DTS-10 weren't a large cross sectional area but they were pretty long, so they took up a fair bit of cab space. And there's stuffing in there too. I don't think the stubs are going to be very effective unless they are quite large.
Hmm... where can I download a copy of this TL.app? I might want to have a look at it...
Yeah, the size requirements of said stubs is what worries me. The DTS10 is tuned almost a good octave below the TH designs I'm looking at though (which would also lower the out of band resonance frequencies too), and the stubs should decrease in length as target frequency increases.
Download | Leonard Audio
But oops, I forgot that tl.app doesn't give accurate results for tapped horns, at least it didn't last time I checked. I did do some comparisons on other things and everything was fine (close enough to Hornresp). But he added that tapped horn feature and it just didn't work right and he didn't fix it as far as I know.
You could try stubs on other things like tls but regular tls won't have those spiky spikes like tapped horns.
So I guess Akabak is the only choice. Sorry about that, I should have remembered.
I can do an Akabak sim for you if you like but it won't be anytime soon. My 32 bit computer is out on loan and my main computer did not like the Oracle VM for some reason.
But oops, I forgot that tl.app doesn't give accurate results for tapped horns, at least it didn't last time I checked. I did do some comparisons on other things and everything was fine (close enough to Hornresp). But he added that tapped horn feature and it just didn't work right and he didn't fix it as far as I know.
You could try stubs on other things like tls but regular tls won't have those spiky spikes like tapped horns.
So I guess Akabak is the only choice. Sorry about that, I should have remembered.
I can do an Akabak sim for you if you like but it won't be anytime soon. My 32 bit computer is out on loan and my main computer did not like the Oracle VM for some reason.
STUBS
I was raising questions about these a couple of years back ! For eg, just as tuned ports can suffer from port compression, then stubs surely must too. In which case they need to be sized to prevent issues. But, nowhere have i seen ANY discussion about this. I expect that, incorrect sizeing/damping could lead to a mistuned etc overall respomse.
Having the right options etc within a program to evaluate/sim stubs, is essential in my opinion. So if HR can include such functions =
I was raising questions about these a couple of years back ! For eg, just as tuned ports can suffer from port compression, then stubs surely must too. In which case they need to be sized to prevent issues. But, nowhere have i seen ANY discussion about this. I expect that, incorrect sizeing/damping could lead to a mistuned etc overall respomse.
Having the right options etc within a program to evaluate/sim stubs, is essential in my opinion. So if HR can include such functions =