Hey yo,
I decoded the A4 patch sysex to create a generator. It is working quite well, I am able to generate patches with a custom Processing script.
The generator is super rudimentary and not ready to share. But so far I want to release the sysex specs… Probably incomplete, but enough to create a working generator.
I am using the default sound patch as file template, load it and just change the values I want.
PDF attached.
[EDIT]: I removed the PDF… Please check the git repo.
Thanks for posting the document. Did you do all the the decoding yourself or use information from an existing depository?
Reverse engineered it myself…
Just put the tables on GitHub too: https://github.com/kimasendorf/elektron-analog-four-sound-sysex
Mind if I ask how you went about this? I’ve been wanting to get into this, but haven’t quite known where to start. 
Thanks so much; you’ve certainly gotten yourself a rather enthused thread sub. 
yeah sure… simply said:
I saved the initial sound and sent it as SySex over C6 to my Mac. I took it as the reference file to compare.
I changed one value, i.e. the TUN of OSC1 and saved it and sent it to my computer again.
I opened both files in a hex editor (because SySex is a hex encoded file) and compared them. By this I could see that the value change was reflected in Byte 43.
Then I figured out what the minimum and maximum values are.
Repeated it for each value.
Ah ok. That makes total sense.
I might see about doing this with pattern data here in a bit.
Cool! That could be really interesting.
Will release the generator soon, as Processing code. Wrote it last year and just realized it is quite well written…
I just started with the Digitone…
Agreed. - My primary interest in sysex has been for real-time generation/ modification of patterns from Max MSP.
I’ll be interested to see what comes of these; I’d messed around with Processing for visuals in the past, but it fell by the wayside when I started getting more into Max/ Jitter, etc.
I ported the generator from Java to JavaScript. Currently working on a user interface where you can adjust the random ranges and make use of gauß distribution to push the generator is certain directions…
Well sorry @asdf it would if the data wasn’t packed, which it is. It is categorically not sent plain readable. The majority has to be unpacked which reduces the list size of the entries quite significantly. Some actual used values are greater than 7bit which cannot be sent as midi data so the extra bits are encoded in groups of additional bytes. You can luck out doing what has been described if values are low and may be able to swap in certain bytes but assembling arbitrary data will lead to errors because the important data hasn’t been packed prior to submission. I am afraid I won’t be able to help any further, it’s fiddly to explain let alone process to put it mildly, Elektron don’t help either sadly. There are a couple of packing standards used by various manufacturers to send such data via sysex. You can probably fnd out about these packing schemes from the internet if you do some homework. For a dump of around 400 bytes around 50 or so are going to be composed of arranged bits extracted from other entries. That’s about all I can add, I had a hard enough time doing this for the cycles recently even following my own notes from doing it with the A4. It’s a thankless task sometimes to crack these because Elektron can change the size and true byte order at any time, one of the entries in the header is the version number for the particular scheme used so that older sysex files using a different scheme can be parsed properly. It retains backwards compatibility that way. I am not up to date myself now and may try again next time the firmware is updated. The header and footer bookend the packed payload which can have padding spread throughout it to accommodate new features. They are generally structured logically. The benefit of pursuing this diminished for me when OB was introduced, it’s also tedious to revisit when the firmware is changed. Eminently doable but needs patience and example sounds which use the highest parameter values, this too isn’t always obvious e.g for bipolar info. Maybe the packing/unpacking has been worked out already but the fact it wasn’t alluded to was reason to mention before tackling way bigger files like the patterns etc
I note this was even pointed out in a naming topic recently, but seemingly overlooked - surely you understand that Elektron wouldn’t contract the name of their patch in 2 or three parts - the name is split over 17bytes, but is in fact only 15bytes long as it is correctly rendered when it is processed - I;m not sure what’s being done here, but the foundations are very very shaky if you haven’t accommodated the data packing - you will corrupt certain values if you don’t decode/encode
Thanks for your input. At least in the sound patch sysex most values are not packed. Some values are encoded in a tricky way… that’s true. Osc fine tune, filter frequency, envelope and lfo depth. Those needed to be cracked.
However, I am able to generate fully working sound patch sysex…
I have no clue how the pattern or project sysex look like. Probably a lot more encoding.
I recently analyzed about 3.000 patches and created presets based on the assigned tags. Works really well. Just generated 1.792 patches and put them on my A4. Pretty funny…
