A quick filter synthesis for illustration. The blue curve is a system response for a filter designed with 5dB setting in "reverse phase dip required". The green curve is for 25dB. XMachina added 2 extra components to achieve this.
Use it or not, there is an option for such a target.
You can also find description for the "reverse phase dip required" parameter on page 24 in the pdf.
|Thank you very much for that, I'm sure I can make use of it. Oh yes and thanks so much for developing this software, it has helped me greatly even though I'm still getting to grips with it.
Another question, does XMachina try align driver phase in it's crossover design around the crossover points?
Another question, does XMachina try align driver phase in it's crossover design around the crossover points?
"Reverse phase dip required" target is the only way to align phase of ways in XMachina. The dip is searched in the crossover frequency and its surrounding, which is an octave fraction. However only one point is enough to consider the target is achieved.
RTFM
I have hence asking the question as a beginner but thank you for the lovely kind hostile reply.
I have hence asking the question as a beginner but thank you for the lovely kind hostile reply.
Sorry for snippy response, it was a moment of weakness. My only defense is that over the years I have seen literally hundreds of questions that were easily answered if only the poster had read the documentation. I assumed you were in that group. Mea culpa.
I have tried running XMachina under Win10/64, Win7/64, WinXP/32, no problems occurred. I suppose it should also work under Wine/Linux (or MacOS) but I haven't tried this yet.
Hi @XMechanik,
Very cool tool, indeed! I played around with it yesterday, based on an existing design and got results very near the current implementation - but improved, and much faster.
I would like to confirm that the software works under Wine on top of Linux (Manjaro). There are only few things not working perfectly, for example:
1. Importing images for for digitization of FRD /ZMA plots does not work. This seems to be a known bug as I read later in this thread.
2. The tab order in the design task definition window does not follow the layout. It makes using the tabulator during input quite impossible.
3. I'm dearly missing an undo function, especially in the target SPL setting. A click in the wrong place is made easily and results in having to redo the graph from scratch. Or, as an equally viable solution, if the list of coordinates in the middle might be interactive ...
But this is really a cool piece of software!
Kind regards,
iago
It's a good news, thank you. this is something I wanted to check out and still haven't found time for it.I would like to confirm that the software works under Wine on top of Linux (Manjaro).
When you click a wrong place creating spl target there is really no need to redo the graph from scratch. The points of the SPL target can be easily corrected with the mouse. Let's take an example of a wrong clicked point:I'm dearly missing an undo function, especially in the target SPL setting. A click in the wrong place is made easily and results in having to redo the graph from scratch.
to correct this, at first move the mouse close to the point until the cursor turns into pointig finger shape:
move the cursor (do not drag) vertically to the desired position and click:
the graph is corrected:
I didn't care about the tab orders at all when I was designing the window. Thanks for the notification, it is added to the list of things to be corrected.The tab order in the design task definition window does not follow the layout. It makes using the tabulator during input quite impossible.
Attachments
Last edited:
It's a good news, thank you. this is something I wanted to check out and still haven't found time for it.
Probably, for the record, I should have added the version info:
O/S version 5.9.16-1-MANJARO
Wine version wine-6.4
Wine version wine-6.4
When you click a wrong place creating spl target there is really no need to redo the graph from scratch. The points of the SPL target can be easily corrected with the mouse.
Maybe this is something that does not work under Wine:
1. Move mouse cursor near an existing point, cursor changes shape into hand
2. Left click and move mouse
3. After traveling a few pixels, cursor changes form back to cross; point is unchanged
4. On releasing mouse button, a new point is created in the new location
So it seems the 'grab' of the point is never performed and the click /release in its entirety is interpreted as creation of a new point. 2. Left click and move mouse
3. After traveling a few pixels, cursor changes form back to cross; point is unchanged
4. On releasing mouse button, a new point is created in the new location
Interesting thing is: if I click on the graph while the mouse is in drag mode (there is a small region around each point, the snap-in area), the point is moved. Due to the limited size of the snap-in area naturally only a few pixels.
After creating a lot of points by trying to drag them, I noticed another phenomenon. The snap-in is sensitive to the x-coordinate of the respective point, that is along a vertical line through the point.
That could be used as workaround to correct erroneous points 🙂
Kind regards,
iago
Attachments
After creating a lot of points by trying to drag them, I noticed another phenomenon. The snap-in is sensitive to the x-coordinate of the respective point, that is along a vertical line through the point.
That could be used as workaround to correct erroneous points 🙂
May I point out this again: do not drag the point. After the cursor changes into pointing hand just move the cursor up or down to desired level then make a single classical click. Be aware that the mouse cursor should be moved vertically so its snapping with the point is maintained. (This actually means that frequency of the point won't change)
How are things going with this topic?
On Jantzen audios homepage there is an export for their (air) coils which is interesting. The problem is that they make thousands of different coils, which most of them are not sold anywhere I know of. So they have sorry to say no "Mostly sold" list. And trying to import it to Xmachina I got a thousand error messages telling me that the value wasn´t that useful in XO designs 🙂. So that seem not to be a good idea to import the whoel Jantzen audio air coil production list.
Hi sharky
Being in Sweden i would suggest buying OM1 microphone from Line Audio. It requires No correction File, it measures between -+1dB from Line Audio directly. It is really small and seems to be what recommended for us in Sweden. I bought it rather Than behringer etc, a bit more expensive but better quality and made in sweden. You can contact the designer/builder directly thru Line Audio email. Kind of priceless if you ask me. Comes with a small box for storage and transportation that easily fits in your wallet.
Hi there!
maybe an option "avoid any unbypassed resistor in series to the woofer" can be useful, just a though..
Once You gain some experience on how it behaves, this thing is awesome.
Greetings from Maresme region, Barcelona.
maybe an option "avoid any unbypassed resistor in series to the woofer" can be useful, just a though..
Once You gain some experience on how it behaves, this thing is awesome.
Greetings from Maresme region, Barcelona.
Last edited:
maybe an option "avoid any unbypassed resistor in series to the woofer" can be useful, just a though..
If a series resistor occurs, it usually has a reason. First it would be good to analyze what XMachina wanted to achieve applying it. Compare the system response with and without (shorting) series resistance, and how it relates to the defined FR and impedance targets. If this leads to any conclusions, make adjustments to the targets and restart the design process.
Or, you may try a workaround. Create a dedicated list of resistors starting with value of, say, 5..10 ohms (adjust experimentally). Then select this list in the woofer way settings and restart the design. Resistors with such values are unlikely to be used in series with the woofer because it would degrade the response too much. These values are still useful for other branches of the woofer filter.
Attachments
Last edited:
Excellent! thanks XMechanik,
I thought that "follow the woofer" was enough to prevent that.
There is always something to learn.
I thought that "follow the woofer" was enough to prevent that.
There is always something to learn.

Last edited:
Out of pure curiosity, why XM never show out a solution that align the response reversing the polarity of a tweeter, or a midrange, like sometimes show even commercial products?
I don't know why this is happening. Reversing polarity of a loudspeaker is one of the legal design steps in XMachina. By analyzing the design process under control of a debugger, I can see that designer frequently changes polarity and looks for gains for such option. But as the process progresses, it happens less and less often. I guess I never got any final design with altered speaker polarity. An attempt of tracing why this is happening did not lead me to any conclusions for now.
Last edited:
Just a thought an early morning.
If one use XM with real measurements on for example a woofer and a tweeter in a cabinet and import the curves into XM the software will calculate out of real values and will therefore get a better result. Great! So here is my thought. What if XM were set up to create an XO based on an on-axis curve/values but also could include a number off off-axis curves/values. A looot more computation I know. Maybe possible to reduce by in wich order the computation is done, so only a few of the most reasonable on-axis designs are used as a base for the best off-axis designs to get the best overall design.
Just to be noted, I am not drunk, just got some free running thoughts from sleeping with open doors and windows during a hot Swedish summer night.
If one use XM with real measurements on for example a woofer and a tweeter in a cabinet and import the curves into XM the software will calculate out of real values and will therefore get a better result. Great! So here is my thought. What if XM were set up to create an XO based on an on-axis curve/values but also could include a number off off-axis curves/values. A looot more computation I know. Maybe possible to reduce by in wich order the computation is done, so only a few of the most reasonable on-axis designs are used as a base for the best off-axis designs to get the best overall design.
Just to be noted, I am not drunk, just got some free running thoughts from sleeping with open doors and windows during a hot Swedish summer night.
Last edited:
- Home
- Design & Build
- Software Tools
- Automatic crossover designing with XMachina