No driver specs are real, just there is no value for mechanical resistance in the T/S parameters. All of the regular T/S parameters are there including CMS. The issue is that the RMS label is suggesting that a RMS value is to be put in the box (that is reasonable assumption) considering every program I have written where I want a value to be added has an appropriate label to suggest that, but newton sec / m is not what you would expect to put in a box for RMS, so either the RMS label is wrong, or the short description that appears below is wrong. I don't know what goes in the RMS box, it not a lack of having a value to put in there, just need to know what to put in there.
Just to clarify - Cms is not a Thiele-Small parameter.
newton.sec/m is the MKS unit for mechanical resistance Rms. The default record for example, has an Rms value of 4 newton.sec/m.
Rest assured, both are correct.
As GM says, with the record in Edit mode double-click on the Sd input box and enter the Thiele-Small parameter values for the driver you intend using. The electro-mechanical equivalents, including Rms, will be automatically calculated. Attachment 1 refers.
Alternatively, simply double-click on the Rms input box in Edit Mode and follow the instructions. Attachment 2 refers.
Attachments
TC Sounds might be disinclined to agree with you, but then they may have just included additional spec in that section. I don't know what is in standard specs to say one way or the other, just that TC Sounds have listed it that way indicating it is.
Every internet search I have done indicates that RMS is measured in watts, but if you are meaning the mechanical resistance of RMS, instead of power handling which seems to be the accepted meaning of RMS, then perhaps that label should say MKS?
Also if it is a derived number based on other T/S parameters, and not something that is listed on a driver sheet, then shouldn't that field be a label or a non editable text box if the user isn't supposed to directly enter a value in there?
From a non advanced user perspective isn't the goal to make it as easy to use as possible?
This seems straight forward enough once you know this is what is required to enter a value, but again it is not intuitive for the user.
That is assuming you can get into edit mode... When you first install Hornresp and come up to the main screen you can't edit the default driver because it is disabled / greyed out. So like any new user might you use the wizard to create a new speaker (since there is a note on load up now), then once you have done that and come back to the main screen, the edit button is still disabled / greyed out. It is only after you click Previous to go back to the first record, then click Next to go to your current record that the Edit button becomes enabled / usable. It is only because I write code myself that I instinctively did that.
Surely if the intent is to make the user press the Edit button (which isn't at all obvious) first before entering any parameters, then all text boxes should be disabled to stop people doing what I just did, which is instinctively to put text in an enabled text box.
Why is there a need to press Edit anyway? Normally you would have a greyed out Save button that when any value of a text boxes changes the Save button becomes enabled allowing the user to save the record (or not). It's the little things that are stopping it from being a go to app. I have been trying this app periodically for I don't know how many years now and while there are more features, it has only gotten marginally easier to use.
I don't doubt that once you navigate the nuances of the program it is a great program, it is just the lack of user friendliness and adequate help (with pictures) that stops it from being a brilliant program.
You are confusing RMS as Root-Mean-Square, with the loudspeaker parameter. Root Mean Square is not measured in watts, but is a method to calculate something. See https://en.wikipedia.org/wiki/Root_mean_square for instance. It can be used for instance to find the heating power of an AC voltage. It is basically equivalent of the DC voltage that produces the same heat in a resistor as the AC voltage.
RMS for loudspeakers is the mechanical resistance of the suspension. It stands for Resistance, mechanical, small signal, and usually MS is a subscript. That is not always easy to make happen in a field label in a program.
I'm sure more people would help you if you stopped asking questions like "your program is a piece of crap, tell me how to use it". The Hornresp community also expects a bit of user friendliness
RMS for loudspeakers is the mechanical resistance of the suspension. It stands for Resistance, mechanical, small signal, and usually MS is a subscript. That is not always easy to make happen in a field label in a program.
I'm sure more people would help you if you stopped asking questions like "your program is a piece of crap, tell me how to use it". The Hornresp community also expects a bit of user friendliness
It is a brilliant program.
Most of all: it's free.
plus you can get direct support from the author himself!
If you expect it to be an incredibly easy to learn and intuitive tool then maybe it's not for you. There are other easier tools but they usually lack the versatility.
I can just tell you from my experience, once you understand the way hornresp works (that might take some time) it is very smooth to use.
Here is a typical example of what RMS means to the average non technical person. https://www.techjunkie.com/rms-speakers/
Which says exactly what I have known it to mean my whole life. That RMS is music power measured in watts, now if it has another technical meaning then perhaps that might be explained to the non rocket scientists in plain simple language, instead of being surrounded in mystery.
I'm sure more people would help you if you stopped asking questions like "your program is a piece of crap, tell me how to use it". The Hornresp community also expects a bit of user friendliness
I don't believe it is a piece of crap, I do believe it is incredibly hard to use, and is not user friendly in the slightest, that is a long way from thinking something is crap. If it was crap I wouldn't have spent probably the last 10 years trying to get it to work. I keep trying it from time to time hoping it was going to get usable.
This is what I believe the program could be with a tiny bit of effort. Two parameters (Fs and Sd) and it spits out plans for a box. http://www.mh-audio.nl/Calculators/TML.html that is what a program should be. I have written programs myself that have been complex in nature but simple to use. Programs don't need to be complex, programs don't need to be difficult to use, programs don't need to need to perform miracles to enter simple data, yet here we are...
It should not require you to do hours of research to find out what every single acronym means, or go to university to get a masters degree in math.
i.e. CMS 4.00E-04 what the heck does that mean to someone that hasn't been to school for over 40 years? No where on any data sheet are you going to find that number. What you are going to see is 1125.4 um/N. Where is the unit selector so you don't need to try and convert to m/N the program requires?
These are the sort of things that make it easier for a user to use a program, not more features. In code it is generally a couple of lines of code to turn one value into another. But plenty of research trying to make sure the formulas you find online agree with each other.
Any program that is so complex and difficult to use to the point you can't get a usable result is kind of useless, no matter how fully featured it is. I am not a stupid person, I am just frustrated that I can't crack the magic code of secret buttons to press to get the hidden door to appear.
Just trying to create a new box I am having to go into a dat file and pick out the default driver, so when it creates a new box it does it with the driver I need and not some driver I don't, this is insanity that I should need to do that to forgo all the button pressing to get the right driver to show up. There should be no driver parameters on the main page, you should be able to open or create a driver on a sub menu and load it. just like every other program does.
I am a masochist for continually trying to get it to work. I need to stop torturing myself and realize it is never going to get easier to use. Can anyone recommend an easy to use program that gets results?
There is no reason for it to be complicated. If I had all the formulas to make it work I could write the same program that a five year old could operate. It is not complicated because it is difficult, it is complicated because it is complicated.
As I say even selecting a driver is 10 times more complicated than it needs to be and when you do create a box it uses a different driver to the one you expect. That has absolutely nothing to do with understanding speakers, that comes down to a poorly designed graphical user interface.
I have already paid for Bass Box Pro so I am not afraid to spend the money if the program works well. What I see in this program is the potential for it to be better than many of the others out there, I just need it to be user friendly and tell me what it is I am selecting so I can make informed decisions and have some confidence that if I made a box using the information that it would turn out as intended. Currently I can't even get a design out of it, let alone have confidence in that. I just wish BBP6 had some better box options.
There is.
as far as i know david focuses on the functionality and accuracy of simulations rather than developing the GUI. I am glad it's happening that way.
Maybe you could contact david and work on a new user interface yourself?
Edit:
Did you see what @Brian Steele and @LORDSANSUI did, developing excel and freecad "plugins" that work in combination with hornresp?
Been there done that. A couple of years ago I put together a mock up program replicating this program demonstrating how it could be done to make the whole thing a lot easier to understand (without removing any functionality, in fact I added a bit to simplify things). David said himself that it was good, but you can only lead a horse to water you can't make it drink. David doesn't appear to be interested in making the program more usable, and as a programmer that is his prerogative to do so.
But after 12 years of waiting for it to get more usable it is time I finally accepted that the program is never going to be user friendly, and that is really disappointing because it could be so much more than it is. I will never know if it is as good as I think it is (maybe it isn't) but I'm never going to know, but to all those that said this program was free over the years, it's has not been, it has cost me a lot of time for zero return, so it is time to cut bait on this one.
Before I go I do want to sincerely thank everyone that attempted to genuinely help over the last 12 years. This without a doubt is the most helpful out of any audio forum I have come across. Being that I suffer mental issues that make it hard to express certain emotions, I hope my gratitude is coming across with the deep sincerity in which it is made.
Sorry, but I am with @Silent Screamer on this.
Free or not doesn't change how easy or good a program is.
That's just 100% the subjective choice of the developer of any program.
That's just nothing more than a plain objective observation.
I have learned to find my way around it by now.
David said many times that he doesn't feel like changing the entire thing after so many years.
Which I think is totally understandable! 👍
But yeah, I can totally see how that can be very frustrating for people with the right skills.
Unfortunately it seems to be a standard in engineering to make programs with a interfaces that lack good intuitive interfaces lol 😄😆😂
I basically don't know any.
Fyi, again that's just an observation and NOT any critique towards the incredible amount of time, work and effort that has been put into it!!
The problem is that many of these explanatory pages dumb tings down to make it accessible to the average person who is just interesting in comparing numbers for products they are buying. Such pages are often not very helpful if you're looking for the enough technical info to design and build stuff, and sometimes they are plain wrong because they just use the everyday meaning of a term, not the actual definition. Wikipedia would be a better place to start looking.
As I said, the RMS voltage is the voltage that heats a resistor the same amount as a DC voltage with the same value. I think there has been long debates over if you can really say Watts RMS, because the power dissipated has to be calculated based on the RMS voltage or current. But RMS by itself is not power, voltage or anything else, it's just a way of calculating something. It's like saying peak-to-peak. Is that measured in volts, amperes, ohms, coulombs or pascal? It doesn't say, you have to specify that. Likewise, if you talk about RMS power, that's measured in watts, but RMS itself has no unit per se.
As for speaker parameters, it took me just a few seconds to find this page: https://en.wikipedia.org/wiki/Thiele/Small_parameters by searching for "rms loudspeaker parameter". It seems to have pretty good explanations of every parameter.
I'm not saying that what you said isn't right, just that I and probably 99% of the speaker building population would not associate any other meaning than the one that is outlined there in that simple article. So whether it is right or not is not the issue, the underlying issue is that if you have an advanced knowledge compared to the average person, or if the average person is under a completely different understanding, then you need to educate the user in a way that is clear enough for them to see that they have been mislead their whole lives, not just stick it up there and expect everyone to know or accept it. They have had a life time believing it, change wont come easy.
Most programmers I know hate with a passion doing help files, they want to type code. Often many programmers are not very good at articulating complex subjects in a way the layman can understand. They think they are explaining in English, but in reality they are still talking in a jargon that not many people understand. In a previous life I was a senior licensing specialist and the 200+ pages of licensing rules that I used frequently changed (probably 200+ products and 10 different channels to buy them, and no two exactly alike), I knew them like the back of my hand and could tell you what page the rule appeared on, but what was so obvious to me trying to explain it to a small / large business person who is just at the conference to get licensed properly and keep their door open would often be met with blank stares or complete lack of comprehension. But why didn't they understand it was SO SIMPLE.
Probably the worst people to write help files are the ones that know the subject best, because they have forgotten how to communicate at a level beginners can understand. I don't know who the person is behind this website but they explain complex things in a very simple way without a lot of confusing jargon. This is what a good example of a help file would look like. http://www.mh-audio.nl/SpeakerGlossary.html
When I design a GUI I try to make it idiot proof (having said that there are some very talented idiots out there). First thing I do is NOT over crowd the page. Keep only information that absolutely has to be there in view at any one time. To give you an example once the appropriate driver has been chosen there is no reason whatsoever for it to be displayed. The parameters of the driver aren't going to change suddenly. So the only thing that needs to be on that screen is the name of the driver being used, and maybe some real basic information tucked away in some small corner, or a form header. Removing half the information on the main page takes away the overwhelming feeling out the situation.
I try and make it so that you can't choose a wrong option by controlling what can be accessed when and where. I will often even take items off the screen to remove confusion. If an option is not applicable then remove it off the page until it is needed. Simple done by using the visible object control. Description links that are a single line can be multiple lines now to go into high level detail because there is freed up screen space. There are lots of ways to make things simple without compromising the quality of your app.
Last edited:
I agree, as a coder myself I don't like writing help files Having tried to use some of the open source simulation software, it seems that people usually don't want to do it unless they're paid. These packages often tell you what the parameter or function is, but not the context of how it influences the simulation or when to use it and why. But help files must be written, and in a good way. Hopefully I will be able to do it for the SW I'm working on.
The speaker glossary you link to looks like a good one. It also has the correct definition of the Rms speaker parameter
Having tried to use some of the open source simulation software, it seems that people usually don't want to do it unless they're paid. These packages often tell you what the parameter or function is, but not the context of how it influences the simulation or when to use it and why. But help files must be written, and in a good way. Hopefully I will be able to do it for the SW I'm working on. The speaker glossary you link to looks like a good one. It also has the correct definition of the Rms speaker parameter
Nofi, but most I know think that every single person on this planet is fluent in at least 4 different programming languages, has no trouble understanding very complicated abstract problems and can blindly understand all Linux problems.
Therefore the majority think that manuals are not needed to begin.
Relying on manuals is a poor implementation and excuse to begin with in my opinion. A good interface shouldn't need any steep learning curve.
That only highly distracts from the goal of the program itself.
A lot of courts or other official instances don't even consider manuals as something legally liable.
Which on itself speaks.
Could agree more the problem is that a lot of programs start with an adhoc idea, or develop feature creep, as it is being written, rather than proper pseudocode / UML at the beginning. This leads to poorly planned code and usually results in a poor GUI layout. The better thought out it is at the start the easier the program should be to use if it is done right. I've used some very expensive software programs that has been complete garbage. You can't help but wonder what they were thinking when they coded them for them to turn out so badly flowing.
Good Lord, I hope no-one is actually using that program. Just because it's simple doesn't mean that it's good. Hint - any box-modeling program that doesn't require at least the three basic t/s parameters (Vas, Fs, Qts) is likely going to produce results that have little or connection with reality.
That is one of the drawbacks with acronyms - sooner or later you'll run out of unique labels. Your confusion stems entirely from the fact that Rms and RMS are too similar and you erroneously assumed that both mean the same thing in this context. One could just as easily be confused by Cms and cms (centimeters). I constantly have to keep looking up the full forms of the abbreviations for speaker types etc. that are used on this forum (e.g. CB is closed box, not constant bandwidth or even citizens band).
What makes the study of loudspeakers so daunting (and applications like Hornresp so complicated) is the sheer number of unique parameters involved. Even in a simple CB (closed box) simulation, there are a number of assumptions that a 'user-friendly' program makes for you, assumptions that might not be what you expect. If you want more control over the assumptions, you make things more complicated - that's a fact of life. And even Hornresp isn't the last word in this field - it is terrific for getting you into the ball park but for many things one does need more advanced simulators - COMSOL is one which springs to mind, but if you think that's easy, boy, have you got a surprise coming.
There seems to be quite a bit of confusion between hard to use and hard to comprehend. Yes introducing more variables does make things more complex, but that doesn't automatically mean that it needs to be harder to use.
Lets look at virtually any program you might have installed on your computer. Let pick one at random... "Word".
99% of programs out there all select a document or whatever (a speaker driver) by going up to File, then Open. This is the industry standard way to do it. I've probably been doing it this way for at least 30 years on Windows programs, we are all well acquainted with this method. I don't need to give you instruction how to open a Word document in Microsoft Word, or Libre Office or what other programs that are out there because it is ingrained in they way the industry does it, therefore unless this is the first time you have laid eyes on a PC you can do it almost without thinking.
This represents the simple way. If I put the file open under the hambrger icon (three dashes) and I call it Extract instead of Open I have immediately made the program harder to use without changing a single thing to the functionality of it. This is what most people don't seem to be getting.
As I highlighted in an early post having to press Previous, then pressing Next to get the Edit button to be active is adding complexity for zero reason. (On top of which there should be no Previous or Next buttons on the screen)
The other major point I was making is that there is no reason that you should have a configurable driver parameters on the same page as box parameters, they have absolutely nothing to do with each other. A box relies on the data from the driver parameters, but it does not directly interact with the driver parameters (it is a fixed object there is nothing configurable at the point of use). So these two items should be completely separate.
If I am in Paint I want on the page of my drawing all the things I can use i.e the eraser, lines, circles etc etc, I don't need on that valuable real estate a button to a help file, a link to an internet site, or a open jpeg file. When the action has been performed once it is out of sight it should be out of mind. All I want to make my Paint program simple is anything that is going to modify my drawing. Anything that is not essential is adding to the confusion. I may want to know what file I am working on, so you simply put the jpeg file name in the frame header, it is not taking up valuable real estate, it is not adding to visual confusion. Same could be done for a few simple driver specs. If you really must see the driver spec have a pop up window that shows the specs then goes away.
If you need to select a driver you go to File / Open which then opens a window that contains only drivers, or if the programmer is feeling generous they may allow you to select one from a database.
If you need to edit a file you click on Flie / Edit, a simple easy way to know what you are working on at any given time. When you create or save something you know without any doubt whether you saved it or not. This is what simplifies a program without changing any of its functionality.
I honestly don't think that Hornresp needs to be any more complicated than something like BBP6 if it was properly laid out to begin with. The problem is there is little logical grouping going on (now better than it was), and trying to stack too much information on one screen which leads to information overload. I don't know if this is deliberately done to give the illusion it is something special and only people who think a certain way can understand it, but from the perspective of someone who writes code to make applications as simple as they can be while being full featured, that is what it looks like to me.