My first crossover design (yes I've measured things) but I can't find any software...

[Chris Roemer]

Re: My first crossover design (yes I've measured things) but I can't find any softwar

Those online calculators are based on the NON-fact that the loads (drivers) have a "flat" impedance. They do NOT.

Your digital XO isn't affected by the actual variation in impedance. Those online calculators will give you L/C values that WOULD work, IF drivers had flat impedance profiles, but they do not. If you have an 8 ohm tweeter and an 8 ohm woofer, your (passive) XO network will in fact see impedances ranging from a low of 5-6 ohms (possibly even lower), to a high of 50 (or possibly even 100) ohms ranging across the audible frequency spectrum. Therein lies the problem.

It would be MUCH less expensive to get an EMM-6 mic ($50?) and have it calibrated by Cross-Spectrum Labs (I believe they're in Massachusetts?) every 5 years if "drift" is a concern of yours. THEY used an ACO Pacific mic to cal my EMM-6. And a side note, is that the CSL cal file was NOTHING like the cal data furnished by the on-line "individualized" cal file that I downloaded from Dayton. That's my problem with the Dayton cal files. Short of getting an EMM-6 cal'd at CSL, I'd have been MUCH better off using a generic cal file (generic to the Panasonic WA/WM-61 condenser capsule - flat up to about 3-4k with a +4 to +5dB rise in the 10k-12kHz range, we've all seen/read this data) than to use the cal file supplied by Dayton.

Chris

[stochastic]

Re: My first crossover design (yes I've measured things) but I can't find any softwar

Those online calculators are based on the NON-fact that the loads (drivers) have a "flat" impedance. They do NOT.

I wasnt' assuming a flat load, I have the impedance plot and can transfer it to a zma file if needed. If it sounds good at 1.8kHz with the slopes I've found, why not plug that into an online calculator with the corresponding impedance values 13.4ohm, and 16.2ohm and get the LC values required?

It would be MUCH less expensive to get an EMM-6 mic ($50?) and have it calibrated by Cross-Spectrum Labs (I believe they're in Massachusetts?) every 5 years if "drift" is a concern of yours. THEY used an ACO Pacific mic to cal my EMM-6. And a side note, is that the CSL cal file was NOTHING like the cal data furnished by the on-line "individualized" cal file that I downloaded from Dayton. That's my problem with the Dayton cal files. Short of getting an EMM-6 cal'd at CSL, I'd have been MUCH better off using a generic cal file (generic to the Panasonic WA/WM-61 condenser capsule - flat up to about 3-4k with a +4 to +5dB rise in the 10k-12kHz range, we've all seen/read this data) than to use the cal file supplied by Dayton.

Chris

That's also what I thought the Daytons calibration file would entail. Hence the purchase decision is now much closer in price with the Josephson.

Also, since my Fmax of this speaker works out to just over 1.8kHz acording to http://www.claudionegro.com/sw/swaco...nearfield.html then maybe my frd files will be accurate enough to not bother re-measuring anything? EDIT: whoops, miscalc there - actually Fmax is closer to 680Hz.

[neildavis]

Re: My first crossover design (yes I've measured things) but I can't find any softwar

I wasnt' assuming a flat load, I have the impedance plot and can transfer it to a zma file if needed. If it sounds good at 1.8kHz with the slopes I've found, why not plug that into an online calculator with the corresponding impedance values 13.4ohm, and 16.2ohm and get the LC values required?

Read the Help file from PSD-Lite that I posted previously. It's actually got the information you need to design your own crossover program.

It's not just the impedance at the crossover point that you need--you need to model the impedance at all frequencies and you need to account for the driver response. PSD-Lite has a checkbox for initializing the textbook crossover with the impedance at the crossover frequency--that is, it looks at the ZMA file for the impedance value at the textbook crossover frequency and determines the values of the textbook crossover components. So it already does what you are proposing. This gets you a lot closer to a good crossover than if you just use the textbook values for the nominal impedance, and it's a good starting point to initialize the model. You can uncheck the "use ZMA impedance" checkbox and see how bad a textbook crossover is--it's usually an interesting comparison.

However, for the drivers I used for experimenting, there was still a lot of room for improvement even using the ZMA impedance at the crossover point. Borrow a laptop and try PSD-Lite and you can see for yourself how much difference there is between an optimized crossover with all ZMA values in the model with the driver response and one designed using just the impedance at the crossover point. Usually the optimized crossover doesn't look much like the textbook crossover by the time you are done optimizing, and sometimes it can be a lot simpler and still achieve the same slopes.

[Chris Roemer]

Re: My first crossover design (yes I've measured things) but I can't find any softwar

. . . as in, frequency modulated ?

"Fmax" is not a common speaker term. Is that the top end limit for you woofer's nearfield measurements?

[SirNickity]

Re: My first crossover design (yes I've measured things) but I can't find any softwar

Is microphone calibration over time really that big of an issue? How much do they drift over 5 years? I'm not being sarcastic, I'm actually wondering if anyone has gone to the trouble of remeasuring theirs, and by how much it's off. I'm just not going to get worked up about 0.3dB shifts, since there's likely to be a bigger difference on whether my cat hacked up a furball on the carpet, causing reflections at the resonant frequency of kibble. If it's off by 4dB, that's another matter...

OP -- using impedance charts won't work. That's impedance under test in the manufacturer's baffle. In your box, it will be different. Especially if it's ported. If the driver is enclosed (like a tweeter or dome mid), then it's much less of a concern, but still worth testing yourself.

I understand the propensity to Linux (fellow user myself), but there are some things that Linux people make difficult for themselves. Specialized software implies you gotta stray from your ideals and either get, or acquire access to, the OS where the apps are. Borrow if you must. You can't sneeze without hitting someone that has a Windows box.

On the flip side of that coin, it's about time someone started an open-source project for this speaker calc stuff. I hugely appreciate the work JB et.all have done, but the Excel dependency is such a huge hindrance. I'd love to see a good ol' C/C++ project in the works. If the calculations are done in a ISO C, porting the UI to Win/Mac/Linux is relatively easy. With Makefiles, the platform detection can be done automatically, so you download, compile, run. That's easier than the "cross platform" .NET environment, since "cross platform" in this case actually means "across every OS... (that is [still] supported by Microsoft)." Yes I've heard of Mono. No that doesn't make it cross-platform.

Is Jeff generally OK with people forking off his VBA code?

[stochastic]

Re: My first crossover design (yes I've measured things) but I can't find any softwar

Is microphone calibration over time really that big of an issue? How much do they drift over 5 years? I'm not being sarcastic, I'm actually wondering if anyone has gone to the trouble of remeasuring theirs, and by how much it's off. I'm just not going to get worked up about 0.3dB shifts, since there's likely to be a bigger difference on whether my cat hacked up a furball on the carpet, causing reflections at the resonant frequency of kibble. If it's off by 4dB, that's another matter...

I'm not really sure, but there's aslo THD measures that cheaper mics are certainly proven to be not as good at - if you care to start measuring THD.

OP -- using impedance charts won't work. That's impedance under test in the manufacturer's baffle. In your box, it will be different. Especially if it's ported. If the driver is enclosed (like a tweeter or dome mid), then it's much less of a concern, but still worth testing yourself.

Those impedance measurements are mine - in the box that it's going to live in.

I understand the propensity to Linux (fellow user myself), but there are some things that Linux people make difficult for themselves. Specialized software implies you gotta stray from your ideals and either get, or acquire access to, the OS where the apps are. Borrow if you must. You can't sneeze without hitting someone that has a Windows box.

On the flip side of that coin, it's about time someone started an open-source project for this speaker calc stuff. I hugely appreciate the work JB et.all have done, but the Excel dependency is such a huge hindrance. I'd love to see a good ol' C/C++ project in the works. If the calculations are done in a ISO C, porting the UI to Win/Mac/Linux is relatively easy. With Makefiles, the platform detection can be done automatically, so you download, compile, run. That's easier than the "cross platform" .NET environment, since "cross platform" in this case actually means "across every OS... (that is [still] supported by Microsoft)." Yes I've heard of Mono. No that doesn't make it cross-platform.

I'm going to give in and accept the fact that I may need to learn a compatibility layer for this, but I'm also in the middle of studying for exams right now (had electromagnetics this morning, linear algebra in two days) so learning the software in WINE is going to have to wait - I really shouldn't even be touching these speakers right now but you know how projects go... (especially when there's important studying to be done)

I'd love to help write a GPL C/C++ program to fill this gap. Hopefully there are enough other talented coders around that we can make light work of this... I'll talk to my friends about it.

Is Jeff generally OK with people forking off his VBA code?

That's a really good question. I'd love to know.

[dlr]

Platform and open source considerations

Is Jeff generally OK with people forking off his VBA code?

The bulk of the calculations are not in the VBA code. When Jeff made v7 available to me, there was little VB code to even try to re-use. Jeff did tremendous work with calculations in Excel itself. In fact, I found it so difficult to try to follow that I decided I had to do it from scratch. My hat's off to Jeff's Excel skills.

I doubt that any open source version will ever come to full fruition. It seems like every time I saw something coming along of that nature, it eventually withered away. WinPCD is completely done in C#/.NET 4.0 because I wanted a real project to do in C#, not some make-work stuff, I wanted to the whole thing as a learning experience and because Windows is still the largest installed base and likely to be that way a while. It's easy to use and there's tons of open source code for it (as there is for C++, too, of course). I've used two major pieces of it. One item I could have done myself, the long way. The other was (and still is) indispensable to me. To create that part myself would have been a major effort, possibly a real game changer. The size of that code is unreal, but that's what makes it nearly universal. Just learning how to use it and find the aspects useful for my needs took a lot of time. You can run stuff like this from XP through Win7 and I would think Win8, though I've not tested that yet.

I also think that a lot of open source stuff advances too slowly unless there's one individual who is the driving force unless it has some generic purpose such as a math library. When a program has a significant GUI, too many cooks spoil the stew IMO.

Another consideration is that graphic representations, whether controls or graphs, likely don't carry properly across platforms. I may be wrong, but that alone would have to be validated before I'd consider coding in a cross-platform language.

dlr

[JasonP]

Re: Platform and open source considerations

I may be wrong, but that alone would have to be validated before I'd consider coding in a cross-platform language.

Gtk+/Sharp

[neildavis]

Re: Platform and open source considerations

The bulk of the calculations are not in the VBA code. When Jeff made v7 available to me, there was little VB code to even try to re-use. Jeff did tremendous work with calculations in Excel itself. In fact, I found it so difficult to try to follow that I decided I had to do it from scratch. My hat's off to Jeff's Excel skills.

I had the same problem with WBCD. Excel has arrays and dependencies that you have to implement manually in functional code, whether it's C, VB.net, C# or whatever. Reverse-engineering an Excel program *can* be a lot more difficult than starting from scratch. It depends on the code, of course, but after reverse-engineering WBCD I resolved to never do it again. It took me a long time (several months) to figure out the cell dependencies in WBCD, but I wrote a new version of PCD from scratch in about 3 days. A complicating issue is that Excel allows you to write what amounts to very bad code. Lots of redundancies, lots of undocumented variables, and sometimes very inefficient computing, where values are unnecessarily re-computed. This isn't a knock against Jeff--it's just the way Excel supports rapid development. I found myself re-writing equations and creating a lot of extra "common" variables to streamline the calculations for WBCD. Translating from Excel to a real programming language is a lot of work, and as Dave correctly points out, it sometimes just isn't worth it.

I doubt that any open source version will ever come to full fruition.

I tried to put this issue to bed by providing a link to the "Crossover Equations" in PSD-Lite. The number-crunching for the Crossover Module is only about 2 pages long, and the actual equations are described in that Help file. This isn't magic--it is simple network analysis that a good 2nd year engineering student should be able to do. And that Help file should make it even easier for anyone to write the equations.

But the challenge in a crossover design program isn't the network equations--it is all of the textbox handlers, user interface code and charting. I haven't done an "official" tally, but I think that PSD-Lite is at least 80% user interface code and no more than 20% "math". And that's why this open source talk is mostly nonsense. The really hard part about the crossover program is the user interface, and that is usually platform-specific.

Another open source challenge is that we've grown beyond stand-alone calculators and really need a systems approach that can integrate the various design tools. And I don't think you can design a complex suite of design tools without a data model and a good overall architecture. I've put a lot of work into defining a Loudspeaker Data Model and I've started documenting the architecture of a comprehensive design suite using Enterprise Architect. So unless the "open source" approach comes up with a data model and a comprehensive architecture, I don't think it's going to be successful.

[stochastic]

Re: Platform and open source considerations

<snip>because Windows is still the largest installed base and likely to be that way a while.<snip>

Of the 1.07 billion consumer computing devices shipped in 2012, Google Android took a 42% market share, followed by Apple devices at 24% (OS X and iOS), Microsoft at 20% and other vendors at 14%. http://www.zdnet.com/windows-has-fal...id-7000008699/

I think the future is full of cross-compatible coding. It needs to be. OS and device development is getting too vaired to keep everything reliant on a single OS'es code library. Just my opinion.

Yes, windows still ships with most OEM desktops, but those are becoming dinosaurs. Anyone can use a decent USB audio interface on their android tablet - they'd be in the same lack of tools situation as I sit.

None the less, (despite what it may seem) I don't want to argue the validity of your past coding choices. Would you be interested in helping build a GPL project to rule all the platforms? Your expertise could certainly be very useful to all of us.

[johnnyrichards]

Re: Platform and open source considerations

Of the 1.07 billion consumer computing devices shipped in 2012, Google Android took a 42% market share, followed by Apple devices at 24% (OS X and iOS), Microsoft at 20% and other vendors at 14%. http://www.zdnet.com/windows-has-fal...id-7000008699/

I think the future is full of cross-compatible coding. It needs to be. OS and device development is getting too vaired to keep everything reliant on a single OS'es code library. Just my opinion.

Yes, windows still ships with most OEM desktops, but those are becoming dinosaurs. Anyone can use a decent USB audio interface on their android tablet - they'd be in the same lack of tools situation as I sit.

None the less, (despite what it may seem) I don't want to argue the validity of your past coding choices. Would you be interested in helping build a GPL project to rule all the platforms? Your expertise could certainly be very useful to all of us.

While that is all true, a little dose of reality needs to be interjected. Nobody is going to be able to write a program for a phone that will allow sophisticated crossover design - the sheer amount of screen real estate just demands a larger screen than phones ship with. While RTA programs will abound for handheld devices, advanced simulation tools will always be in the realm of machines capable of displays larger than a deck of cards. Those shipment numbers are a red herring. Given that nobody is going to want to deal with a phone screen toggling between 12 different windows to see what a simple capacitor change will accomplish (extrapolate that to any serious computing tasks, by the way) and the "cross platform future" becomes dependent on larger screens, not the current trend of trying to fit a PC in your pocket.

Bejeweled, Solitaire, Angry Birds, and instant messaging will work just fine on tiny displays but serious engineering software (which is what these tools in question are) will demand, at the least, a usable GUI beyond what an iPhone or Galaxy can afford. Tablets, maybe - but never a phone no matter how smart they think they are.

So when it comes to the inevitable pee match about OS superiority - look first at what the majority of people use their OS for.

[stochastic]

Re: Platform and open source considerations

Quite right, phones are not the realistic place for this form of application. That being said: http://www.parts-express.com/pe/show...number=390-810

I was primarily thinking about tablet computers. They easily make up the vast majority of computers I see at my engineering classes in univeristy right now - those and apple powerbooks.

None the less I was merely trying to illustrate that cross platform compatibility is going to become a more requested feature around these parts in the future IMHO.

[johnnyrichards]

Re: Platform and open source considerations

Quite right, phones are not the realistic place for this form of application. That being said: http://www.parts-express.com/pe/show...number=390-810

I was primarily thinking about tablet computers. They easily make up the vast majority of computers I see at my engineering classes in univeristy right now - those and apple powerbooks.

None the less I was merely trying to illustrate that cross platform compatibility is going to become a more requested feature around these parts in the future IMHO.

The little Dayton holds promise, but for a 3"x5" screen it will be relegated to RTA duty.

Tablets, as I noted in my posts - maybe. It depends on who is willing to take the plunge to develop the apps that go beyond simple RTA. We have several experienced developers on this board alone, two of which explained why they went with a Windows dependency, and a few others who do not seem to know how to take it on their own to a cross platform dependency.

This might be the issue, but it could also be why you do not see full featured 3D Cad apps on a tablet, at least not yet. Well, except for maybe the Win8 tablets

[neildavis]

Re: Platform and open source considerations

None the less I was merely trying to illustrate that cross platform compatibility is going to become a more requested feature around these parts in the future IMHO.

Nah--I've been doing Systems Engineering for a long time (even have an MSSE) and if anything, cross-platform compatibility is less of a concern than it was 10 years ago. People nowadays want something that will run on either Windows, Android or IOS. They don't care whether it's truly cross-platform or easy to port--they just want the product on their platform of choice.

The most promising approach for platform-agnostic computing is Model-driven Architecture (MDA), where the design is represented as a platform-independent model (PIM) and compilation tools take care of platform-specific features. That's partly why I started to model my tool suite using Enterprise Architect, including the data model. I've still got a lot of work ahead of me to fully implement a PIM, but at least the top-level features are defined.

Unfortunately, MDA can work well for procedural code, but it doesn't work well for defining and porting a user interface definition. And these tools tend to be "heavy" on user-interfaces. So I've got a core architecture that I can implement easily enough on other platforms, but the user interface code will be different for each platform. There is a lot of user interface code, but it tends to be repetitious, so maybe hosting this design on another platform won't be all that time-consuming. I downloaded the Android SDK and started playing a bit--I'll know more about the challenges in a couple of weeks.

I'm curious how well some of these algorithms will work on a tablet. There is a lot of double precision floating point math in the Crossover and Baffle Diffraction routines--I'm not convinced those ARM processors are up to the challenge.

[SirNickity]

Re: Platform and open source considerations

Nah--I've been doing Systems Engineering for a long time (even have an MSSE) and if anything, cross-platform compatibility is less of a concern than it was 10 years ago. People nowadays want something that will run on either Windows, Android or IOS. They don't care whether it's truly cross-platform or easy to port--they just want the product on their platform of choice.

Tell that to the dozens of posts about getting WinISD to run on Win8, or requests for Mac software, and now, a couple Linux folks too.

Platform dependence is less of an issue today because a great many applications have moved to the web, where as long as you're not using Internet Explorer, it'll work the same on anything, anywhere.

Engineering tools can't be web-ized quite so easily. But there can be libraries that do the heavy lifting, and there are plenty of graphics (UI) toolkits that work on all the major OSes. (Qt and Gtk are two fine examples.)

Edit: This reads a little harsher than I mean it to, so I'd like to make it clear I'm not trying to start a fight. And I do appreciate the work everyone has done on their respective projects. Nonetheless, I'm advocating for an attempt at trying to bring some of these tools to greater audiences. And I would love to see it in an open source package. People learn from that stuff, and bright people contribute in really profound ways when the code is out there for the taking. There's a lot of free (beer) software available, but it seems like no one is interested in doing the work and giving away the code. I don't hold that against developers, especially those that hope to gain something in return for their effort, but if there are some talented people who understand the concepts, math, and code... and they're willing to donate their time to the "greater good" (or whatever)... well, hey. Even better. So we'll see.