Transmission Line Modelling Software

Schmeet, this program is awesome, thanks, i´m a noob in the transmission line speakers, and this program is more intuitive that hornresp.

The image is a comparative between a design i made with a custom excel in your software and hornresp.
 

Attachments

  • Comparativa.png
    Comparativa.png
    42.5 KB · Views: 467
Owen,

Thanks for your kind words. I'm glad you like the software. I have done a update with regards to your comments. This can be installed by opening the about window (Help -> About). This will check for updates and you can click the Install button to install them.

1. On startup the "Make a directory" box appears behind the splash screen and makes it look like the program has frozen. It wasn't until I clicked on the program's tab on the windows bar that the GUI for directory selection appeared.
Thanks, I have fixed this and it now appears once the main window has loaded.

2. After entering a driver's parameters in the driver window, I clicked save and everything worked perfectly, but clicking in the white "Driver Library" box caused a recoverable crash.
Thanks. This was a bug where it tries to load a non-existent driver. Now fixed.

3. Lvc is in Henries, which caught me out the first time through. After looking more closely, I notice that all your units are consistent, but this one might be best left in mH since every datasheet I've ever seem gives Lvc in this format. I had initially put in 1.35H and all the graphs were nonsense, it wasn't until closer inspection that I found my error and re-entered as 0.00135H
I'm still undecided on this. I know it is typical to quote inductance in mH but I am a warrior for SI units! ;) I have added a warning so if you enter anything higher than 0.002mH it remind you that its in H, not mH.

4. I'm still wondering what "Enclosure Width" does since it didn't appear to change anything on the graphs.
I need to do some work on this, but it does essentially do nothing. There is a window called Geometry Viewer. This gives you a 2D view of your enclosure, the width value is used here. I divide the area by the width in order to show you a 2D view.

I need to add some more stuff here to make it more intuitive and maybe some more views etc.
 
Hi, I like your program. I haven't had time to test it much yet but I've been telling lots of people about it.

Would it be possible to allow for a rear chamber? If so, front loaded horns could also be simulated.

It would also be neat if you could seal the tl terminus so you could simulate sealed boxes.

I realize that both these requests are outside the scope of a transmission line simulator, I'm just hoping this can evolve into a general 1/4 wave simulator.
 
Hi, I like your program. I haven't had time to test it much yet but I've been telling lots of people about it.

Would it be possible to allow for a rear chamber? If so, front loaded horns could also be simulated.

It would also be neat if you could seal the tl terminus so you could simulate sealed boxes.

I realize that both these requests are outside the scope of a transmission line simulator, I'm just hoping this can evolve into a general 1/4 wave simulator.

I have no experience with horns. Do you mean a rear chamber as well as a 'front pipe'? I would have to done some research to understand the best way of doing this. I will certainly keep it in mind.

With regards to sealing the terminus. In the enclosure window you can select 'Closed End' and you can indeed model sealed boxes.

On that note. You can model vented (reflex) enclosures by having a box and then adding an element that is the size of the port.
 
I'm still undecided on this. I know it is typical to quote inductance in mH but I am a warrior for SI units! ;)
Since this has come up again, I'll point out that every value conversion by the user is an opportunity for error. Especially when decimals and lots of zeroes are involved. :D

Myself, I'm a warrior for useability, though when I was programming back in the days of DEC PDP 11s, you'd have been hard pressed to get me to waste any processor time on the input. Or use a variable name with more than three letters. ;) These days, things have changed, of course, and I have to tip my hat to the inputs in WinISD - being able to cycle through a choice of units (with conversion on-the-fly) is actually very useful.

The lack of standard units is annoying, but I think you'll make more friends by helping with the problem, rather than adding to it. (and that's my geezer lecture for today)
 
Do you mean a rear chamber as well as a 'front pipe'?

Yes.

Front loaded horns also sometimes have a defined front chamber as well, but that's easily defined by one or more of the initial segments, so no need to worry about a front chamber.

With regards to sealing the terminus. In the enclosure window you can select 'Closed End' and you can indeed model sealed boxes.

I didn't see that. Great!

On that note. You can model vented (reflex) enclosures by having a box and then adding an element that is the size of the port.

I realize that. It would be nice if you could also choose the port location, same as you choose the driver location. Then you could model all manner of mltl.
 
I need to do some work on this, but it does essentially do nothing. There is a window called Geometry Viewer. This gives you a 2D view of your enclosure, the width value is used here. I divide the area by the width in order to show you a 2D view.
Hi schmeet,
What expansion/flare do you use? If you intend your software to design enclosures of constant width you'll want to use a parabolic expansion as opposed.
 
Hi

First impression is that input fields could be more userfriendly, liter instead of m3, cm instead of meters, cm2 instead of m3. Stuffing value etc.

I find it hard to actually see what I have entered for the Enclosure using several sections: Which Elements are to the Closed End, which Elements are to the Open End.

It would also be nice if the GeometryDisplay had measurements (cm) to ensure the Enclosure data had been entered correctly.

(I use simulation of stuffing distribution a lot.)

What I find very nice in "Easy Quarter-Wave" is the near real time result of the changes, and how easy it is "to move the driver" up and down in the line.

When I have some more time, I will compare to MJK models.

Hi from
Bjorn
 
I almost forgot, one last suggestion. Things would go a lot smoother if things just updated automatically without the having to click the "update" button every time you make a change.
I must defer. WinISD works like that, and I keep getting annoying error messages when I typo. :eek:

I think it may be even less apropos in a TL program where it's not uncommon to change several entries at once.
 
While it is possible to do that in code, it can be quite painful to implement. I go through stages where I try to do changes on the fly and other times I prefer to use a update button. The problem with real time changes is you have to spend a lot more time trying to catch errors.

For example deleting all of the data out of a box in real time will throw up one type of exception, type a letter where a number should be will throw up another, where as you use an update button it can check all of the data in one go and tell you if you have it right or wrong before it crashes anything.

Edit:
Forgot it has to check for double decimal points etc (while a decimal point is a valid entry and therefore you can't exclude it from acceptable characters, you only want the one), I have written code to check for all these things, and it can be quite handy for an application like this where you are dealing with a lot of decimal placed numbers, as you can use the same bit of code for numerous boxes.
 
Last edited:
Not sure if you plan to offer imperial conversion to those that don't speak native metric.... but here is a bit of code I wrote that works quite well for a two way conversion, you are most welcome to use it in your app.

Imports System.Math

Public Class Conversion

Dim Position As Integer
Dim FirstPart As Integer
Dim SecondPart As Integer
Dim ThirdPart As Integer
Const checkString As String = ".0123456789"

Public Function UnitConversion(ByRef ConvertMe As String, ByRef Metric As Boolean) As String

Dim charArray() As Char = ConvertMe.ToCharArray
Dim aBool As Boolean = False

For i = 0 To charArray.Length - 1
If CBool(InStr(checkString, charArray(i).ToString)) = False Then
If charArray(i).ToString = "/" Then
SecondPart = CInt(ConvertMe.Substring(Position, (ConvertMe.IndexOf("/") - Position)))
Position = ConvertMe.IndexOf("/") + 1
Else
FirstPart = CInt(ConvertMe.Substring(0, ConvertMe.IndexOf(charArray(i).ToString)))
Position = ConvertMe.IndexOf(charArray(i).ToString) + 1
End If
aBool = True
End If
Next

If aBool Then

Metric = False
ThirdPart = CInt(ConvertMe.Substring(Position, ConvertMe.Length - Position))
ConvertMe = CStr(Round((FirstPart + (SecondPart / ThirdPart)) * 25.4, 4))
Position = 0
FirstPart = 0
SecondPart = 0
ThirdPart = 0

Else

Metric = True
Dim Reducer As Double = CDbl(ConvertMe)
Dim Inches As Integer = CInt(Int(Reducer / 25.4)) 'Find the number of inches
Reducer -= Round(Inches * 25.4, 7) 'Subtract off the inches (out to 7 decimal points of accuracy)
Dim SixtyFourths As Integer = CInt(Int(Reducer / 0.396875)) 'Calculate the number of 64ths
Reducer -= Round(SixtyFourths * 0.396875, 7) 'Subract off the 64ths calculated
If Reducer > (0.396875 / 2) Then SixtyFourths += 1

Dim denom As Integer = 64 'The denominator starts off at 64
If CBool(SixtyFourths) Then 'If the number of 64ths is not 0 {even inches}
Do While (SixtyFourths And 1) = 0 'Do while number of SixtyFourths is even
SixtyFourths >>= 1 'Divide SixtyFourths by 2 (shift one bit to the right)
denom >>= 1 'Divide the denominator by 2
Loop
If CBool(Inches) Then
ConvertMe = String.Format("{0}-{1}/{2}", Inches, SixtyFourths, denom) 'Format inches and fraction
Else
ConvertMe = String.Format("{0}/{1}", SixtyFourths, denom) 'Format the fraction
End If
Else
ConvertMe = String.Format("{0}", Inches) 'Format inches only
End If
If Reducer <> 0 Then ConvertMe = "~" + ConvertMe

End If
Return (ConvertMe)

End Function

End Class
 
I must defer. WinISD works like that, and I keep getting annoying error messages when I typo. :eek:

I think it may be even less apropos in a TL program where it's not uncommon to change several entries at once.

Ok, I see what you mean, it probably shouldn't auto update every single time you type a character. But if the program auto updates every time you leave an input box, that's what I"d like to see. For example, the program could just assume that every time you leave an input box and click somewhere else, you'd like the program to click "update" for you, I don't see any need or advantage to do this manually.

When you are going through several iterations of a design trying to perfect it, just making single, small changes each time, that update button is going to get very annoying. Certainly not unmanageable but annoying nonetheless.
 
Last edited:

opc

Member
Joined 2004
Paid Member
I must defer. WinISD works like that, and I keep getting annoying error messages when I typo. :eek:

I think it may be even less apropos in a TL program where it's not uncommon to change several entries at once.

I'll second this... It think it's perfect just the way it is. I probably ran close to 1000 variations on two designs today, and I didn't find the button cumbersome at all.

Quite the opposite in fact... if you're making small changes, having the "Apply" button allows you to focus on the graphs and the way they change as you click the button. If it just updated after text entry you might constantly be wondering if it changed, or by how much.

Add to this the incredibly obnoxious tendency of programs like winISD to throw errors when you delete the value in a box, and I think it's not worth the trouble. My vote would be for the button to stay.

By the way, I checked a ported enclosure simulated in winISD and this program, and they agreed nicely with the same parameters in both programs. Not a guarantee, but it's a good thing.

Cheers,
Owen
 
... if you're making small changes, having the "Apply" button allows you to focus on the graphs and the way they change as you click the button. If it just updated after text entry you might constantly be wondering if it changed, or by how much.

Cheers,
Owen

If you can focus on the graph while you click "update" you should be able to focus on the graph as you click ANYWHERE except the active input box (which would have the same effect, as I proposed). The only difference is it would be much easier and faster with no "update" button.

Maybe we aren't picturing the same thing, there also wouldn't be any error when you clear an input box, no changes would be applied until you left that input box.