Decoding the Digitone SysEx

Elektron Gear Digitone/Digitone Keys
#21

unless you’ve unpacked the data (which will probably not be sent plain readable - a strategy used by some manufacturers) then you cannot meaningfully try to interpret the raw packed syx dumps in a hex editor - there’ll be no shortcuts to doing the tedious hard grind I’m afraid - that was my experience before overbridge editing came along

I doubt elektron will support this any time soon, from time to time the ordering of the payload will change and it’s not that much fun to map out the shifting around of maybe a hundred or two hundred parameters and to potentially support end users in dealing with it

2 Likes
#22

When I did this for the Rytm, I would:

  • make one parameter change
  • request sysex
  • decode / unpack sysex…if you don’t decode then you will not be able to map / make sense of the data
  • compare resulting array of ints to the decoded default project using Beyond Compare (very useful)

*sometimes multiple parameters will be encoded to the same int…for example on the Rytm, microtiming and TRC values are all encoded into one final byte

4 Likes
#23

The data itself doesn’t seem to be packed or encoded in any sort of way. Like I mentioned before, I haven’t dived into the actual patch data yet, but all of the metadata on the patch was quickly discernible and lines up with the work done in libanalogrytm. You can see the patch names in plaintext from the dump. Of course, this is my first time attempting to reverse SysEx information without any documentation.

The whole bank/counter byte thing is just confusing. It looks as if they started implementing it and then stopped once they realized counting up to 256 patches would eventually produce a F7 byte which would kill the SysEx message prematurely.

I’ve been working out of a Jupyter notebook on all of this and my progress can be looked at here: (so glad gitlab is doxxing me)

Note that the notes included in here are to myself and may not make a lot of sense at times.

1 Like
#24

A few things,

You want to get your hands on the following documents from Elektron.

mnm1_22_sysex.pdf
md1_53-sysex.pdf

As far as I am aware. Sysex messages from the MNM and newer machines, are “packed” .
Packing is a rudimentary form of compression explained in the above documents.

Each elektron sysex message ends in a length and checksum.

The headers vary from machine to machine, but I expect that there is some consistency amongst the new machines. Ie A4, RYTM and so on.

3 Likes
#25

I would imagine looking into DT sysex might also help here since DN and DT hardware is very similar and they have been released and developed around the same time period…?

1 Like
#26

Thanks for your pointers! I just requested those files from Elektron, hopefully they’re still being nice about sending them out. If not, it looks like there was some healthy discussion on how that machinedrum packed it’s sysex out there.

#27

No worries. The MNM document is the going to be the most useful one, as it explains the packing compression.

Also, in some instance some data is 7bit encoded, which is also explained in the docs.
You’ll likely need to devise a way of identifying 7bit encoded chunks. Can’t think of a clever way off the top of my head.

Liking the thoroughness of you work thus far, will keep an eye on the progress.

1 Like
#28

And here I was coming to ask if the Digitone uses the same .syx files as the other elektron gear :frowning:

#29

have you tried just calling them and asking for the documentation?

#30

Yes

#31

bump, any update on parsing the sysex? Considering buying a Digitone to make an app, but the lack of sysex documentation makes me :sweat:

#32

Someone send me a Digitone… :crazy_face:

I’ll build a Standalone / VST / AU editor for it… go along with the Analog Rytm one…

2 Likes
#33

I’ve made it pretty far. I had to shelve the project for a little bit because my semester got a little hectic. I’ve been able to locate the bytes that represent all of the parameters. With a few more hours of work, I should have a functional python library for the digitone. I’ll see if I can spend some time on it early next week and post some actual results.

4 Likes
#34

Nice job. Are you dealing with the Project sysex or Sound?

#35

So far I’ve just been dealing with sound because it’s the most pertinent to what I’m doing. However, I have no reason to believe that the pattern data would be no different than libanalogrytm.

I’ve taken a look at both the Pattern and Project sysex but haven’t done much in that area. The Project sysex is just a collection of all the Patterns, Track Sounds, and Sound Pool sounds as individual messages.

5 Likes
#36

Bump, any news?

#37

:nerd_face:

1 Like
#38

Somewhere there is a function that runs when the user does sysex import and export. (Elektron) Open your editor, paste that function into the forum.

redacted: part where i say everyone in the world is a big jerk except for me.

1 Like
#39

Yeah, it would take an hour for someone with the info to just paste a script that decodes / encodes the sysex…also maybe give us the sysex command to request the current sound sysex on Track X…maybe they want to wait on a finalized OS? Argh…

#40

Of course someone “could”. But at least in my job (software architect) I can get sued when doing something like this and I would lose my job for sure. It doesn’t matter if the information is important or critical or not. It’s simply part of my contract that any information is disclosed and as far as I know so it is in almost all IT contracts here in Central Europe.