Hi David
I have tried the 22 version too. At last I can see group delay and phase of the acoustical output, even when using combined response
The jumps in grup delay in tapped horns (and in the bottom octave of midrange horns) that cause crossover headaches are now evident. The changes in phase and group delay depending on spatial loading are now evident too.
I suggest adding delay compensation to the phase response, and a dialog allowing the user to enter the desired amount of delay, and a checkbox to optionally keep this value for further calculations (as long as the record is not changed). By default that delay could be the one associated to total horn length.
I also suggest adding a range select dialog to the group delay plot, like in the electrical impedance plot but allowing to type the values and with a check box to optionally don't reset the values in the next calculations (again, as long as the record is not changed). This is to overcome the tall and narrow spikes that sometimes appear. Allowing to enter a value that would be just substracted from all the values in the plot would be useful too. This value could be the same used in the phase plot. Remember that many of us are using DSP delay to compensate horns and tweaking the delay sometimes allows minor phase correction.
Also, it seems that phase and group delay don't get updated when calculating frequency response with the directivity option.
Thank you very much for the update
I have tried the 22 version too. At last I can see group delay and phase of the acoustical output, even when using combined response
The jumps in grup delay in tapped horns (and in the bottom octave of midrange horns) that cause crossover headaches are now evident. The changes in phase and group delay depending on spatial loading are now evident too.I suggest adding delay compensation to the phase response, and a dialog allowing the user to enter the desired amount of delay, and a checkbox to optionally keep this value for further calculations (as long as the record is not changed). By default that delay could be the one associated to total horn length.
I also suggest adding a range select dialog to the group delay plot, like in the electrical impedance plot but allowing to type the values and with a check box to optionally don't reset the values in the next calculations (again, as long as the record is not changed). This is to overcome the tall and narrow spikes that sometimes appear. Allowing to enter a value that would be just substracted from all the values in the plot would be useful too. This value could be the same used in the phase plot. Remember that many of us are using DSP delay to compensate horns and tweaking the delay sometimes allows minor phase correction.
Also, it seems that phase and group delay don't get updated when calculating frequency response with the directivity option.
Thank you very much for the update
Jmmlc said:
Hi Jean-Michel,
While your suggestion could certainly be implemented in Hornresp (I have already tested it in the development environment - see attached screenprint) I think I nevertheless would still prefer to display and export 'raw' -pi / +pi wrapped phase instead.
The way things are at the moment, users can process exported Hornresp phase data any way that they wish. As far as I can see, this would not be possible if 'derived' corrected phase was exported instead.
However - if enough users were to indicate that they preferred your corrected phase, then I might be persuaded to change my mind
. Before anyone asks though, displaying and/or exporting both phase presentations, is not an option that I am willing to consider.Kind regards,
David
Attachments
Eva said:
Hi Eva,
Your suggestions would require significant changes to Hornresp and a considerable amount of work to implement. I will keep them in mind for the future, but I am not promising anything
.You are correct - phase and group delay don't get updated when calculating frequency response with the directivity option. I have no plans to change this at the moment. The next release will however allow impulse response to be calculated off-axis and exported as a wave sound file, as requested by Jean-Michel.
Kind regards,
David
Hello David,
"The way things are at the moment, users can process exported Hornresp phase data any way that they wish. As far as I can see, this would not be possible if 'derived' corrected phase was exported instead."
I am sorry we disagree on that and prefer others to comment on the usefulness of the phase as presented in the actual version of Hornresp...
Best regards from Paris, France
Jean-Michel Le Cléac'h
"The way things are at the moment, users can process exported Hornresp phase data any way that they wish. As far as I can see, this would not be possible if 'derived' corrected phase was exported instead."
I am sorry we disagree on that and prefer others to comment on the usefulness of the phase as presented in the actual version of Hornresp...
Best regards from Paris, France
Jean-Michel Le Cléac'h
Jmmlc said:
Hi Jean-Michel,
The problem I see in exporting corrected phase is that it has already been processed using what could reasonably be described as an "arbitrary rule". How can the 'raw' phase information then be retrieved from the exported corrected phase data, if required, without having to also export information regarding the correction / normalising rule used?
Kind regards,
David
Hello David,
If we let any travel time effect in the phase curve then it is obvious that at high frequency it will correspond to many hundreds or thousands periods and thus rotate the phase many time 2pi.
Then, with rising travel time warping will also affect low frequency and this is something we don't want because the effect of the travel time will mask the phase variation due to the acoustic loading we want to analyse.
IMHO, when it comes to the phase of propagating waves, the only reference that we should consider is the phase as reflected at the origin of the propagation (travel time = 0) though I know this becomes a bit difficult when multipath waves exist (e.g.: combined load...).
You know perfectly all of that, but this leads to the additional question of "phase curve what for?". Having quite a long experience on that subject, I don't follow Eva on the usefulness of the knowledge of the phase curve to program a digital filter:
1) simulation is not measurement
2) phase values taken in an absolute way are mostly useless ...
For practical purpose as crossover set up (delays, phase correction..) Hornresp's group delay curve is much more important to consider IMHO (specially when the group delay is expressed in equivalent distance travelled at the speed of sound).
The main importance of the phase curve I can see in Hornresp is when performing optimisation, e.g.: optimisation of rear load when trying to compensate reactance... as details on the phase curve are more easily visible than on the group delay curve.
But I'll be interested to know how the way other people are using the phase curve given by Hornresp.
Best regards from Paris. France
Jean-Michel Le Cléac'h
If we let any travel time effect in the phase curve then it is obvious that at high frequency it will correspond to many hundreds or thousands periods and thus rotate the phase many time 2pi.
Then, with rising travel time warping will also affect low frequency and this is something we don't want because the effect of the travel time will mask the phase variation due to the acoustic loading we want to analyse.
IMHO, when it comes to the phase of propagating waves, the only reference that we should consider is the phase as reflected at the origin of the propagation (travel time = 0) though I know this becomes a bit difficult when multipath waves exist (e.g.: combined load...).
You know perfectly all of that, but this leads to the additional question of "phase curve what for?". Having quite a long experience on that subject, I don't follow Eva on the usefulness of the knowledge of the phase curve to program a digital filter:
1) simulation is not measurement
2) phase values taken in an absolute way are mostly useless ...
For practical purpose as crossover set up (delays, phase correction..) Hornresp's group delay curve is much more important to consider IMHO (specially when the group delay is expressed in equivalent distance travelled at the speed of sound).
The main importance of the phase curve I can see in Hornresp is when performing optimisation, e.g.: optimisation of rear load when trying to compensate reactance... as details on the phase curve are more easily visible than on the group delay curve.
But I'll be interested to know how the way other people are using the phase curve given by Hornresp.
Best regards from Paris. France
Jean-Michel Le Cléac'h
David McBean said:
Hi Jean-Michel,
Thanks for your insights into phase and group delay. There is one thing though that I still don't quite understand:
Your corrected phase is calculated as follows -
for I = 1 : Nfreq;
PUNW(I) = PUNW(I) - Dphase * (FREQ(I) - FREQ(1));
end
Why is it not calculated as -
for I = 1 : Nfreq;
PUNW(I) = PUNW(I) - (PUNW(Imag1) + Dphase * (FREQ(I) - FREQ(Imag1)));
end
Assuming that in both cases -
Dphase = (PUNW(Imag2) - PUNW(Imag1)) / (FREQ(Imag2) - FREQ(Imag1));
Any further comments would be appreciated.
Me too.
Kind regards,
David
Jmmlc said:
Thanks for your insights into phase and group delay. There is one thing though that I still don't quite understand:
Your corrected phase is calculated as follows -
for I = 1 : Nfreq;
PUNW(I) = PUNW(I) - Dphase * (FREQ(I) - FREQ(1));
end
Why is it not calculated as -
for I = 1 : Nfreq;
PUNW(I) = PUNW(I) - (PUNW(Imag1) + Dphase * (FREQ(I) - FREQ(Imag1)));
end
Assuming that in both cases -
Dphase = (PUNW(Imag2) - PUNW(Imag1)) / (FREQ(Imag2) - FREQ(Imag1));
Any further comments would be appreciated.
Jmmlc said:
Me too
.Kind regards,
David
REQUEST FOR ASSISTANCE
Hi Everyone,
My existing Hornresp website is to be closed down on 30 September 2009 as part of a product rationalisation plan by my Internet Service Provider. More information can be found at http://bigpond.custhelp.com/cgi-bin/bigpond.cfg/php/enduser/std_adp.php?p_faqid=13457 if required.
I am currently attempting to establish a new site, but I have run into a problem downloading Hornresp from it, over a dial-up connection. The download starts normally enough but prematurely terminates when about 440 KB of the 982 KB Setup.exe file has been saved.
REQUEST:
To enable me to gain a better understanding of the scope of the problem, it would be greatly appreciated if people who have dial-up Internet connections could try downloading the current version of Hornresp from my new website at www.dmcbean.bigblog.com.au and then check to ensure that the Setup file can be opened.
Could you please let me know if your download is successful, and if it is not, could you please tell me the size of the file that is saved. Rather than posting to this discussion thread, if you like you can send me an e-mail at dmcbean@bigpond.com
Note that downloading over a broadband connection seems to work fine. It is only with dial-up connections that the problem arises.
Thanking you in anticipation.
Kind regards,
David
Hi Everyone,
My existing Hornresp website is to be closed down on 30 September 2009 as part of a product rationalisation plan by my Internet Service Provider. More information can be found at http://bigpond.custhelp.com/cgi-bin/bigpond.cfg/php/enduser/std_adp.php?p_faqid=13457 if required.
I am currently attempting to establish a new site, but I have run into a problem downloading Hornresp from it, over a dial-up connection. The download starts normally enough but prematurely terminates when about 440 KB of the 982 KB Setup.exe file has been saved.
REQUEST:
To enable me to gain a better understanding of the scope of the problem, it would be greatly appreciated if people who have dial-up Internet connections could try downloading the current version of Hornresp from my new website at www.dmcbean.bigblog.com.au and then check to ensure that the Setup file can be opened.
Could you please let me know if your download is successful, and if it is not, could you please tell me the size of the file that is saved. Rather than posting to this discussion thread, if you like you can send me an e-mail at dmcbean@bigpond.com
Note that downloading over a broadband connection seems to work fine. It is only with dial-up connections that the problem arises.
Thanking you in anticipation.
Kind regards,
David
Henkjan said:
Hi Henkjan,
I would much prefer to have a single download location, if at all possible.
I have already received the first response to my request for assistance - interestingly, that person has the same problem downloading the Hornresp file as I do.
If enough people report difficulties downloading the file, then hopefully I can convince my Internet Service Provider that there might be a problem in their system somewhere. Obviously, the more responses I can get confirming the problem, the easier it should be to convince my ISP.
If people with dial-up Internet connections still want to be able to download Hornresp after 30 September 2009, then I really need to hear from them now.
Kind regards,
David
Re: Hornresp Version 22.00
Greets!
I installed V22 on 5.31, re-booted and so far I've had no virtual memory or runtime error problems, but I've only had time to do two quick sims and compare them. The rest of the time HR has been minimized in the Taskbar, so don't know if that makes a difference.
Thanks for the much needed impulse response plot changes.
GM
David McBean said:
Greets!
I installed V22 on 5.31, re-booted and so far I've had no virtual memory or runtime error problems, but I've only had time to do two quick sims and compare them. The rest of the time HR has been minimized in the Taskbar, so don't know if that makes a difference.
Thanks for the much needed impulse response plot changes.
GM
Re: Re: Hornresp Version 22.00
Hi GM,
Many thanks for the feedback. Things sound reasonably promising so far! Could you please let me know if the runtime error in particular, does occur again. If I don't hear from you, I will assume that "no news is good news".
Kind regards,
David
GM said:
Hi GM,
Many thanks for the feedback. Things sound reasonably promising so far! Could you please let me know if the runtime error in particular, does occur again. If I don't hear from you, I will assume that "no news is good news"
.Kind regards,
David
Hello David,
As you may probably imagine, this is the result of a reasoned choice. The main reason is to avoid large phase values {abs(phase) >>0 } at the lowest frequencies after travel time compensation.
This is based on the fact that at low frequency the phase due to the acoustical load only is rarely outside the range -pi / +pi whatever is the acoustical load.
In the case we have a bandwith at 0 / -6dB ranging in HF then using the second formula results in large phase (absolute) values at low frequency which is unrealistic.
I tried both formulas and the one I finally chosen has a more general appliance.
Best regards from Paris, France
Jean-Michel Le Cléac'h
As you may probably imagine, this is the result of a reasoned choice. The main reason is to avoid large phase values {abs(phase) >>0 } at the lowest frequencies after travel time compensation.
This is based on the fact that at low frequency the phase due to the acoustical load only is rarely outside the range -pi / +pi whatever is the acoustical load.
In the case we have a bandwith at 0 / -6dB ranging in HF then using the second formula results in large phase (absolute) values at low frequency which is unrealistic.
I tried both formulas and the one I finally chosen has a more general appliance.
Best regards from Paris, France
Jean-Michel Le Cléac'h
David McBean said:Hi Jean-Michel,
Thanks for your insights into phase and group delay. There is one thing though that I still don't quite understand:
Your corrected phase is calculated as follows -
for I = 1 : Nfreq;
PUNW(I) = PUNW(I) - Dphase * (FREQ(I) - FREQ(1));
end
Why is it not calculated as -
for I = 1 : Nfreq;
PUNW(I) = PUNW(I) - (PUNW(Imag1) + Dphase * (FREQ(I) - FREQ(Imag1)));
end
Assuming that in both cases -
Dphase = (PUNW(Imag2) - PUNW(Imag1)) / (FREQ(Imag2) - FREQ(Imag1));
Any further comments would be appreciated.
Me too
Kind regards,
David
Jmmlc said:
Hi Jean-Michel,
Many thanks for the explanation.
I was thinking of possibly using:
for I = 1 : Nfreq;
PUNW(I) = PUNW(I) - Dphase * FREQ(I);
end
rather than:
for I = 1 : Nfreq;
PUNW(I) = PUNW(I) - Dphase * (FREQ(I) - FREQ(1));
end
That way, if the mean group delay value was included in the chart title then the original uncorrected phase could be directly calculated by the user, if required, without also having to be aware of the need for a 10 hertz offset.
The result for the example you gave previously would look like the attached.
What do you think - would this be an acceptable compromise?
Kind regards,
David
