Hornresp

[minkuni]

The driver arrangement should definitely be stored as part of the permanent data record when a model is saved, as illustrated in the attached screenprint. What version of Hornresp are you using?

I am using 36.30 but this issue has been present for multiple versions. I have been thinking of doing the bug report earlier but you know how it is with something that it is possible to work around 'just this once'...

Yes, the 'Input parameters' screen indicates the correct driver configuration here too. Running the simulation gives the results for a single driver configuration regardless of the desired configuration if the model is simulated without visiting the 'Driver arrangement' screen and setting the desired parameters after opening a previously stored model.

While it could certainly be done, the existing functionality makes it easier to reset to a single driver - which is why it was adopted.

I understand and respect that people use the software in different ways, but I still disagree with the idea that the time spent putting the sliders back to 1 (if they have been changed) and resetting to non-isobaric configuration (if set) is worth more than having the dialogue box show the settings that are stored in the current configuration.

I realize that I only speak for myself, but this behavior confused me quite a bit when learning to use Hornresp.

Normally the Driver Arrangement tool is only selected when a change is to be made, so it shouldn't really matter if the settings reflect the currently-specified configuration or not.

The 'Input parameters' screen does not indicate whether or not an isobaric configuration is in use. With the current behavior there is no way to know if an isobaric configuration is in use or not other than knowing what the simulated response should look like.

While I personally prefer the tool to open with "a clean slate", I would be prepared to consider making the suggested change if others also feel that it would be an improvement - bearing in mind that the 'quick single driver reset' feature would then be lost .

Thank you for the quick response! I hope I am not in the minority in being annoyed by this

 

[Kravchenko_Audio]

While it could certainly be done, the existing functionality makes it easier to reset to a single driver - which is why it was adopted. Normally the Driver Arrangement tool is only selected when a change is to be made, so it shouldn't really matter if the settings reflect the currently-specified configuration or not.

While I personally prefer the tool to open with "a clean slate", I would be prepared to consider making the suggested change if others also feel that it would be an improvement - bearing in mind that the 'quick single driver reset' feature would then be lost .

I use Hornresp a lot. And it is more useful as David has set things up. I agree with the reason above. At least to me it works very well as it is.

It is very easy to put a little note for ourselves showing the number of drivers.

 

[minkuni]

It is very easy to put a little note for ourselves showing the number of drivers.

This, combined with a mandatory Edit>Driver Arrangement> (change to the intended settings) after loading each model with multiple drivers, has been my workaround so far.

As you exemplify my feature request for the 'Driver arrangement' behavior may not be desirable for the majority of Hornresp users. However, the incomplete storage of driver configuration with each model is most certainly a bug.

 

[tb46]

Hi Y'all,

Seasons Greetings.

I have used Hornresp a lot since 2006, and have never seen the described bug (Hornresp does not save driver arrangement on save).

I suggest keeping the existing functionality.

Regards,

 

[minkuni]

I have used Hornresp a lot since 2006, and have never seen the described bug (Hornresp does not save driver arrangement on save).

I suggest keeping the existing functionality.

Interesting...I have attached one way to reproduce the bug. Note that the 'Input parameters' are identical on both save and load. Please give it a go and let me know if the issue is present at your site as well. My sanity would appreciate it

As mentioned I am running Hornresp through Wine but I have also seen it when running Hornresp in Windows.

 

[DrDyna]

I see the same thing in Windows, but it's a little different. When I save it as 2 drivers, it correctly shows 2S under ND. When I go back to arrangement, it's back to 1. If I then push ok again, it reverts it to 1 under nd.

 

[minkuni]

Text-based description of reproducing bug:

Step 1) Make a loudspeaker model, any type
Step 2) Set the driver arrangement to 2 drivers in series or parallel.
Step 3) Simulate the model and make a note of the the response. If the drivers are offset, make a note of the relative size of the driver area compared to the rest of the model in the Schematic Diagram.
Step 4) Save the model.
Step 5) Load the model.
Step 6) Calculate the simulated response.
Step 7) Compare the frequency response (and schematic diagram, if offset driver is used) to the model created in step 1&2.

The simulation result from step 6 consistently gives me the response of the single-driver case, regardless of the driver configuration chosen in step 2. The schematic diagram also makes it obvious that the total driver area is that of a single driver.

 

[minkuni]

I see the same thing in Windows, but it's a little different. When I save it as 2 drivers, it correctly shows 2S under ND. When I go back to arrangement, it's back to 1. If I then push ok again, it reverts it to 1 under nd.

This is the correct behavior as described by David McBean. The 'Driver arrangement' window always reverts to a single driver when opened. Although I disagree with the reasoning behind it I accept it as a deliberate design choice.

Try following the steps in my previous post(s) to see if you can reproduce the bug.

 

[tb46]

Posts #5145/5147

Hi minkuni,

- the Driver Arrangement in screen print 1 is "2 Series Normal"
- the 2s (s in small letters) in the Input screen indicates two drivers in an isobaric arrangement, so would not be derived from print 1 (if it were it would say 2S (S in capital letters))
- your Confirm Changes/Save.... looks different from the one on my Windows XP laptop

No idea why those differences would occur, or how you got from an isobaric arrangement to a standard series arrangement. I tried your steps from #5147, and Hornresp works fine on my old laptop.

Regards,

 

[minkuni]

- the Driver Arrangement in screen print 1 is "2 Series Normal"
- the 2s (s in small letters) in the Input screen indicates two drivers in an isobaric arrangement, so would not be derived from print 1 (if it were it would say 2S (S in capital letters))

Interesting. No matter if I arrange the drivers as (2 drivers in series, no isobaric) or (1 driver, isobaric 2 drivers in series") the configuration is indicated as '2s'. If I arrange the drivers in parallel '2p' is used. If I arrange it as 2 series connected isobaric pairs the configuration is indicated as '2s 2s'. This is the only case where I can deduct that an isobaric configuration is being used. If capital letters are supposed to be used to indicate the driver configuration then this may indicate a subtle wine-related bug.

- your Confirm Changes/Save.... looks different from the one on my Windows XP laptop

Other than the window title bar decorations and associated buttons (which are drawn by Mac OS X) I would expect the Hornresp window itself to look very similar to your window. Are there any other differences?

No idea why those differences would occur, or how you got from an isobaric arrangement to a standard series arrangement.

I am not sure if this is a case of miscommunication on my part. I am not referring to a mixup between standard series and isobaric series.

When I select an isobaric configuration and simulate it the result is as expected. When I select a normal series or parallel connection the result is as expected. The bug symptom I am referring to is that if any configuration other than a single driver is chosen, saved and then reloaded the simulation model only uses a single driver.

I tried your steps from #5147, and Hornresp works fine on my old laptop.

Very interesting. Did you simulate the response with 2 drivers before saving and compare it to the response after reloading and simulating the same model (without touching the driver arrangement dialogue)? I am not trolling, just curious since this issue is consistently reproducible at my end.

 

[tb46]

Hi minkuni,

Post #5150: "...Did you simulate the response with 2 drivers before saving and compare it to the response after reloading the same model (without touching the driver arrangement dialogue)?..."

Yes, I did. They lay over perfectly, and I did it multiple times w/ different arrangements.

Looking back at the last picture in Post #5145, an SPL comparison: the bold SPL is isobaric (2s), and the higher/gray curve is standard series (2S). That is very easy to confirm. I just cannot get any confirmation on your bug, sorry.

Maybe somebody w/ a setup similar to yours can take another look at this.

Regards,

 

[minkuni]

tb46: Thank you! I think I finally figured out what is going on.

If I export the Hornresp record both 2 series (normal) or 1 isobaric series pair both end up as 'Nd 2s' in the resulting text file.

When I export the same record with the drivers configured as a standard parallel pair the record lists 'Nd 2p'.

If Hornresp expects a normal multi-driver configuration to have upper-case letters denoting the connection, and never expects to see an isobaric pair with the drivers connected in parallel then I guess it defaults to a single driver as the fallback configuration when it finds '2p'. In the other cases it takes the '2s' to indicate an isobaric pair, as per the program specifications.

I apologize to David and everyone else, the problem is most likely some sort of character set issue when running under Wine. I will not be able to test under Windows until I get back to work in a few days, but until then I will focus my efforts in figuring out how to fix my wine-configuration.

Any day you learn something new is a good day

 

[David McBean]

Hi minkuni,

I understand and respect that people use the software in different ways, but I still disagree with the idea that the time spent putting the sliders back to 1 (if they have been changed) and resetting to non-isobaric configuration (if set) is worth more than having the dialogue box show the settings that are stored in the current configuration.

Even though the Driver Arrangement tool has a single-driver default setting, the current configuration is still shown on the Input Parameters form, and will not change until the OK button is clicked. Personally, I find it very useful to be able to quickly reset a multiple driver arrangement back to a single driver. With the current record in Edit mode, this can most easily be done by simply double-clicking on the disabled text box showing the driver configuration, and then clicking the OK button on the Driver Arrangement form.

The 'Input parameters' screen does not indicate whether or not an isobaric configuration is in use. With the current behavior there is no way to know if an isobaric configuration is in use or not other than knowing what the simulated response should look like.

An isobaric configuration is indicated by a lower-case 's' (for series-connected) or 'p' (for parallel-connected).

The complete driver configuration 'code' is shown in red at the top of the Driver Arrangement form (see attachment) and is copied into the Input Parameters form text box when the OK button is clicked. If you are not sure how to interpret the code, try moving the three sliders to see how the code changes in response to the revised settings.

Kind regards,

David

 

[David McBean]

Hi minkuni,

If Hornresp expects a normal multi-driver configuration to have upper-case letters denoting the connection, and never expects to see an isobaric pair with the drivers connected in parallel then I guess it defaults to a single driver as the fallback configuration when it finds '2p'. In the other cases it takes the '2s' to indicate an isobaric pair, as per the program specifications.

Hornresp interprets '2P' (upper-case) as two drivers connected in parallel, and '2p' (lower-case) as an isobaric parallel-connected pair.

I apologize to David and everyone else, the problem is most likely some sort of character set issue when running under Wine. I will not be able to test under Windows until I get back to work in a few days, but until then I will focus my efforts in figuring out how to fix my wine-configuration.

No apology necessary . You had a legitimate problem with Hornresp that we needed to understand, and help you to resolve if possible. It seems that for some reason your Wine setup cannot distinguish between the upper-case and lower-case characters used in the Hornresp driver configuration code. Hopefully you will be able to find a solution to this problem.

Any day you learn something new is a good day

I couldn't agree more .

Kind regards,

David

 

[minkuni]

Even though the Driver Arrangement tool has a single-driver default setting, the current configuration is still shown on the Input Parameters form, and will not change until the OK button is clicked.

That is understood and as expected.

The complete driver configuration 'code' is shown in red at the top of the Driver Arrangement form (see attachment) and is copied into the Input Parameters form text box when the OK button is clicked. If you are not sure how to interpret the code, try moving the three sliders to see how the code changes in response to the revised settings.

I must admit that I had not paid attention to that bit of text before, focusing instead on the sliders With that said the configuration indicated in red letters looks correct with upper and lower case letters where they should be. This also appears to be stored to the temporary variables used for the immediate calculation.

However it is not reflected in the Nd field of the Input parameters after pressing 'OK'. All letters revert to lower case as mentioned in post #5152

The real culprit seems to be some subtle internal handling of character encoding when running Hornresp through Wine. No matter what configuration I select the resulting driver configuration description never contains an upper-case S or P. If I set the drivers to 2 series isobaric series pairs the Nd is given as 2s 2s.

The temporary internal variables used are updated correctly, enabling the simulation to run with the intended parameters for the duration of the session. However something seems to happen when the temporary variables are stored as part of the Input parameters which in turn are the parameters that are stored to file (educated guesswork on my part).

I have tried exporting my model and manually editing '2s' to an '2S' before importing it back into Hornresp but with no good results. I used Sublime text 2 to save the file with different character encodings (UTF-8 and variants of ISO 8859-1). All resulted in Nd being '2s' when the model was imported.

An isobaric configuration is indicated by a lower-case 's' (for series-connected) or 'p' (for parallel-connected).

I blame my ignorance on the fact that in my use Hornresp has consistently refused to store upper case letters for the Nd field. It does not have trouble storing, exporting or importing upper case letters in the Comment field

Personally, I find it very useful to be able to quickly reset a multiple driver arrangement back to a single driver.

As mentioned before I accept this as a deliberate design choice. It just seemed a little random to me before based on how I expected the program to work. No worries

I sincerely appreciate your responses David, as I realize I may have come across a bit over-eager to find fault in the excellent tool that is Hornresp.

Kind regards,

Øivind

 

[David McBean]

Hi Øivind,

The temporary internal variables used are updated correctly, enabling the simulation to run with the intended parameters for the duration of the session. However something seems to happen when the temporary variables are stored as part of the Input parameters which in turn are the parameters that are stored to file (educated guesswork on my part).

I have tried exporting my model and manually editing '2s' to an '2S' before importing it back into Hornresp but with no good results. I used Sublime text 2 to save the file with different character encodings (UTF-8 and variants of ISO 8859-1). All resulted in Nd being '2s' when the model was imported.

It seems that Wine cannot distinguish between 'S' and 's' (or 'P' and 'p') when used in the text string describing the driver configuration (which is copied into the Input Parameters text box and then subsequently saved to the permanent record).

A fragment of the relevant Hornresp Visual Basic source code reads as follows:

txtHp(27) = SeriesDrivers & "S"

where txtHp(27) is the string variable copied into the Input Parameters text box, and SeriesDrivers is the number of drivers connected in series.

If for example, SeriesDrivers = 2 then txtHp(27) should equal 2S, but in your case it becomes 2s.

I am wondering if changing the code as shown below, might fix the problem:

txtHp(27) = SeriesDrivers & Chr(83)

Where 83 is the ANSI code for "S" (the ANSI code for "s" is 115).

Perhaps Wine could distinguish between the two if Chr(83) and Chr(115) are used instead of "S" and "s". It won't make any difference to Windows either way.

I can quickly modify a test file and send it to you to confirm if the proposed change fixes the problem. If you would like me to do this, could you please send me an email that I can reply to - click on my name on the Hornresp download website.

I blame my ignorance on the fact that in my use Hornresp has consistently refused to store upper case letters for the Nd field. It does not have trouble storing, exporting or importing upper case letters in the Comment field

I can see how this could have made things very confusing for you. When everything works as it should, it becomes relatively easy to understand what is going on.

I sincerely appreciate your responses David, as I realize I may have come across a bit over-eager to find fault in the excellent tool that is Hornresp.

Not a problem - I am always very happy for users to report any problems that they may be experiencing with Hornresp .

If you would like to test the modified file, please let me know via email.

Kind regards,

David

 

[David McBean]

Hi Mark, Oliver and DrDyna,

Thanks for your inputs.

Kind regards,

David

 

[minkuni]

I am wondering if changing the code as shown below, might fix the problem:

txtHp(27) = SeriesDrivers & Chr(83)

Where 83 is the ANSI code for "S" (the ANSI code for "s" is 115).

Perhaps Wine could distinguish between the two if Chr(83) and Chr(115) are used instead of "S" and "s". It won't make any difference to Windows either way.

That does indeed sound like a possible fix. You've got mail.

 

[David McBean]

You've got mail.

Hi Øivind,

Now, so have you .

Please let us know if the source code changes make any difference. Thanks.

Kind regards,

David

 

[David McBean]

Now, so have you .

Unfortunately my email did not get through.

The Hornresp.zip file attachment size is 537 KB.

///////////////////////////////////////////

From: Mail Administrator
Sent: Tuesday, December 30, 2014 7:08 PM
To: David McBean
Subject: Mail System Error - Returned Mail

This Message was undeliverable due to the following reason:

Your message is larger than the destination computer is willing to
accept, so it was returned. The error message below indicates the
size of your message and the maximum size allowed by the receiving
E-mail system. You may be able to split your message into several
smaller pieces and have them delivered separately.

Your message was rejected by gmail-smtp-in.l.google.com for the following reason:

5.7.0 This message was blocked because its content presents a potential
5.7.0 security issue. Please visit
5.7.0 http://support.google.com/mail/bin/answer.py?answer=6590 to review our
5.7.0 message content and attachment content guidelines. t5si34684289pdh.70 - gsmtp

The following attachments have been removed from the bounce message: Hornresp.zip

///////////////////////////////////////////