Patch tools for the Echon 6: a working .ech6 library, a feature request, and some manual errata

lesjamusic · August 7, 2026, 3:20pm

Hi all! I’ve been deep in a rabbit hole with my Echon 6 and wanted to share where it’s led, plus a request for the Morphor and a few small manual corrections.

Over the past while I’ve built a Python library that reads and writes .ech6 preset files. It started as a personal patch librarian and grew into something more fun: I can now edit preset metadata (names, descriptions, categories, slot locations), generate new presets programmatically, and set a decent chunk of the sound parameters by name. I’ve been auditioning the results on hardware throughout, and it works: I’ve filled most of a bank with generated patches, first by recombining parameters from factory presets I love, and more recently by designing patches directly in code. The format has been partially mapped through diffing experiments (export a preset, change one knob, export again, compare), which is slow but effective. Happy to share the library or put it on GitHub if there’s interest, and I’d love to hear if anyone else has poked at this.

Which leads to the feature request: it would be wonderful to have the parameter layout of the voice group block inside a preset documented, or alternatively a SysEx path for reading and writing sound parameters by index. Either one would let community tools like librarians, editors and patch generators be built safely rather than by reverse engineering, and I suspect I’m not the only one who’d build things with it.

Finally, some small errata spotted in the v1.2 manual while working through all this: the MIDI CC table labels CCs 90 to 95 as LFO 3, but they appear to belong to LFO 4; the value columns for CC46 (fine tune) and CC47 (note offset) look like copy-paste errors from neighbouring rows; and page 97 still has a draft footer.

Thanks to the Morhpor team for an instrument that rewards this kind of obsession. The resonator architecture is genuinely unlike anything else I own, and the fact that the format is clean enough to work with from the outside says good things about what’s underneath.

attiph · August 8, 2026, 4:58pm

Not the same as what you did, but I actually started mapping out timbre and settings based on what sounded like realistic modelled instruments vs synthetic ones. An X/Y table. Essentially permutationally modulated parameters and then used the output against a large model of known instruments to see if I could figure out what would get me a tone I wanted from just a visual map.

Might be some overlap here. I felt the biggest challenge beyond just blindly epxloring (which I do not want to devalue how much fun this instrument is for that) was figuring out the type of sounds that I wanted relative to what actually needed to be modulated or changed.

I’m a python/C++ person myself so would love to see where you got with your project, equally happy to push my stuff up into a community repo as well if that is something we could do for the morphor community?

Eli · August 11, 2026, 8:00pm

Thanks for writing this up - this is exactly the kind of tinkering we hoped ECHON 6 would invite, and the fact that you got as far as you did by diffing exports says the format is at least reasonably sane, which I’m glad to hear.

On the feature request - both directions are worth doing, and they’re complementary:

Format documentation The on-device format is a versioned chunked container (payload chunk v1 today), and the voice-group layout has a clean structure we could publish later. That gets everyone off the diff-based reverse-engineering path, and the version byte gives you a clean signal to update whenever we change the layout.

Per-parameter SysEx is more work but it unlocks the live-editing case documentation alone can’t cover - real-time editors, DAW-side controllers, hardware bridges. The transport is already there (the configurator uses the same protocol and manufacturer ID), so most of the effort is enumerating parameters, deciding on the granularity for the modulation matrix, and picking sensible get/set command shapes. Realistic order: docs first, per-parameter SysEx next. If you have opinions on what you’d want that API to look like, I’d genuinely like to hear them.

On the errata, all three confirmed:

CCs 90–95 are LFO 4, not LFO 3 (label error).
CC46 / CC47 value columns are indeed miscopied from neighbouring rows.
Page 97 draft footer shouldn’t have shipped, sorry.

A corrected manual will go out with the next manual batch.

Thanks again! and for the kind words about the resonator. It means a lot that the format has held up under this kind of scrutiny.

lesjamusic · August 11, 2026, 10:10pm

Eli, thank you, this is a wonderful reply. Docs first, per-parameter SysEx next sounds exactly right to me, and I’ll happily take you up on the invitation to share thoughts on the API. Having spent some time building against the format from the outside, here’s my wishlist. All of it is offered as suggestions from one user’s vantage point, and I’m sure you’ll have better instincts on plenty of it:

Stable parameter IDs: get and set by ID rather than panel position, with IDs stable across firmware versions so tools don’t break on updates
Bulk read: a “get all parameters for a voice group” request, so editors can sync state on connect without hundreds of round trips
Native resolution: values in normalised form rather than quantised to 0-127, so external editors don’t lose resolution against the panel
Modulation matrix at slot granularity: source, destination, depth, polarity and mute in one atomic message per routing, rather than a stateful select-then-set sequence
A subscribe mode: panel moves emitting change messages, which is the difference between a librarian and a true bidirectional editor
Edit buffer vs stored preset: explicit control over which one a set touches, with a separate commit command
Smaller wishes: a format-version handshake before writing, and eventually a published parameter ID table in the manual appendix so the CC chart, SysEx API and file format all share one set of names

I’d also like to volunteer as a beta tester for both the format documentation and any SysEx draft. I have a working Python library for reading and writing .ech6 files, a growing corpus of generated presets running on hardware, and clearly far too much enthusiasm. And a small personal note: while I’m UK-based, I used to work for a Ghent-based company and have visited the city more than fifteen times. One of my favourite places in Europe, so it’s a pleasure to see what’s coming out of it.

Attiph, I love this, and I think our projects are two halves of the same tool. What I’ve built is the write path: named parameters in, valid preset files out. What you’ve been mapping is the part mine can’t do: which settings actually produce a wanted timbre. Between your X/Y map and my generator, “pick a point on the map, receive a loadable patch” becomes a real workflow, and your labelled listening data could steer generation toward targets instead of blind exploration, which is exactly the problem you described.

A community repo sounds great and I’d say let’s do it. My suggestion for shape: the format library and field map as the core, your timbre-mapping work as a sibling module since it’s a different concern and a C++ person shouldn’t need my Python stack to use the map, and a shared presets directory with generated patches and listening notes.

Eli, if a community repo like this is something you’d want to link from the forum once it exists, even better.

I’ll get my library cleaned up and pushed once it’s presentable, and Attiph, let’s compare notes on structure before merging your side in.

attiph · August 11, 2026, 10:42pm

@lesjamusic , @Eli - these are both amazing responses. I love this community.

To mirror what @lesjamusic has just said, I’ll get my work cleaned up a bit over the coming days and happy to regroup when there’s some momentum at pooling all our findings into a shared community repo.

Really the key thing for me… at least coming from a software eng’ background, is ensuring the format it arrives in, does so in such a way that it doesn’t cause breaking changes on version release. Naming standards / conventions that are agreed upon early will save 100s of development hours / improve quality of life for both the development team and the consumer.

One thing to call out though, I 100% agree with the Atomic message per routing from my findings depth, polarity and mute sit in three parallel arrays which would cause a race condition for stateful select-then-set if my understanding of the architecture is correct?

Voice groups surfaced in every message. Six groups, could thefile store them as six independent blocks. Any get/set needs a group index or the API would inherit the panel’s modal state.
The full set of LFOs and a knob sweep will flood a DIN link pretty easily afaik. If we were to rate limit (or change coalescing) rather than emite on every move.
There’s no checksumming as far as I can tell. Which means you could write / create a corrupted file and it would just silently go through. If this was surfaced in SysEx that might be a possible avenue to resolving that?
Seems to be no error states, again I could be wrong. But, a set with an out-of-range value or unknown ID returns nothing versus a NAK response. I feel this is pretty important for a “librarian” tool of sorts?
Finally one thing I’m less clear on atm, is a “get and set parameter by ID” API assumes everything in a preset is a knob with or per value, if each voice group holds around 33 records and 0-31 being panel destinations, that leaves 32 with a potential misbehaviour or something that’s not documented - again I am probably over complicating this more than it needs to be. But my understanding is if one were to write a patch, 32 would typically remain empty and result in an incomplete preset? The same would then be true for parameters that sit outside of the panel (note, velocity, aftertouch, etc) - So I guess the tl;dr is would the API cover the entire parameter list for the preset or JUST the sound parameters?

Peace out all!