Hornresp

GM said:

Bummer. FWIW, it's apparently causing me another, more aggravating, problem since now my machine runs out of virtual memory a lot quicker than normal. I mean, normally I can leave it booted up for weeks before I have to reboot whereas now it's a matter of days, so AFAIK it's HR or MS critical and/or NAV updates that's causing it. :(

Since the latter two have never caused this particular 'problem' and I haven't installed any other executable programs or seen any new ones in the TASK MANAGER that sneaked in, I don't know what else to attribute it to.

GM

Hi GM,

It is interesting to note that your Hornresp problems only seem to have started after the filter was added to the Find tool, and the record limit was increased to 9999.

As far as running out of virtual memory is concerned, while I am no expert, from your description it sounds like it could be a machine configuration problem.

Does the ‘Subscript out of range’ error occur only when the Find tool is used, or can it be generated at other times as well?

Thanks.

Kind regards,

David
 
Greets!

True.

No, I occasionally get it same as jogi59 and as I alluded to previously it appears to be all about SAVE, just that I normally am using FIND to trigger a SAVE, but I can sometimes trigger it by clicking ADD and hit BACK to save it.

WRT running out of virtual memory, I haven't opened HR since a reboot several days ago, but have had a NAV update, so to my computer illiterate observation, HR is starting to look like the probable culprit.

GM
 
GM said:
Greets!

True.

No, I occasionally get it same as jogi59 and as I alluded to previously it appears to be all about SAVE, just that I normally am using FIND to trigger a SAVE, but I can sometimes trigger it by clicking ADD and hit BACK to save it.

WRT running out of virtual memory, I haven't opened HR since a reboot several days ago, but have had a NAV update, so to my computer illiterate observation, HR is starting to look like the probable culprit.

GM

Hi GM,

Thanks for this. I will include some further changes in the next update in an attempt to address both the ‘Subscript out of range’ error and the virtual memory problem. I will let everyone know when Version 22.00 is released.

Kind regards,

David
 
GM said:
WRT running out of virtual memory, I haven't opened HR since a reboot several days ago, but have had a NAV update, so to my computer illiterate observation, HR is starting to look like the probable culprit.

Hi GM,

When you open the Windows Task Manager and select the 'Processes' tab, what is your Hornresp.exe 'Mem Usage' figure? In my case, the value never exceeds 5,000K, which is really nothing in the grand scheme of things (only 5MB), and is about what I would have expected to see.

Thanks.

Kind regards,

David
 
Does anyone know why Hornresp shows a falling response with a front loaded horn, while Akabak does not?

I took a FLH that I made in Hornresp, exported it to Akabak, and the drooping response was flattened in Akabak.

I have a feeling that Hornresp is correct, as a conical horn should form an acoustic low pass. But Akabak is usually quite accurate...

I checked LE to be sure it was correct, it's the only thing that I could think of...
 
Hornresp export to Akabak

David,

I exported a tapped horn design to Akabak.
I notice that the first duct segment has nodes 7 and 8.
Node 7 has nothing attached to it.
Intuitively, this should act as an open-ended duct, but Akabak appears to treat it as a closed end duct. (The horn response is unchanged if I change the node to 0, explicitly closing it.)
So it works OK, but more by default than by design.
More of a nit than a bug...
 
Patrick Bateman said:
Does anyone know why Hornresp shows a falling response with a front loaded horn, while Akabak does not?

Hi Patrick Bateman,

Are you comparing the Hornresp constant directivity SPL response to the AkAbak acoustic power response or to the AkAbak acoustic pressure response? Hornresp (resonances not masked) and AkAbak power results should be identical.

AkAbak includes a simple directivity model in the acoustic pressure response calculations which extends the high frequency response. You would need to use the Hornresp directivity tool in that case to get a meaningful comparison (bearing in mind that the Hornresp directivity model is more sophisticated than the one used in AkAbak).

Hope this helps.

Kind regards,

David
 
Re: Hornresp export to Akabak

Don Hills said:
I exported a tapped horn design to Akabak.
I notice that the first duct segment has nodes 7 and 8.
Node 7 has nothing attached to it.

Hi Don,

What version of Hornresp are you using? A tapped horn design exported from Hornresp (either 3 or 4 segments) should not specify node 7 anywhere.

Segment 1 is specified by nodes 8 and 9
Segment 2 is specified by nodes 9 and 10
Segment 3 is specified by nodes 10 and 11
Segment 4 is specified by nodes 11 and 12

To allow me to investigate further, could you please post a copy of the Hornresp-generated tapped horn AkAbak script showing the use of node 7. Thanks.

Kind regards,

David
 
Greets!

OK, I opened HR late last night and it started out at 4192K, did a FIND, ADD, PREVIOUS, SAVE and it's up to 5712k. Another set and it only increases to 5724k. Minimizing it drops it to 1108k. This morning I was greeted with the virtual memory too low error message. Coincidence? Dunno, I'll have to reboot and try again to see how long it takes without opening HR.

GM
 
Re: Re: Hornresp export to Akabak

David McBean said:


What version of Hornresp are you using? A tapped horn design exported from Hornresp (either 3 or 4 segments) should not specify node 7 anywhere.


Hi David,
You're right. I was using version 20.00. I've now downloaded version 21.50, and it uses nodes 8 and 9 for the first segment. I didn't realise it had been so long since I updated Hornresp - time flies when you're having fun. :)

As to the port being unterminated, it won't matter to Akabak because it defaults to terminating ("grounding") unterminated ports. I look at it from a programmer's perspective - if the node state doesn't matter, then just leave it undefined, but since it has to be closed for the horn to work, it should be explicitly closed to make the intention clear to someone interpreting or modifying the script. Like I said, more a nit than a bug.

I'm using Honresp and Akabak to investigate possible enclosures for a pair of FRDs (Full Range Drivers) with rather difficult parameters - 15 inch diameter, 22 Hz Fs, 800 L Vas. (Altec 420A) A classic bass reflex design specs out at 1350 L, tuned to 21 Hz... Spousal Acceptance Factor on a pair of such boxes is along the lines of, "If you put such large boxes in the lounge you can go and live in them." :-(
 
GM said:
OK, I opened HR late last night and it started out at 4192K, did a FIND, ADD, PREVIOUS, SAVE and it's up to 5712k. Another set and it only increases to 5724k. Minimizing it drops it to 1108k. This morning I was greeted with the virtual memory too low error message. Coincidence? Dunno, I'll have to reboot and try again to see how long it takes without opening HR.

Hi GM,

Are there any other applications listed in your Windows Task Manager that show a high memory usage?

Also, if you have not already done so, you could perhaps check your virtual memory allocation:

Start > Control Panel > System > Advanced > Performance Settings > Advanced > Virtual Memory

What is your "Total paging file size for all drives", in MB?

Kind regards,

David
 
Re: Re: Re: Hornresp export to Akabak

Don Hills said:
I look at it from a programmer's perspective - if the node state doesn't matter, then just leave it undefined, but since it has to be closed for the horn to work, it should be explicitly closed to make the intention clear to someone interpreting or modifying the script.

Hi Don,

I missed the key point of your first post - sorry. You are suggesting that to avoid any ambiguity, node 8 in a Hornresp exported tapped horn AkAbak script should really be shown as node 0. Correct?

Kind regards,

David
 
Jmmlc said:
Do you think it will be very difficult to adapt Hornresp to a loudspeaker loaded on both sides by a horn (which may be different).

Hi Jean-Michel,

The way that Hornresp is structured, the best I can do is as detailed in my earlier post #381, relating to the release of Version 21.00 containing the compound horn option (Note 9 is now on page 17 rather than page 16 of the Help file). Note that it is only possible to use conical and/or exponential profiles.

Unfortunately, specifying back-to-back push-pull Le Cléac’h horns is not an option :).

Kind regards,

David
 
Hornresp Version 22.00

Hi Everyone,

Hornresp Version 22.00 has just been released. Changes are:

1. Impulse Response Tool:

* Calculation algorithm improved to reduce unwanted "ringing" artefacts.
* 'Compare previous' functionality added - requested by David_Web and Oliver (tb46).
* Auto-ranging time window - requested by Oliver.
* On-axis impulse response can now be calculated - requested by Jean-Michel (JMMLC).
* Impulse data can be exported as a wave sound file - requested by Jean-Michel.

2. Phase Response and Group Delay Charts:

* Results for the whole system rather than just the driver are now given - requested by Eva.
* The two charts are updated when the Combined Response tool is used - requested by Eva.

3. Bug Fixes:

* The Run-time error '5' message generated when multiple decimal points were entered into fields L12 to L45 has been corrected - reported by Johan (Rademakers).

* When the Horn 2 output of a compound horn was selected using the Combined Response tool, the SPL Response chart title indicated "Direct Radiator Output" rather than "Horn 2 Output". This has been corrected.

* Some further small changes have been made to the code in an attempt to fix the 'Subscript out of range' error being seen by GM and jogi59. Steps have also been taken to ensure that dynamic arrays are completely erased after use, to reclaim memory, and hopefully to help with GM’s virtual memory problem.

Once again, my thanks to Jean-Michel Le Cléac’h for providing the necessary algorithm for the Impulse Response tool. I am using my own method to calculate and display phase response and group delay.

Substantial changes have been made to the program with this latest release. Could you please advise me if you find any bugs. Could GM in particular please let me know if the new changes have made any difference to the 'Subscript out of range' error, and/or to the virtual memory problem. Many thanks.

Kind regards,

David
 
Re: Re: Re: Re: Hornresp export to Akabak

David McBean said:
You are suggesting that to avoid any ambiguity, node 8 in a Hornresp exported tapped horn AkAbak script should really be shown as node 0.

Hi Don,

Further to my note above, while it is certainly possible to identify the closed end of a duct by designating it as node 0, in AkAbak this cannot be done with a flared waveguide (which is often required as segment 1 in a practical tapped horn design). To be consistent, I chose to use the same numbering arrangement for both elements.

By definition, the absence of a radiator means that a duct or waveguide must be closed at that end.

I understand what you are saying, but I think I prefer to leave things the way that they are :).

Kind regards,

David
 
"Impulse data can be exported as a wave sound file"
Thanks! (I thought I bugged you about that) :smash: :D

Now I know that when you say "no can do" you really mean "shh, don't ruin the surprise" ;)

Thanks for the compare as well. It's a lot easier to work with now.


Maybe I should be quiet a while and let you catch your breath...
but would it be possible to have any popup windows not block the movement of the parent window?
And also to keep IR window open and then update it.
Hmm, maybe the ability to break out response windows for easier viewing. You probably already have this in the roadplan for later as I guess it's a major overhaul of the code.



I have already played around with the IR export function and listened to the simulation for the TH I built (or close enough at least) and it works really well. I can even hear the same "pipe" coloration I get when I tap the cone with my finger. A "clonk" type sound.
I find that pretty cool. Very useful to understand what's going on.
The frequency response also models like it should when run through the IR.

btw now the IR is always calculated with resonances not masked.
 
Re: Re: Re: Re: Hornresp export to Akabak

David McBean said:


Hi Don,

I missed the key point of your first post - sorry. You are suggesting that to avoid any ambiguity, node 8 in a Hornresp exported tapped horn AkAbak script should really be shown as node 0. Correct?

Kind regards,

David

Correct. It's just my personal opinion, though based on "sound porgramming practice". If a tapped horn requires that the "throat" end to be terminated (closed), then it is not wise to depend on Akabak terminating it by default. One day the default might change (granted, unlikely). Explictly terminating the node makes it clear that the end of the line must be closed, both to Akabak and to anyone reading the script seeking to understand it.

Sorry if I seem to come across as a pedant, I just tend to notice things like this. It makes me good at my job (currently a system test and validation engineer), but doesn't endear me to the people in whose work I find fault. :) I've had enough of my own programming and development work criticised to know how it feels like from the other side.
 
Re: Re: Re: Re: Re: Hornresp export to Akabak

David McBean said:


<snip>

I understand what you are saying, but I think I prefer to leave things the way that they are :).


No problem. Like I said a few minutes ago in a previous post, it's only my opinion, and you make a good argument for leaving it the way it is.

I do like your tapped horn wizard. More "box plot" programs could usefully use sliders, instead of the current "enter value" - "calculate / plot" iteration.

I liken it to tuning a radio - using a knob / slider is a simple and intuitive way of searching the dial for new stations. Entering each frequency using a numeric keypad is only practical when you know which frequency you want in the first place. The "tapped horn wizard" sliders enable searching for alignments between the known alignments.

For example, when calculating something as simple as a vented enclosure, the classic alignments often result in over-excursion in the passband at the driver's rated input. In this case, one can reduce the box size and apply a Linkwitz transform. This involves juggling box volume and port tuning while watching the response and excursion graphs to reach an acceptable compromise. Sliders would make this process much quicker.