Sure, I'd be interested in the Python version. Other than amusing antiques like PL/I it's the language I've most recently done much of any sort of programming in, so there MIGHT be a hope in heck. I'm a travesty to my BSCS, but that's life.
WRT WinISD .vs. your program and the transfer function-ish bit, they have the transfer function (which they normalize to 0dB out in the flatland section) and then they have the SPL graph that responds to what you enter for the wattage in the signal section (as your cone excursion and port airspeed graphs do) so it was a bit counterintuitive that your dB SPL graph didn't change when I changed the input wattage; that's all the issue there might be from my POV, anyway. At 1W, my box models to a bit below 100dB in WinISD, too. It is nice to have the "input sensitive" version if only for the "so how loud can THIS box get with THIS amp?" questions, though otherwise they are basically the same graph. And, of course, courtesy Randall Munroe's xkcd (and there are others on the Python theme):
Python is currently my favorite language. I find that I can be extremely productive with it. I'll put my program up on my little web page, Real Soon Now.
It will be in source code form, which is my favorite way of sharing software. So you'll have to install Python and maybe one or two other packages such as MatPlotLib. I still use C (straight ANSI, none of this ++ or # stuff) for microcontrollers.
Amusingly, PL/1 was taught in colleges in my area when I was in school, because the auto industry used it. A few years later, everybody switched to Pascal. I was dead certain that Pascal would win out over C.
I think that some improved annotations on my graphs would clear things up for the plots. Also, my program typically reads about 2 dB higher than WinISD because of the convention that I chose for converting 1 Watt into an equivalent voltage.
Edit: I added a graph for sensitivity at the amplifier power entered into the user inputs.
Not to try and be a scrounger but is the spreadsheet version hosted anywhere? I did wonder as I was using the online version that I could create a spreadsheet version to do the maths and graph it, and allow to save and compare different drivers easier as well - but I'd have to look up what all the maths was - and spreadsheets are pretty cross platform, even people on macs have a reasonable chance of having MS office.
It's at my noncommercial web page:
Invalid Link Removed
It's Excel with a Visual Basic macro, so you will get alarm bells from Excel if you try to download it. As with any such content, good computer hygiene suggests actually looking at the source code before enabling macros, even if you think that you trust the author. And if you save it in a newer Excel version, you have to use the .XLSM extension. I wrote it using Excel 97, which served me for more than a decade!
I'm missing the number for QL (box leakage losses). QL impacts the frequency response most intensive. I can reproduce a very similar response for QL>30. That means a very large number for QL but IMO this will not reflect the real world. Eminence has published tons of cab designs for QL=7. So I would never ever expect QL>15. IMO it is a good idea to set QL around 7..10 for the simulation of response, and than doing the fine tuning with the ears (if possible).
I suggest a tuning around 60..65Hz for the 12CL64. There is no need to extend Vb to 50L. The 12CL64 looks excellent for Vb 40..45L.
Keep in mind you have to subtract 2L off Vb due to the air volume occupied by the driver.
I'll add some code to simulate a separate Q value for the port. In fact, it's in my Python program, but I removed it from the Javascript version just to get myself going quicker. A huge advantage of Python is that it handles complex numbers inherently, so all of the formulas are simpler. There may be a Javascript complex arithmetic library that I can add. And yes, good point about subtracting the driver volume.
