FxMath LR Studio
A desktop application that drives a quantitative research pipeline from raw broker bars to a compiled, deployable MetaTrader 5 Expert Advisor — and then reports honestly on whether that EA is worth trading.
What this is
FxMath LR Studio is a graphical front-end over a set of Python research scripts. It does not re-implement the trading engine, and it does not hold any hidden state. Every stage it runs is a command line you could type yourself, executed as a subprocess, with its output streamed verbatim into a log panel.
That design choice has three consequences worth stating up front, because they explain almost every behaviour later in these docs:
- Every command is visible and copy-pasteable. There is no proprietary execution path. If the app can do it, you can do it in a terminal — and get the same artefacts.
- Nothing is cached in the app. All state is read back off disk from the files each stage wrote. If you run a stage by hand, the app picks up the result on its next refresh.
-
Changing a script changes the app. Edit
feature_search.pyand the GUI uses the new behaviour with no rebuild, because it never imported it.
The problem it solves
The pipeline underneath is long and unforgiving. Seven stages, eleven feature
sets, hundreds of grid-search combinations, and a set of binary artefacts
(.mq5 source, compiled .ex5, JSON summaries, HTML
reports) that must be produced in order, from the right data, before
anything can be trusted.
Run by hand that means remembering exact flags, watching long silent runs,
and — the expensive mistake — losing track of which file came from which
run. The repository happily holds identically-named EAs and tail folders
from a dozen earlier attempts, side by side. An old .ex5 will
sit next to a new .mq5 and look perfectly compiled.
The app addresses that with three things a shell does not give you: a step tracker with real progress parsed from the pipeline's own output, freshness checks that compare artefact timestamps and flag stale results, and a single ordered chain that stops at the first failure instead of letting a later stage consume yesterday's configs.
The pipeline at a glance
Seven stages, strictly ordered. Each consumes the previous stage's output.
Presets methods the
individual pages use.
What it produces
At the end of a successful run you have:
| Deliverable | Where | What it is for |
|---|---|---|
| MQL5 Expert Advisor | strategies_lr_m5/all9/*.mq5 |
The generated source, ready to compile and attach in MT5. |
| Compiled binary | …/all9/*.ex5 |
The build artefact. Success is judged from this file, not an exit code. |
| Delivery report | report_m5_performance.html |
Cost basis, equity, per-slot curves, best hours, the exact 24h-vs-window replay, and the holdout — in one file. The one to hand to a human. |
| Per-set analysis | report.html |
How each individual feature set performed, with its in-sample caveat. |
| Holdout report | tail_holdout_report.html |
The warm/cold unseen-tail comparison. |
| Machine summaries | …/<set>/summary.json |
Slot metrics, parameters and feature lists — everything the GUI reads back. |
The honesty rule
The app enforces this distinction visually rather than hiding it. In-sample metrics are labelled as such, staleness is surfaced as a warning rather than silently tolerated, and the hours search shows both the half a window was chosen on and the half it was not, side by side — because a window with a large total and a negative out-of-sample half is an artefact of the search space, not a session edge.
Nothing here is financial advice. Forward-test on a demo account before risking capital.
How the pieces fit together
Then, each step in detail
Reading order
If you are new to the system, read in order — the step pages assume the vocabulary defined in The LR Engine. If you are here to debug something specific, jump to Troubleshooting or the Glossary, both of which are self-contained.