Agreed. IMHO the most valuable part of the project is not the GUI, but reverse-engineering the file format, which must have taken a ton of time. Even if the code were total crap - which I’m sure it isn’t - being able to document the structure of the file format from the codebase would be a huge time saver. Implementing a new GUI and logic is not so much work for an experienced developer.
And I’m sure that @mzero would have found the time to polish the code and open source the project ages ago, had Elektron saved him that time by publishing and maintaining sysex documentation, as is good (but not common) industry practice. Why they don’t do that is beyond me, it’s not too much work, and enabling the community to build an ecosystem around your products beyond what you could have imagined or built yourself is never a bad idea.
Also, I prefer my data being mine, so open formats that enable me decode and reuse to the music I created long after I sold my device should not be a luxury, but common sense.
Or an experienced and motivated developer who steps up and bites the bullet, this happens way more often than you might imagine. And the complexity here is, as I explained above, not too frightening with all the excellent work that has already been done by @mzero
FWIW, I do most of my sequencing for my Elektron boxes in a Cirklon these days, and I only use patterns to store sounds, which gives me 64 “songs” per project. From time to time I make a backup and delete the “patches” I no longer need. That has simplified my workflow tremendously, and personally I appreciate having a much more capable sequencer more than the tight integration. And it’s so simple using trying out another device for any sound, which helps a lot with experimenting with sounds. But I understand how this would not be an option for a small setup.