I’m working on a project to build a patch generator for the Digitone. I’ve poked around and even reached out to Elektron directly, but I have so far been unable to find any documentation on the SysEx dumps themselves. I’ve dumped the sounds out and have been able to isolate them into individual patches fairly easily. I’m in the process of reverse engineering the patch data but it’s a rather tedious process.
Has anyone taken a crack at looking at this SysEx data or any other SysEx data like this have any pointers?
I don’t think anyone has reversed engineered it yet…not sure how much libanalogrytm will help. Maybe the checksum functions are the same (?). What did Elektron say? Every single time I have reached out to them for anything I have been disappointed with their lack of response / interest.
If you are reverse engineering the sysex dumps, you need to make sure to decode them first else nothing will make sense.
It’s a shame companies don’t do an ‘approved tools/engineer’ program to allow proven individuals to sign nda’s Etc , and get access to this information (assuming it’s been developed internally to a suitable level)
Everyone wins…
Developers can do tools unlikely to be made by companies
Users get additional tools to make their hardware more accessible , even if companies have moved onto other things…
Developers might find issues that help companies.
There must surely be enough controls , legal things , security to allow a small confidential group if developers to get involved .
Not only elektron , other companies could benefit from this , especially if there’s a deadline to release hardware but a lack of development on internal tools just means users will be frustrated.
I’m not talking about hardware / os development with proprietary tech / routines … just enough to develop librarians , editors , backup solutions … it would surely have helped octaedit, collider , and can ensure users find gear easier to use , more likely to keep and recommend to others.
Most companies wont ever spill out their guts but take them to their graves. There are so many phased out products in the world without further hope for any support because their companies did not release anything about them… take my bb passport, one of the most advanced mobile phones ever, now a 600€ brick because you cant decrpyt it’s bootloader and put a custom firmware on it…
@mekohler When I reached out to elektron, they told me that they did not have any SysEx documentation available (after waiting a week for their reply). They then told me to just check here to see if anyone else had done it.
@jingo could you imagine what the open source community could do with the DSI Tempest?!
I’ve made some pretty good progress last night looking at the Digitone sysex information. I have been able to identify the location and encoding scheme of the tags (most important for my reasons at the moment), the prefix, meta data, and patch name locations. There is quite a bit of data that does not change at all between patches which should be fairly easy to filter out.
A company gives up nothing by publishing sysex implementation, accept for the effort required to document and publish. I’ve done some of this reverse engineering in the past and as noted, many times there is a great deal of trial and error.
On modern equipment I assume there is some kind of proprietary format in use that doesn’t adhere to midi spec, hence the lack of public documentation. Perhaps that is the case here, and if so, it isn’t fair to assume that laziness or protectionism are the reasoning. It may come down to technical reasons.
I’m not sure yet if there is a checksum to be calculated. So far, I’ve only been able to decode the metadata of the patch and haven’t dived into the actual parameters of the patches. I’ll be looking through libanalogrytm to see what the checksum calculations are for the rytm. I would assume that they wouldn’t just go reinventing the wheel each time they made a device.
Sysex and doing things in the firmware are very very different … maybe I misunderstand the point with the tempest though… I assumed it had some type of librarian / editor…
Open source - again it’s different to my understanding of sysex. I can see the expectation for people to recode / use hardware how they’d like to once the official support is dead , but that is very different to wanting sysex
My understanding of decoding sysex is purely to understand the structure of how pattern data , patch data , songs or whatever are stored.
It’s a very very different thing to adding functionality to a device , it’s not going to give anyone the ability to add another filter or something…
Doing firmware is basically like trying to understand an Xbox so you can make your own console.
Incredibly massively hard to do .
My point on the tempest was the fact they cut official support and have considered it a ‘finished’ product. It still has many bugs and functionality that was promised but never delivered. It was a little off topic to bring up the tempest, but it would be wonderful if they allowed hackers to get into that machine and continue development of it.
Sure , that’s not sysex , that’s a new firmware … I wouldn’t ever imagine they’ll release the libraries and dev environment to allow anyone to do it.
Working on a plug-in for ableton , making a plug-in for vcvrack , making a game in unity isn’t hacking. .
To turn tempest into another device , from nothing , even with a binary of the firmware , virtually impossible and not worth the effort.
No matter how old things get in terms of hardware / software , i don’t think I’ve seen any big company do this , certainly not Sony , Nintendo , Microsoft , Samsung , Roland , Yamaha , nvidia , ati, arm , Apple , novation , mfb, access , etc etc etc .
A few game companies have , but even then duke nukem , doom was their own engine , and their companies grew from a shareware / dos / pc software background.
You’ll never see EA release any source code for assassins creed , no matter how old it gets.
I encourage your efforts as I am a programmer myself… and hopefully you will be able crack the sysex dumps and use them for support of the digitone :)!
Have developed a Standalone / AU / VST editor for the Analog Rytm that does everything that Overbridge does and more apart from audio streaming as I don’t have access to the 3rd party drivers at the moment.
Same for Analog Four / Analog Keys
And some other ones over the years; like Yamaha RS7000; DX200; AN200 etc
Unfortunately a lot of the time it can boil down to a whole bunch of time and trial and error.
So not just me then
It probably would have; instead (like others) got nothing, and did it all anyway.
It looks like I will be putting a lot of time into this, but the whole point of doing this is a learning experience.
I’ve been digging into libanalogrytm for the past hour or so and it’s been a great help so far, though my C++ knowledge is rather weak. While there are some differences, it looks like the general SysEx scheme is very similar. This definitely makes me doubt that Elektron has no SysEx documentation available.
Any tips on figuring out the parameters? My current plan is to duplicate patches with one parameter changed per duplication and simply analyzing the bytes that change to see what the difference is. That’s how I was able to figure out the location of all the patch meta data.
Another odd thing I’ve noticed: The first 128 patches in each bank have a byte that counts up from 00 to 7F, then stops. Each bank holds 256 patches and I have so far been unable to locate another byte that increases in the same manner for the second 128 patches. There also does not seem to be a byte to indicate the which bank the sound should belong to. The lack of a bank byte makes sense but the counter byte is a little worrisome.
Did you encounter anything similar when missing with the A4 or AR?
