Transmission Line Modelling Software

If you would like I could knock up a quick GUI (no code) for you to take a look at and see if it warrants a change. If you decide it doesn't I won't be offended. As a programmer we have to be happy with our own creations, but for me, being a visual person, seeing different options helps me decide what I like and what I don't.
 
Had nothing better to do so I started mocking up what I might design if I was doing it...
 

Attachments

  • 5.png
    5.png
    22.8 KB · Views: 448
  • 4.png
    4.png
    32 KB · Views: 432
  • 3.png
    3.png
    34.6 KB · Views: 374
  • 2.png
    2.png
    35 KB · Views: 378
  • 1.png
    1.png
    25.3 KB · Views: 441
  • Like
Reactions: 1 user
Had nothing better to do so I started mocking up what I might design if I was doing it...
Wow, that's amazing, what you have done in less than a day would take me ages to come up with :).

Just to clarify what for some reason seems to be a very common misunderstanding, the driver parameters you show as Thiele-Small parameters are actually the electro-mechanical parameters of the driver, with only Sd and Re also being T-S parameters.

Driver Thiele-Small parameters are:

Sd
Re
fs
Vas
Qes
Qms
Qts

With regard to the GUI, one key thing that I wanted was for all the main parameters to be on a single window screen, so that they could be seen at a glance whether viewed directly, as a screenprint, or as a hard copy printout (as shown in the attachment).

The main input parameters window layout is divided into four sections, and that is reflected in the Help file descriptions also:

1. Radiation, source and mouth parameters
2. Horn parameters
3. Traditional driver parameters
4. Chamber parameters

Decisions on layout and functionality are only taken after much consideration of all the consequences, with controls being positioned down to the last pixel. Hornresp is now an extremely complex piece of software with many more features than would normally be expected in such a seemingly modest program. The context-sensitive interactions between different parts of the program are very complicated indeed. All these things need to be taken into account when thinking about the user interface. Also, it is not just horn loudspeakers that Hornresp needs to deal with, other system types need to be accommodated as well.

Thanks for going to the trouble of producing the GUI examples, it seems that GUI preferences are a very personal thing with everyone having their own idea of what makes best sense. For example, I would consider things like the Loudspeaker Wizard, etc, to be tools, not input parameters.
 

Attachments

  • Print.pdf
    174.6 KB · Views: 210
To be perfectly honest (speaking only for myself) it is the sheer amount of unknown values on the main screen that makes the program look so daunting to an inexperienced user.

I completely understand why you took the approach you did, and how it developed into what it is, but let me tell you a little story...

Back in the naughties I was a licensing specialist at Microsoft, and once a year we would travel all around Australia giving licensing presentations to key companies. I prepared these presentations based on current relevant content, and the extensive information in my head. Because we only got to do this once a year in person (I held monthly virtual meeting with these same people) I wanted to pack as much information into those presentations as I could.

Those that understood what I saying were blown away by the amount of knowledge I had to impart, while a great portion of the audience just looked at me with blank stares. Talking to some of the participants after the presentation it was obvious that even some of the more basic stuff I had covered had gone over their heads (you don't get this same level of interaction in virtual meetings because people don't want to appear stupid, so they will sit there in silence).

That made me realize that while it was my intention to give a comprehensive presentation, not everyone in the audience was capable of receiving it due their backgrounds and knowledge. You see while I lived in this bizarre licensing world where I spoke in TLA's all day long, a large portion of the audience didn't. They were busy running companies and trying to make a living, and the only reason they were at the presentation was to make sure they were making good licensing decisions for their business.

So while I was well meaning in my attempts to convey this information in extensive detail, I wasn't being very effective if I lost a single one of the audience. From this tour on, I don't think I would call it "dumbed down", but I simplified the same message I had to convey, then I would go into greater detail on the phone or other opportunities with those who had sufficient background to understand.

You see if I wanted everyone to get the most value out of what I had to say I had to tailor it to the lowest common denominator, and present it in bite sized chunks, and not put a 5lb steak in front of everyone and ask them to chew it.

I try to design programs using the same philosophy, while some users may be able to handle a full on interface, I need to consider those trying to get the same benefit that don't have the capability to handle something new. So while my natural desire is to just go for it and put everything on one form, I need to reel myself back in sometimes and try not to jam too much into one screen, to save it from getting overwhelming.

What I put together wasn't anything like a final version, more like a concept. I don't understand what half of the things do. It was an attempt to put what I thought was related in one place to make it flow in a more logical way. I used the descriptions at the bottom that had similar words to group them. At first glance I thought they were all related, but only after dissecting what was on the main page and splitting them up did I discover there were different groups of related items. Obviously there is speaker and box information, but I didn't naturally see four groups of information.

I don't see why you couldn't still produce the exact same report, as long as the information is still contained within the application somewhere it is still possible to correlate it all together.

Sometimes when we allow feature creep to take place we need to go back to the drawing board and see if our initial way of doing things still makes sense. What made perfect sense when it was a limited amount of features, can sometimes lack cohesion once new parts are introduced and needs to be redesigned to incorporate the new features. I don't know how many times I have found myself in this position because I get too excited about starting the project I don't do a proper UML and I add features as I think of them, causing me to redesign the interface over and over.

If you are writing an application for a specific business it is easy to try and map it all out in one go, when you are writing something where there is community input, it can become an endless moving target with users asking for new features and discussions spurring new ideas and new features.

I don't understand the program well enough to be able to 100% know where everything should be, that is why I put a tab Wizards??? in there as it would seem like there should be a tab like that for the input wizard that is under help. Without looking at the code it is hard to say but if there are a number of wizards, perhaps it would be best to put them in one place, as long as it doesn't upset the flow of everything else.

Anyway it is nothing more than a suggestion. You are welcome to use all or none of the suggestions. It is your app and if you think it is the best version it can be then go with that.

One last thing, being the visual person I am. The crude images I put in helped me feel more comfortable with the interface. I am fairly sure I am not the only one who prefers to see a few relevant images instead of all text. Especially the ones for the flare type, not everyone is going to be overly familiar (if at all) and just representing the different shapes helped me cement what the function is.
 
Last edited:
  • Like
Reactions: 1 users
To give my question some more context, every speaker I have seen designed like this has had the driver at the end of the horn. And even with a limited understanding I have of Hornresp and playing with the software (following the video) it would seem like moving the driver would be more beneficial.

So my question is does the shape of the sealed end of the chamber matter or only the volume of it?

Horn - Chamber.jpg
 
I have never understood why people give up on Hornresp because of the slight learning curve as it pertains to the UI. If you listen to the comments of the many diehard users of Mr. McBean's beautiful freeware especially the ones that refer to the staggering accuracy of the simulation model how can you give up on trying to figure out how to brandish such a tool. ..............note to self....... self perhaps we should give Akabak another go ......... like they say practice what you preach 🫣🤬🤔
 
  • Like
Reactions: 1 user
diyAudio Moderator
Joined 2008
Paid Member
The earlier adopters come from the position of trying to work with horns before tools like hornresp were readily available. We learned some of what makes them work and used targetted formulas, and probably built a few horns based on best guesses and then used them to the point of understanding their limitations.

I see using hornresp as a good tool to better understand horns... but I suspect those new to horns don't yet appreciate that they aren't near as simple as closed and vented boxes.

I often see newbies asking so many questions that they skip too many steps to learn properly. They don't always take as much time to build and make mistakes.
 
  • Like
Reactions: 1 user
Yes I agree that one must earn his knowledge through blood, sweat , tears , and sawdust. The vast majority of that knowledge generally comes from life's two best teachers...... failure and mistakes. But yet if you desire to be respected in these forums you better come armed with knowledge from ample research on the subject at hand. This supplemented with a dash of lessons learned from design/construction/simulation mistakes. As much as I respect knowledge that is earned through hard work and dedication, I have an otherworldly amount of respect for all of you gentlemen (and ladies?) who were here before MJK and Mr. McBean decided to develop computer simulation models for Horn / ¼wave enclosure designs. The dedication and love for loudspeaker design in general and horn loudspeaker design specifically that each of you possess is breathtaking. I consider myself a pretty big ¼wave guy. I have not built any other style of enclosure since I designed and built my first a few years back. And if I have any say in the matter I will never build a "normal" enclosure the rest of my life. But that pales in comparison to the way it was done before sim tools. To commit to build what was basically known before hand to be at best a "ballpark" horn enclosure knowing that the optimization was going to require multiple tweaks (tongue in cheek) as well as the possiblity of multiple construction modifications if not full on complete rebuilds is amazing to me. Although I'm glad I didn't have to do it this way please do know that I appreciate the effort and shared knowledge of each of you that did. I make it a point anytime I'm talking to guys about horn enclosures and the person comments "wow great build, (or sim , or design, or whatever) how did you learn to do that so good" I always try my best to give credit to everyone that came before me and I'm not just talking about MJK and McBean either. So with all that being said in my windbag of a comment I would like to finish by saying....... Thank you sir for everything. We each and every one owe you a deep debt of gratitude that we can unfortunately never repay.
 
Last edited by a moderator:
https://github.com/ibcooley/TransmissionLine

It took me a while to install and be able to use the TL software, and it was a little frustrating to get all that done. So, I spent some time decompiling the program and uploaded the source to Github. Since I can't find any reference to this, except through way back machine, I figured it would be nice to have an available copy that doesn't rely on a broken installer -- and the source along with it.

If its against the rules, let me know. I've only added it for convenience and archival purposes.
 
  • Like
  • Thank You
Reactions: 7 users
@perceval to compile the project, you'll want to use a .NET framework compiler, such as Visual Studio. If you just want the binary of the executable, you should be able to download it from releases section of the git repository.(https://github.com/ibcooley/TransmissionLine/releases)
I've built both a debug version and a release version. The debug version has compiler generated debug information and may be marginally slower and a little bigger than the release version. Other than that, they should be identical in functionality.
Also, I believe the original code used Visual Basic in the .NET framework, and my decompiler generated C# source code. It shouldn't matter much, but that is a difference.