I’d like to fig. out how to do thing like set trigs etc. via midi… I assume there is some sysex command or something.
Nothing as fancy as Collider, but can we get more info from Elektron on this area?
Same as all the other machines…you need to request the Pattern, decode, edit, encode, send it back
2 Likes
Ugh. Hoped things got easier… oh well…
There are no signs that Elektron has (ever) implemented sysex commands to control their sequencer in depth remotely.
Hi! Much respect for all your awesome efforts.
How is this request initiated (re: M:C)? I see how to send the data from the [SETTINGS]/CONFIG menu on the device, but is there a way to make the request over MIDI?
Another way of asking the same question: What happens in your Tensor app when the user presses GET KIT or GET PTN?
Sadly, I don’t use iOS for HW music making so I cannot try your app.
Regardless, hope you’re doing well- thanks again for all your amazing contributions to this community.
Cycles Get Kit: [0xF0, 0x00, 0x20, 0x3C, 0x11, 0x00, 0x6A, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x05, 0xF7]
Cycles Get Ptn: [0xF0, 0x00, 0x20, 0x3C, 0x11, 0x00, 0x68, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x05, 0xF7]
Samples Get Kit: [0xF0, 0x00, 0x20, 0x3C, 0xF, 0x00, 0x6A, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x05, 0xF7]
Samples Get Ptn: [0xF0, 0x00, 0x20, 0x3C, 0xF, 0x00, 0x68, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x05, 0xF7]
You can send this or translate the hex to integers and send that
2 Likes
That’s nuts 
- thank you. Cannot wait to try this out.
How did you discover this?
bsp / void did most of the leg work back when the RYTM came out for requesting / sending and decoding / encoding sysex. I use the library GitHub - bsp2/libanalogrytm: Portable Sysex Library for the Elektron Analog Rytm Drum Computer for all of my Elektron apps. For requests / sending, the only thing that changes is the Device ID (0x11 for Cycles, 0xF for Samples)…the majority of the work involves determing what each number in the sysex represents (after using the library to decode it)
If you just use the above commands, you will get an encoded kit / pattern. You need to decode it before doing anything, else the numbers are just garbage / random for us humans
2 Likes
Ah, so it was just guess and check based on things that had worked on earlier machines?
I have seen some things around re: 7-bit decode and checksums and such — I understand that I have some fun playtime ahead of me.
Thank you kindly for this help, I really appreciate it.
hello,
you guys sound technical enough to maybe answer my question.
i was wondering out of curiosity if there is a way to extract/download the whole software of a model:cycles to upload it in a model:samples or vice-versa.
admitting that the two hardware are the same of course (which seems to be), it should be theoretically possible to do so via sysex/usb, no ?
although if there is some kind of command to extract such info it will be well kept secret ; )
or reverse engineered it… any thought ?
If you’re on Linux, you can try Elektroid.
With the verbose option activated you can see the incoming and outgoing messages.
Read the post Elektroid, a GNU/Linux transfer application for Elektron devices - #97 by DG2 to add Model:Cycles support.
I hope it helps.
1 Like
interesting, Elektroid seems to be a good tool to understand the elektron hardwares under the hood.
i’m not sure if the OS and the code that runs the M:Cycles or M:Samples will be lying around in a folder though. and/or what is the comman to send it through the usb or midi connection to intercept it with Elektroid.
i don’t even know if both of these machines have exactly the same hardware, and if the difference is purely code/software… i was probably just wishful thinking ; )
anyhow, thanks for the input,
and happy music !
I’m curious about this too.
The only thing I can tell is that the OSs are distributed in a SysEx file, which is a set of SysEx commands.
$ hexdump -C -v model-samples_OS1.13.syx | head
00000000 f0 00 20 3c 0f 00 7f 01 0a 00 01 72 00 33 6d f7 |.. <.......r.3m.|
00000010 f0 00 20 3c 0f 00 7e 00 01 72 04 00 0a 3a 60 36 |.. <..~..r...:`6|
00000020 2e 00 40 6a 45 4c 45 33 00 00 00 00 14 30 30 33 |..@jELE3.....003|
00000030 38 31 00 2e 31 33 00 00 00 00 00 00 00 00 00 00 |81..13..........|
00000040 00 00 00 00 00 00 00 04 00 00 00 00 05 00 00 00 |................|
00000050 70 00 00 00 00 0f 00 00 00 00 00 00 00 00 02 00 |p...............|
00000060 00 00 44 00 00 00 3c 2c 04 00 00 00 00 00 00 00 |..D...<,........|
00000070 03 00 03 00 3d 30 00 09 00 7c 00 40 00 04 00 00 |....=0...|.@....|
00000080 00 00 08 04 00 09 3e 30 00 00 10 7c 08 00 2e f7 |......>0...|....|
00000090 f0 00 20 3c 0f 00 7e 00 01 73 00 00 04 00 00 00 |.. <..~..s......|
$ hexdump -C -v model-cycles_OS1.13.syx | head
00000000 f0 00 20 3c 11 00 7f 01 0c 00 01 72 00 36 29 f7 |.. <.......r.6).|
00000010 f0 00 20 3c 11 00 7e 00 01 72 19 00 0a 36 50 26 |.. <..~..r...6P&|
00000020 36 1f 40 7c 45 4c 45 33 00 00 00 00 15 30 30 33 |6.@|ELE3.....003|
00000030 38 31 00 2e 31 33 00 00 00 00 00 00 00 00 00 00 |81..13..........|
00000040 00 00 00 00 00 00 00 04 00 00 00 00 05 00 00 00 |................|
00000050 70 00 00 00 00 0f 00 00 00 00 00 00 00 00 02 00 |p...............|
00000060 00 00 44 00 00 00 3c 30 04 00 00 00 00 00 00 00 |..D...<0........|
00000070 03 00 02 00 3d 30 00 09 7d 70 00 40 00 04 00 00 |....=0..}p.@....|
00000080 00 00 04 04 00 0a 3a 20 00 00 10 7c 08 00 0e f7 |......: ...|....|
00000090 f0 00 20 3c 11 00 7e 00 01 73 00 00 04 00 00 00 |.. <..~..s......|
There is a function to convert Elektron SysEx messages (7 bit) to raw data (8 bit) messages in Elektroid in case you want to do some conversion or research on this. It will be even possible, and quite easy, to add a conversion command to the elektroid-cli to convert SysEx files to raw data messages and the other way around.
But without knowing anything about the hardware, I would be very careful with this. However, I think Elektron devices do some check over the OS code before actually installing it.
If you feel brave enough, just try to send the OS to the other machine but DO THIS AT YOUR OWN RISK and I’m not responsible for anything that could happen.
thanks for the info… i wasn’t aware of the 7 vs 8bit difference between the file formats.
i already tried sending the MS firmware in a MC using a sysex client on windows but without success. fortunately the MC was left untouched after a reboot ; )
i have the impression that Elektron has designed and mass produced one “Model:” machine and can easily create variations like “:Samples” and “:Cycles” just by rewriting the software and the cover as they are full digital engines. if that’s the case, the software should be exchangeable, and maybe a hack will popup one day.
although at this market price, why not get two separate hardware boxes and have more fun ; )
i’m going to stop my investigations for now.
So we’ve already been told
and the hexdumps above show that at least the first 3 sysex commands/messages in each file have that device ID at the 5th byte.
So I wonder if it’s the case, if you want to cross-load, of flipping the ID in the first sysex message ? The idea being that maybe the device reads the first message and decides “this file is not meant for me” … that would seem to be consistent with your experiment @kaboo. Of course, it could be that you need to flip the 1st and 2nd message, or the 1st and 4th, or all the messages up to number 10 or …
CAVEAT: I’m not going to risk this and I take no responsibility for anyone who tries it. I’m just speculating.
1 Like
Previous response from Elektron employee to this suggestion :
and there is more relevant discussion in other posts in that topic.
1 Like
Looks like the ID is 0xa for the Digitakt
$ hexdump -C -v Digitakt_OS1.30/Digitakt_OS1.30.syx | head -n 1
00000000 f0 00 20 3c 0a 00 7f 01 05 00 01 72 00 41 46 f7 |.. <.......r.AF.|
$ hexdump -C -v Digitakt_OS1.11.syx | head -n 1
00000000 f0 00 20 3c 0a 00 7f 01 05 00 01 72 00 39 04 f7 |.. <.......r.9..|
$ hexdump -C -v Digitakt_OS1.20.syx | head -n 1
00000000 f0 00 20 3c 0a 00 7f 01 05 00 01 72 00 3c 3d f7 |.. <.......r.<=.|
However, the devices themselves answer some messages with an ID that is not the same. It’s the 6th byte of the first message received.
$ elektroid-cli -vv info 2:/
DEBUG:connector.c:1982:(connector_init): Initializing connector to 'hw:2'...
DEBUG:connector.c:1991:(connector_init): Setting blocking mode...
DEBUG:connector.c:2003:(connector_init): Stopping device...
DEBUG:connector.c:886:(connector_rx_drain): Draining buffer...
DEBUG:connector.c:869:(connector_tx): Raw message sent (13): f0 00 20 3c 10 00 00 00 00 00 00 01 f7
DEBUG:connector.c:875:(connector_tx): Message sent (5): 00 00 00 00 01
DEBUG:connector.c:1006:(connector_rx_raw): Buffer content (66): f0 00 20 3c 10 00 04 00 0a 00 00 01 0c 23 00 01 02 03 05 04 50 52 00 51 10 13 11 12 20 21 00 22 23 30 31 32 36 40 00 41 42 46 53 54 55 56 00 57 58 59 5a 5b 5c 5d 00 44 69 67 69 74 61 6b 00 74
DEBUG:connector.c:1173:(connector_rx): Raw message received (66): f0 00 20 3c 10 00 04 00 0a 00 00 01 0c 23 00 01 02 03 05 04 50 52 00 51 10 13 11 12 20 21 00 22 23 30 31 32 36 40 00 41 42 46 53 54 55 56 00 57 58 59 5a 5b 5c 5d 00 44 69 67 69 74 61 6b 00 74...
DEBUG:connector.c:1182:(connector_rx): Message received (51): 00 0a 00 00 81 0c 23 01 02 03 05 04 50 52 51 10 13 11 12 20 21 22 23 30 31 32 36 40 41 42 46 53 54 55 56 57 58 59 5a 5b 5c 5d 44 69 67 69 74 61 6b 74 00
DEBUG:connector.c:886:(connector_rx_drain): Draining buffer...
DEBUG:connector.c:869:(connector_tx): Raw message sent (13): f0 00 20 3c 10 00 00 00 01 00 00 02 f7
DEBUG:connector.c:875:(connector_tx): Message sent (5): 00 01 00 00 02
DEBUG:connector.c:1006:(connector_rx_raw): Buffer content (25): f0 00 20 3c 10 00 04 00 0b 00 01 02 30 30 00 35 33 00 31 2e 33 30 00 00 f7
DEBUG:connector.c:1173:(connector_rx): Raw message received (25): f0 00 20 3c 10 00 04 00 0b 00 01 02 30 30 00 35 33 00 31 2e 33 30 00 00 f7
DEBUG:connector.c:1182:(connector_rx): Message received (15): 00 0b 00 01 82 30 30 35 33 00 31 2e 33 30 00
DEBUG:connector.c:886:(connector_rx_drain): Draining buffer...
DEBUG:connector.c:869:(connector_tx): Raw message sent (13): f0 00 20 3c 10 00 00 00 02 00 00 03 f7
DEBUG:connector.c:875:(connector_tx): Message sent (5): 00 02 00 00 03
DEBUG:connector.c:1006:(connector_rx_raw): Buffer content (18): f0 00 20 3c 10 00 06 00 0c 00 02 03 09 5c 60 0e 38 f7
DEBUG:connector.c:1173:(connector_rx): Raw message received (18): f0 00 20 3c 10 00 06 00 0c 00 02 03 09 5c 60 0e 38 f7
DEBUG:connector.c:1182:(connector_rx): Message received (9): 00 0c 00 02 83 89 5c 8e b8
DEBUG:connector.c:2081:(connector_init): UID: b88e5c89
DEBUG:connector.c:2093:(connector_init): Connected to Digitakt 1.30 (Digitakt)
Digitakt 1.30 (Digitakt)
DEBUG:connector.c:1842:(connector_destroy): Destroying connector...
These are the device IDs Elektroid uses.
And even more weird, if you look carefully at the sent raw messages you’ll see that the ID is 0x10 and Elektroid has been reported to work with several machines.