As you can see in the other thread, it would be extremely useful to be able to use the separate modules together, for example, view filtered response and driver power together. Or filtered response and velocity together. There's been a bunch of times I could have used that. Or capture filtered response and compare against other sims. There's so many things that could be done if the modules could be used with the other features of the program.
And while I'm making (most likely) unreasonable suggestions, it would also be nice to do an Od hyp-ex sim. I have no idea how difficult it would be to implement any of this stuff.
There's always Akabak, I know, but it would be really nice to be able to do this stuff in Hornresp.
And while I'm making (most likely) unreasonable suggestions, it would also be nice to do an Od hyp-ex sim. I have no idea how difficult it would be to implement any of this stuff.
There's always Akabak, I know, but it would be really nice to be able to do this stuff in Hornresp.
Last edited:
+1 to the suggestions above...I would find all of that very useful especially the ability to capture filtered response and compare.
Also here is my unreasonable wish. I'd like to be able to simulate 8th order BP in HR. I can in ABEC3 or Akabak or a much older unsupported software but I really prefer HR for the ease of use, quickness and general awesomeness. That is about the only design type I can't seem to at least approximate in HR.
Ok. I'm done.
Also here is my unreasonable wish. I'd like to be able to simulate 8th order BP in HR. I can in ABEC3 or Akabak or a much older unsupported software but I really prefer HR for the ease of use, quickness and general awesomeness. That is about the only design type I can't seem to at least approximate in HR.
Ok. I'm done.
IDEA !
As several people have expressed their wish that HR could open multiple windows at once, i had the idea of opening more than one instance of HR @ the same time.
In order to try & achieve this, i first needed to copy/paste the Full HR Folder to another location & then rename the new Hornresp.exe to Hornresponse.exe. This worked up to a point, as Hornresponse.exe did run, but the records didn't show when trying to import one.
I even copy/pasted Hornresponse.exe etc to another partion on my hard drive, but still got the same result.
Maybe others could experiment with different methods & see what they might be able to do
If DB could find a way "tickle" the code so it could be done, then great
As several people have expressed their wish that HR could open multiple windows at once, i had the idea of opening more than one instance of HR @ the same time.
In order to try & achieve this, i first needed to copy/paste the Full HR Folder to another location & then rename the new Hornresp.exe to Hornresponse.exe. This worked up to a point, as Hornresponse.exe did run, but the records didn't show when trying to import one.
I even copy/pasted Hornresponse.exe etc to another partion on my hard drive, but still got the same result.
Maybe others could experiment with different methods & see what they might be able to do
If DB could find a way "tickle" the code so it could be done, then great 
Yeah, I've got 4 or 5 Hornresp folders in different places that I use for different things, and all instances will run at the same time if I want them to. I've had 4 instances running side by side in the past.
I'm not sure anyone requested opening multiple windows at once though, just need the different features of the program to work with each other.
I'm not sure anyone requested opening multiple windows at once though, just need the different features of the program to work with each other.
Hi just a guy and Josh,
Sorry, it's not going to happen
.Unfortunately it would require just too much work to implement the suggested enhancements using the existing Hornresp code architecture and input constraints, and there are simply not enough years left in me to consider a major re-write at this time, bearing in mind that I would be using what is now in effect an obsolete programming package (Microsoft Visual Basic 6).
Kind regards,
David
Hi just a guy and Josh,
Sorry, it's not going to happen
Kind regards,
David
NNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!
I figured as much. No harm in asking.
No ask, no get!
Asked and received an answer!
I have another side line question. Keep in mind this is from a guy with no current programming skills. My programming experience stopped with BASIC and TURBO PASCAL.
Given that visual basic is a dead language, can Hornresp be ported over to something that has a longer shelf life?
Asked and received an answer!
I have another side line question. Keep in mind this is from a guy with no current programming skills. My programming experience stopped with BASIC and TURBO PASCAL.
Given that visual basic is a dead language, can Hornresp be ported over to something that has a longer shelf life?
I've done a few apps in VB6. It wasn't that difficult to change them over to Visual Studio Express, which is a free download from MS.
Hi Brian,
Even in Visual Studio Express, much of the Hornresp code would still have to be re-written to accommodate the suggested enhancements. That is the bit that concerns me
.Kind regards,
David
I was wondering how the program takes into account drivers position in case you set up a number oh drivers equal to 2? I am trying to simulate a tapered TL (similar to the Thor design of D'Appolito) with two drivers and trying to find out if hornresp accounts for driver positions in this configuration.
"Shelf Life" is not a PL parameter
VB is alive and well; and like most languages in use to today, it has a very long pedigree and an very large inventory of applications to match. You can not program a computer beyond the capability of its instruction set. Most compilers, old and new, block you from getting close to it, except C and its derivatives, and of course, Assembler. Unless you have a compute bound problem, the OOP Language you are used to using, will be the one most developmentally efficient for you. There must be a compelling reason for dealing with the steep learning curve and other problems associated with a port of an established, well experienced program, to a new language and/or development platform. Most of the user interface is implemented through calls to the Windows API; so even here, opportunities are constrained by the oldest OS version most people are using. Bottom line: dealing with matters acoustic and mathematical are far more daunting (and important), than getting around the limitations of a particular HLL or OS API. In extreme cases were computing efficiency is at issue, write subroutines in C or Assembler for the 32 and 64 bit MPU's you expect will be used.
Regards,
WHG
P.S. Hi David,
I see a lot of requests being made here, but no offers to make a contribution. WHG
VB is alive and well; and like most languages in use to today, it has a very long pedigree and an very large inventory of applications to match. You can not program a computer beyond the capability of its instruction set. Most compilers, old and new, block you from getting close to it, except C and its derivatives, and of course, Assembler. Unless you have a compute bound problem, the OOP Language you are used to using, will be the one most developmentally efficient for you. There must be a compelling reason for dealing with the steep learning curve and other problems associated with a port of an established, well experienced program, to a new language and/or development platform. Most of the user interface is implemented through calls to the Windows API; so even here, opportunities are constrained by the oldest OS version most people are using. Bottom line: dealing with matters acoustic and mathematical are far more daunting (and important), than getting around the limitations of a particular HLL or OS API. In extreme cases were computing efficiency is at issue, write subroutines in C or Assembler for the 32 and 64 bit MPU's you expect will be used.
Regards,
WHG
P.S. Hi David,
I see a lot of requests being made here, but no offers to make a contribution. WHG
Last edited:
Look harder. Several people have offered financial contributions and several people are always willing to help whenever they can be useful.
I spent a few hours compiling stuffing data that was used for the program a couple years back and I'm always willing to help in any other way I can.
Anyway, requests are also a form of contribution. I've made dozens of requests over the years and many of those have been integrated into the program, and the program is better for it (and I am very greatful).
Unfortunately David won't accept financial contributions and doesn't often need any other kind of help so there's not much else we can contribute.
Last edited:
Object: Contribution -> Function: Request/Offer/Accept/Make
"Anyway, requests are also a form of contribution."
Certainly you jest! In this context, it is David that is being asked to make the "Contribution" not the other way around.
Anyway, Intellectual/Financial contributions are not the ones I had in mind.
However, there is nothing wrong in making them, even if they are turned down. It is coding/debugging contributions, the 'grunt-work' if you like, that would make David's maintenance programming task a lot easier.
VB source code is not hard to write and debug when done in small modules at a time. Such can be accomplished in nothing more than an Excel spreadsheet with the Developer/VBA tab turned on. Once complete, incorporating such work into a much larger work, such as David's, is a straightforward minimally time consuming task.
In any event, all the offers remain several magnitudes smaller than the requests made here.
Regards,
WHG
"Anyway, requests are also a form of contribution."
Certainly you jest! In this context, it is David that is being asked to make the "Contribution" not the other way around.
Anyway, Intellectual/Financial contributions are not the ones I had in mind.
However, there is nothing wrong in making them, even if they are turned down. It is coding/debugging contributions, the 'grunt-work' if you like, that would make David's maintenance programming task a lot easier.
VB source code is not hard to write and debug when done in small modules at a time. Such can be accomplished in nothing more than an Excel spreadsheet with the Developer/VBA tab turned on. Once complete, incorporating such work into a much larger work, such as David's, is a straightforward minimally time consuming task.
In any event, all the offers remain several magnitudes smaller than the requests made here.
Regards,
WHG
Not even a little bit.
A couple of things I exclusively requested were Driver Power and one component of Diaphragm Pressure. A couple of things that many people requested (myself included) were Filling (stuffing), the Filter Wizard and adding sliders to everything, not just the Tapped Horn Wizard (which became the Loudspeaker Wizard). All of these (with the exception of stuffing) are exclusive features not seen anywhere besides Akabak, and in the case of the sliders not even in Akabak. These features have made Hornresp an exponentially better program (especially the Filter Wizard), and some of these things probably never would have been added if not requested. I see this as a valuable contribution. It's not coding or debugging but few of us are programmers. If you are a programmer why aren't you volunteering?
Also consider the fact that since few of us are programmers and none of us know how this is coded, we have no idea whatsoever how much work any given request will be. I'm pretty sure that in at least a few cases the requests are pretty simple to add, just a few lines of math, a few lines of code, a new graph. But I'm not a programmer so I really don't know.
I'm looking at over 500 pages of feedback in this thread alone and countless more in this forum and around the internet which serves many purposes like quality control, bug finding, theoretical discussion on the purpose and functionality of features and yes, even feature requests. If you think there's no value in any of this you are delusional.
I think you are trying to imply that as a group we are ungrateful and unwilling to help and I resent that. This is by far my favorite and most useful and used simulator and I'd do anything I could to help, I've made that very clear at least a few times.
But this isn't what this thread is for so I'll leave it with this thought - part of the reason this program is so ubiquitous is because the users love it and promote it everywhere and every chance we can and there's value in that too. If David were programming for an audience of one (himself) Hornresp may not be what it is today. I'm not trying to take any credit here, all credit is due to Mr McBean, but an important part of any famous institution are it's fans. So please don't try to imply that we are ungrateful or unwilling to help any any way we can. I'm not a programmer and there's only so much I can do. For the most part he has it all under control and doesn't need any help. I would assume he would ask for help if he wanted it.
Last edited:
Hi PKI,
Bill (WHG) has summarised the situation very succinctly.
As far as Hornresp is concerned, multiple identical drivers are assumed to act as a single composite driver, with the driver parameter values being automatically modified by the program as necessary. When the drivers are located close to each other acoustically (which is usually the case with bass systems, where the wavelengths are relatively long) the composite driver model can be surprisingly accurate.
If you are using the OD option in Hornresp, then the composite driver is assumed to be located at S2, the same as for a single driver.
Attachment 1 shows a tapered transmission line loudspeaker system with a single driver.
Attachment 2 shows the same system but with two drivers. The diaphragm area is shown to be twice that of a single driver.
Parameter values for a composite driver are calculated as follows:
Sd = Sd1 * SeriesDrivers * ParallelDrivers
Cms = Cms1 / (SeriesDrivers * ParallelDrivers)
Mmd = Mmd1 * SeriesDrivers * ParallelDrivers
Re = Re1 * SeriesDrivers / ParallelDrivers
Bl = Bl1 * SeriesDrivers
Rms = Rms1 * SeriesDrivers * ParallelDrivers
Le = Le1 * SeriesDrivers / ParallelDrivers
Where SeriesDrivers = 1 and ParallelDrivers = 1 for a single driver, and Sd1, Cms1, Mmd1, Re1, Bl1, Rms1 and Le1 are the parameter values for a single driver.
Kind regards,
David
Attachments
Hi Bill,
Not a problem
.Suggestions for new features, bug reports, assistance with testing, general comments and observations, etc, are all very valuable user contributions.
Kind regards,
David