XSim free crossover designer

Hi Bill,

Did you do an update? My software said it was updating.

Also, if you are interested in a wish list (I apologize, if you are not):
Maybe the ability to insert a switch to easily switch between two xover designs and then maybe a save overlay to compare. In fact, if it is possible, perhaps multiple overlay saves with multiple colors?

Again, thanks so much for this software. The potential here is enormous.

Jay
 
Yeah, there was a minor update (mostly to allow you to go to Tune mode by double clicking and to register ".dxo" file types with XSim).

You can save an FRD file of a crossover curve result to disk, then use it as the "file" curve in a Frequency Response graph.

You can also click the "Hold" button while tweaking to compare results.

Multiple overlay saves in colors would take some doing the way things are arranged. I guess I could up the number of File curves maybe. I'll check to see how hard that would be.

Thanks,
Bill
 
XSim meets LoudspeakerSoft ?

... just some additional remarks to post 17:

  • LoudspeakerSoft is no more available. Marcel took it from his homepage some months ago
  • LoudspeakerSoft is a pure xover simulation software
  • the posibility to simulate XO on and off axis simultaneously is the most liked feature of LoudspeakerSoft in the german diy community.
Encl. please find the original manual of LoudspeakerSoft. It gives a short impression of the features and the handling.

Regards
Heinrich
 

Attachments

  • lshelp.pdf
    201.1 KB · Views: 384
Administrator
Joined 2004
Paid Member
Thanks Bill! I just started using this yesterday and it look very nice.
I really, really like being able to build the topology needed. As much as I love Jeff Bagby's PCD (have used it for years and learned a lot) the limits of topology are often frustrating.

I'll put in a plug for canned target curves if possible. I find those very helpful in PCD. Will probably end up exporting them from PCD and importing them into Xsim. :)

Will post more feedback after more hands on. Thanks again!
 
The "named" filter shapes (Butterworth, LR, Bessel, etc) seem to be theory teaching things, not terribly relevant (to me at least) with real delay offsets in play, already existing acoustic rolloffs, and driver EQing to handle. When I do crossovers, I work in terms of number of poles and zeroes added and how the curves behave where they join each other.

This is completely backwards, you add in a target curve to show you what you should be aiming for. You then alter the crossover component values and topologies into massaging the drivers natural response to meet the desired acoustic target. This is how LspCAD does it and it is extremely effective.

Sure, the filter slopes are purely theoretical when you're discussing electrical filters alone, but this does not mean the theory and how theoretical drivers sum is irrelevant when considering real world systems. Quite the opposite in fact, it is the theory that shows us what filter types we should be aiming for.

Obviously in the real world you need to consider the electrical filter + the drivers inherent response, but the target acoustic roll off, for your woofer and tweeter, for example, should be text book 4th order LW slopes, or similar. If you've got access too all-pass circuits, digital delay and the like then once you've hit the acoustic slopes all you need to do is apply the relevant amount of delay necessary to bring the drivers into perfect phase alignment. If you don't really have delay, such is the case with most passive xovers, then sure, you do need to deviate away from textbook acoustic targets, towards asymmetric slopes, to bring the drivers into correct phase alignment, but the less you need to deviate the better. The initial goal should always be to land on a textbook acoustic slope, it is then up to you to find a way to make the drivers sum correctly, without moving too far away from that slope.

A piece of crossover design software that does not include target acoustic slopes is completely pointless imo.
 
But that methodology assumes the drivers are in the same delay reference plane, and they almost never are. Summing is a matter of delay not just magnitudes. Unless you can adjust the relative delays to the listening position, the canned curve types won't sum like the books say they will, and basically don't mean much at all.

What is the magic in the named crossover types? They are just points on a continuum.

Edit: you could just load in a target curve as the "File" freq response curve to use it as a target if that's your fave method. You can also put in unattached drivers on the schematic and load those with your target curves so they can display (raw) on the response graphs.
 
Last edited:
But that methodology assumes the drivers are in the same delay reference plane, and they almost never are. Summing is a matter of delay not just magnitudes. Unless you can adjust the relative delays to the listening position, the canned curve types won't sum like the books say they will, and basically don't mean much at all.

What is the magic in the named crossover types? They are just points on a continuum.

Edit: you could just load in a target curve as the "File" freq response curve to use it as a target if that's your fave method. You can also put in unattached drivers on the schematic and load those with your target curves so they can display (raw) on the response graphs.

Did you even read what I wrote?
 
A piece of crossover design software that does not include target acoustic slopes is completely pointless imo.

Don't be so hard :D Agree that target slopes help especially when project is just started. It's much easier to visualize location of slopes and max levels. When initialization phase is done, textbook slopes shouldn't be priority #1 and focus turns into directivity issues etc. If something goes wrong with e.g. power response or DI, one can return to target slope feature to move X/O frequencies radically, or to change orders.
I've done this kind of target slope setting. Tilting straight target line for total is (re)activated by clicking SPL chart.
An externally hosted image should be here but it was not working when we last tested it.
 
IMO no program should use international settings in txt exports. I this case REW should force dot as decimal separator regardless of settings in control panel. I have forced my applications to replace commas with dots before splitting into value fields. It's also extra work to detect&clean headers which may have many different formats.
 
IMO no program should use international settings in txt exports. I this case REW should force dot as decimal separator regardless of settings in control panel. I have forced my applications to replace commas with dots before splitting into value fields. It's also extra work to detect&clean headers which may have many different formats.
If the program is producing a list of values for the user then a comma should be used if that is what the user specified. If the program is writing an FRD file then it should write it in the format for an FRD file. I don't know what REW has been instructed to do in this case?

I have seen programs have problems with FRD files over comments and 2 or 3 columns and now commas. It is remarkable how many ways there are to screw up such a simple format. The real problem is that an FRD file is not defined in a place where people writing FRD readers and writers will look.
 
I can share .NET C# sample code for header detection

Code:
// POSSIBLE HEADER CONTENT:
// * Comment line or header (REW)
// Smoothed Frequency Response (Arta)
// Resolution = 1/6 octave (Arta)
// Numpoints = 720 (Arta)
// SamplingRate = 48000 Hz (Arta)
// Frequency(Hz)   Magnitude(dB) (Arta)
// Freq [Hz]       dBSPL           Phase [Deg] (CLIO)
//    Freq 	     Mag 	   Phase (justMLS)
// Freq      dB         Phase (LspLAB)
// f[Hz]	Uncompensated level [dB}	Uncompensated phase [dB} (Edge)
// 5.07    36.25    -15.14  (no header in SoundEasy)
// 1.508	 80.2353	 -3.6363 (no header in Arta's plain frd export)

if ((sLine.Trim().StartsWith("*") || sLine.Contains("Hz") || 
    sLine.Contains("Freq") || sLine.Contains("Smoothed") || 
    sLine.Contains("Resolution") || sLine.Contains("Numpoints") || 
    sLine.Contains("Sampling")) == false)
        break;  // Exit header, sLine contains 1st data row

and international problems with decimal separator

Code:
using System.Globalization;
public static CultureInfo ciUS = new CultureInfo("en-US");

string sLine;
double dFreq;

// Read sLine from the file
//...
// Force decimal points for US culture
sLine = sLine.Replace(",", ".");

// Split data row
saLine = sLine.Split(new char[] { ' ', '\t' }, StringSplitOptions.RemoveEmptyEntries);

// Parse frequency
if (saLine.Length > 0)
    if (double.TryParse(saLine[0], NumberStyles.Number, ciUS, out dFreq))
    {
        // use dFreq
    }

// Parse magnitude...
// Parse phase...
 
If the program is producing a list of values for the user then a comma should be used if that is what the user specified. If the program is writing an FRD file then it should write it in the format for an FRD file. I don't know what REW has been instructed to do in this case?

Program is producing a list of values as txt file for another programs which may be located in different country & continent. Therefore all txt files which format is not specified inside the file and not for end user, could use common settings for numbers. Otherwise all reading programs need custom settings or intuitive flexibility for national perversions. Locally this would work if all programs in the same computer use common setting, but globally that's not enough.
We use commas as decimal separator in FIN which is stupid and frustrating when playing with international txt exports, IMO. I'll vote for global settings for txt :D
 
Hi zakman35,

I'll look into making the file reading routines accept commas as decimals (no promises, though, I don't want to slow down operation to do so).

Sorry, but without frd data, there's not anything valid (that I know of) you can do for simulating response. T/S is for design of boxes to simulate the low end's "highpass" cutoff and slope, but say nothing about higher frequency response.

The Parts Browser at present isn't useful, as there aren't any vendors hosting data for their components online yet (it's early days, still). Parts or Driver Browsers can't be loaded with user data (though that might be changed in future).

A problem with user-supplied driver files being hosted in the Browser is that FRD files would have to be supplied in a standardized way so they can be used with other published files. Not the dots/commas issue, but drive levels and delay reference values.

I'll be publishing a simple "spec" for making "Standard FRD" files at some time in future addressing this. Basically, this will stipulate that the curves are to be measured at 2.83Vrms at 1m distance (or equivalent combination of drive voltage and distance to get the same levels). On an infinite baffle. And with a delay reference plane specified in the header (nominally and ideally, at 58usec behind the driver's mounting plane). All that to be stated in a header of the file like:

"| Standardized FRD file, measured by OmniMic "xxxxxx.omm" on 11/19/2013 by userID:
"| Equivalent to driven with 2.83V and measured at 1m
"| Acoustic origin is 58.23useconds behind the mounting plane.
"|

Omnimic has some features (or soon will) to help generate such Standard files, but they could be done with data from other measurement systems as well.
The FRD files being supplied by Dayton for their drivers (only some, so far) are being made as Standard FRD files, btw.

Without using standardized driver files, the best way to make FRD files for design of a speaker is to measure each pair of drivers in their baffle, and determine their relative delay/phase relationship with Bagby's method (measuring each individually and both together, etc). Such files, though, couldn't be directly used for design with other drivers.

Sorry for the long reply!