Hornresp Update 5040-190824
Hi Everyone,
CHANGE
Following on from the recent release of Version 50.40, a number of minor "loose ends" have now been tidied up.
One small enhancement is that when the loudspeaker wizard is used with an unbaffled direct radiator, a direct radiator in a flat open baffle, a direct radiator in a H-frame open baffle or a direct radiator in a U-frame open baffle, double-clicking on the schematic diagram now shows the positions of the dipole acoustic centres (see attachment). Pressing the Esc key hides the acoustic centres.
BUG FIX
A single-segment compound horn with stepped segments specified, would generate a fatal overflow run-time error when opened in the loudspeaker wizard. This problem has now been fixed.
Kind regards,
David
Hi Everyone,
CHANGE
Following on from the recent release of Version 50.40, a number of minor "loose ends" have now been tidied up.
One small enhancement is that when the loudspeaker wizard is used with an unbaffled direct radiator, a direct radiator in a flat open baffle, a direct radiator in a H-frame open baffle or a direct radiator in a U-frame open baffle, double-clicking on the schematic diagram now shows the positions of the dipole acoustic centres (see attachment). Pressing the Esc key hides the acoustic centres.
BUG FIX
A single-segment compound horn with stepped segments specified, would generate a fatal overflow run-time error when opened in the loudspeaker wizard. This problem has now been fixed.
Kind regards,
David
Attachments
One minor change I'd like to see....
It looks like Hornresp keeps the data file open (hornresp.dat) while the program is open. I've got Hornresp loaded on my main PC and my testing PC, and they've both configured to use the same copy of Hornresp off of OneDrive. Because Hornresp locks the data file for writing while the application is open, I can run into issues saving updated sims on the test PC if I leave Hornresp open on my main PC. Can Hornresp be reconfigured to lock the data file only if it's writing to the database?
It looks like Hornresp keeps the data file open (hornresp.dat) while the program is open. I've got Hornresp loaded on my main PC and my testing PC, and they've both configured to use the same copy of Hornresp off of OneDrive. Because Hornresp locks the data file for writing while the application is open, I can run into issues saving updated sims on the test PC if I leave Hornresp open on my main PC. Can Hornresp be reconfigured to lock the data file only if it's writing to the database?
Attachments
Hi Brian,
Unfortunately the way that the program has evolved, it would not be a minor change, and I am concerned that it could inadvertently affect the current "stability" of the Hornresp.dat file. As recently mentioned the file has proven to be remarkably resilient in the face of some very harsh treatment, and I don't want to do anything that could potentially jeopardize this enviable record. I am a great believer in "letting sleeping dogs lie". In other words - it's not going to happen
.Kind regards,
David
I'd suggest you install a remote desktop app - team viewer et. al. - on both computers. Then from wherever you are, you can log into your other computer and shut down Hornresp.
I have the same "issue" as Brian - having hornresp on Dropbox which is connected to several PCs (at home, on the mobile Laptop, at work, etc..)..
In order to have a program access data files from several locations at the same time without loosing information in the access file, some sort of database access would be a solution - otherwise each copy of hornresp open at the same time would have to check all the time, if a change in the data file has happened. This is not a simple task and requires a lot of features on the programming side. So I totally get, why this is "not going to happen"
My "workaround" is to simply try to remember to close hornresp everytime I have been using it If I forget, I end up loosing my recent records, depending on which machine did the last "saving" on the file (which then is automatically synced to all others, overwriting all other versions)... I am getting better at not forgetting
One small "safety feature" that could help in usecases like this: If hornresp writes a zero byte file with nothing in to the hornresp directory as long as its running - and deletes it when it´s properly closed - hornresp could simply check on startup if this file exists and give a warning message (or even refuse to start)... The file could be called "datalock.tmp" (or whatever ) .
In order to have a program access data files from several locations at the same time without loosing information in the access file, some sort of database access would be a solution - otherwise each copy of hornresp open at the same time would have to check all the time, if a change in the data file has happened. This is not a simple task and requires a lot of features on the programming side. So I totally get, why this is "not going to happen"
My "workaround" is to simply try to remember to close hornresp everytime I have been using it
If I forget, I end up loosing my recent records, depending on which machine did the last "saving" on the file (which then is automatically synced to all others, overwriting all other versions)... I am getting better at not forgetting One small "safety feature" that could help in usecases like this: If hornresp writes a zero byte file with nothing in to the hornresp directory as long as its running - and deletes it when it´s properly closed - hornresp could simply check on startup if this file exists and give a warning message (or even refuse to start)... The file could be called "datalock.tmp" (or whatever
) .I too am a multi-pc household and have hornresp on my lan.However I work on only one pc at a time so issue does not occur (apart from one laptop with a unusual keyboard.(wont run hornresp at all.)) Personally I think David has done a wonderfull job with hornresp and would much prefer his time to be spent on the nuts n bolts of the program itself.I therefore support his opinion of it :>`aint gonna happen`.!!
One small "safety feature" that could help in usecases like this: If hornresp writes a zero byte file with nothing in to the hornresp directory as long as its running - and deletes it when it´s properly closed - hornresp could simply check on startup if this file exists and give a warning message (or even refuse to start)... The file could be called "datalock.tmp" (or whatever
Unfortunately, if Hornresp crashes and leaves that file in place, then it will give that warning message the next time you start it, and you'll need to know to manually delete that tmp file in order for Hornresp to start normally.
The original method I proposed for storing the Hornresp records addresses this and other issues (e.g. using the INI config file format will allow for much easier interchange between apps, makes the sim parameters easily readable, the record for the sim would not have to have a fixed size, and you can add notes with a text editor without borking the data). However, it will likely require a bit of work to put in place and David's said that it's not going to happen
.Hi David, first of all, thanks for all the effort put into the program! I started getting Run-time error '75': Path/file access error when trying to add a new record. In the past, it usually helped to remove the hornresp.dat file - but now I am getting the error all the time. I have the latest version and Windows 10. I can zip the whole folder and send it to you if that helps finding the problem. A new fresh install works normally again.
Exactly, you end up with a seperate file with the extension "in conflict,.." (or something like that, it´s in german here).
@pelanj
Did you try downloading the most recent version of hornresp and extracting it in a new, clean directory?
Yes, that´s right. No easy solution is perfect. Deleting a file after a crash is something people should be able to handle. Dealing with corrupt record files or trying to merge several "in conflict" copies seems more difficult to me.
Besides: hornresp never crashes
I am fine with the way it is, I just threw in some thoughts.
Yes, I agree, this would be more elegant.The original method I proposed for storing the Hornresp records addresses this and other issues (e.g. using the INI config file format will allow for much easier interchange between apps, makes the sim parameters easily readable, the record for the sim would not have to have a fixed size, and you can add notes with a text editor without borking the data). However, it will likely require a bit of work to put in place and David's said that it's not going to happen
And I totally respect why it´s not going to happen
Besides: hornresp never crashes
I've had it crash out a few times, primarily when editing early bandpass sims. Looks like something changed, making the old sims unreadable. They were only test sims though, so I just deleted them.
The data file remains intact I think because Hornresp only writes to it when you exit the program, where it prompts you to save the changes.
Hi pelanj,
Thanks for the feedback.
I am not sure why you are experiencing problems when you click the Add button. The latest version of Hornresp should work just fine with Windows 10.
If the Hornresp.exe, Hornresp.hlp and Msvbvm60.dll files are all located in the C:\Hornresp folder, as recommended in the Readme.txt file, then when Hornresp is first run it should create a sub-folder named Data under C:\Hornresp and automatically generate a Hornresp.dat file in that folder, containing just the default record. It should then be possible to add further records to the Hornresp.dat file without any problems.
You could perhaps try the following to see if it helps:
1. Move your existing Hornresp.dat file to a temporary folder somewhere.
2. Delete all other existing folders and files on your computer associated with Hornresp.
3. Create a C:\Hornresp folder.
4. Copy files Hornresp.exe, Hornresp.hlp and Msvbvm60.dll into the new C:\Hornresp folder.
5. Run Hornresp.exe then close it down again.
6. Check that the Data sub-folder has been created under C:\Hornresp and that it contains a Hornresp.dat file.
7. Replace the Hornresp.dat file in the Data sub-folder with your existing Hornresp.dat file from the temporary folder.
8. Delete the temporary folder.
If you do decide to try the above, could you please let me know if it fixes the problem. Many thanks.
Kind regards,
David
Hi Brian,
As mentioned in an earlier post there were some issues at one stage with filter data not being saved correctly. It took a while, but the problems were eventually tracked down and resolved. Hopefully you are not experiencing crashes with your more recent records. If you are, then feedback on specific instances would be greatly appreciated.
Kind regards,
David
Hi David,
it seems the problem was with the Drivers folder - I was not able to delete it - it reported it was used by some application - maybe an incorrectly terminated Hornresp session?
I do not restart the computer very often and use hibernation instead. Maybe that was also a part of the problem.
So it is a thing that can be easily worked around.
it seems the problem was with the Drivers folder - I was not able to delete it - it reported it was used by some application - maybe an incorrectly terminated Hornresp session?
I do not restart the computer very often and use hibernation instead. Maybe that was also a part of the problem.
So it is a thing that can be easily worked around.