I don’t know the basis for this thread.
Box #16, Transfer a and b to
Maybe it’s early, maybe I have a lot on my mind.
I think it’s the mixer everyone’s been clamoring for.
They made it just to make it, and then purposefully didn’t release it. Like Mario: The Lost Levels or that first Godspeed You! Black Emperor cassette. It exists solely to be impossible to acquire
Now you’re talking – a mixer with parameterized polyphonic effect sends.
A mixer called… “Transfer”.
You can attach it to the model samples to add sampling abilities
God, I just love these kind of threads 
It’s the battery handle, which supports sysex.
I sniffed some SysEx Messages from my Digitakt and
what I actually got was F0 00 20 04 3C 10.
Any ideas for what this fourth byte 0x04 actually stands for?
This thread is still very relevant as Model:Cycles is 17.
… which is why I began the topic. 
I thought it was before the M:C. I remember now.
Are you sure?
I still think you’re onto something @PeterHanes. The most feasible answer is always the simplest one. If Cycles is 17, another box was missed out for whatever reason. Maybe it’s been delayed or cut at the last minute. But super good detective work here 
Somehow that makes absolutely no sense. Are you really sure about the “04” in between “20” and “3C” (the 3 bytes after “F0” are the manufacturer ID)?
Elektron ESI AB should be “00 20 3C”.
“00 20 04” is “Böhm electronic GmbH”.
source: https://www.midi.org/specifications/item/manufacturer-id-numbers
One might wonder if a sysex editor was used to edit the identifier that 15 & 17 could be switched, so that you could change a Cycles to a Sample or vice versa?
it doesn’t seem even remotely related to the DT anyway leaving aside the first anomaly - the 10 you are thinking is relevant would be 0A in hex - whatever else is happening you have a bunch of F0 immediately followed by F7 which is a little peculiar
Ah, Heureka! That’s not a standard MIDI message dump, but it’s an USB MIDI Event Packet containing all the USB specific bits & bytes which travel over an USB connection. It needs to get decoded first to get the real midi message.
So everything’s fine. You cannot read it the plain way.
Just as example (the old USB MIDI 1.0 specs):
I have never studied this kind of language but I really enjoy reading these posts. Hats down to those who understand the language under the hood.
Respect.
Exactly that.
If anyone is interested in how to decode and encode these messages you can take a look here.
Also, when running Elektroid at full verbosity the message exchange can be clearly seen.
$ elektroid -v -v
Using [...] as local dir...
Initializing audio...
Adding hw:0 (Elektron Digitakt) Elektron Digitakt MIDI 1...
Loading devices...
Selecting device 0...
Initializing connector to 'hw:0'...
Setting blocking mode...
Stopping device...
Raw message sent: f0 00 20 3c 10 00 00 00 00 00 00 01 f7
Message sent: 00 00 00 00 01
Raw message received: f0 00 20 3c 10 00 04 00 01 00 00 01 0c 10 00 01 02 10 13 11 12 20 00 21 22 23 30 31 32 40 00 41 42 44 69 67 69 74 00 61 6b 74 00 f7
Message received: 00 01 00 00 81 0c 10 01 02 10 13 11 12 20 21 22 23 30 31 32 40 41 42 44 69 67 69 74 61 6b 74 00
Raw message sent: f0 00 20 3c 10 00 00 00 01 00 00 02 f7
Message sent: 00 01 00 00 02
Raw message received: f0 00 20 3c 10 00 04 00 02 00 01 02 30 30 00 33 32 00 31 2e 31 31 00 00 f7
Message received: 00 02 00 01 82 30 30 33 32 00 31 2e 31 31 00
Connected to Digitakt 1.11
Raw message sent: f0 00 20 3c 10 00 00 00 02 00 00 10 2f 00 f7
Message sent: 00 02 00 00 10 2f 00
Raw message received: f0 00 20 3c 10 00 04 00 03 00 02 10 00 00 00 00 00 00 00 00 00 00 00 44 64 72 75 6d 20 6d 00 61 63 68 69 6e 65 73 00 00 00 00 00 00 00 00 00 00 00 00 44 64 72 75 00 6d 73 00 00 00 00 00 00 00 00 00 00 00 44 45 00 6c 65 6b 74 72 6f 6e 00 20 53 50 00 00 00 00 00 00 00 00 00 00 00 44 00 69 6e 63 6f 6d 69 6e 00 67 00 00 00 00 00 00 00 00 00 00 00 44 6c 6f 00 6f 70 73 00 00 00 00 00 00 00 00 00 00 00 44 00 72 65 63 6f 72 64 65 00 64 00 00 00 00 00 00 00 00 00 00 00 44 73 69 00 6e 67 6c 65 20 63 79 00 63 6c 65 00 00 00 00 00 00 00 00 00 00 00 44 00 77 61 76 65 74 61 62 00 6c 65 73 00 f7
Message received: 00 03 00 02 90 00 00 00 00 00 00 00 00 00 44 64 72 75 6d 20 6d 61 63 68 69 6e 65 73 00 00 00 00 00 00 00 00 00 00 44 64 72 75 6d 73 00 00 00 00 00 00 00 00 00 00 44 45 6c 65 6b 74 72 6f 6e 20 53 50 00 00 00 00 00 00 00 00 00 00 44 69 6e 63 6f 6d 69 6e 67 00 00 00 00 00 00 00 00 00 00 44 6c 6f 6f 70 73 00 00 00 00 00 00 00 00 00 00 44 72 65 63 6f 72 64 65 64 00 00 00 00 00 00 00 00 00 00 44 73 69 6e 67 6c 65 20 63 79 63 6c 65 00 00 00 00 00 00 00 00 00 00 44 77 61 76 65 74 61 62 6c 65 73 00
[...]
0x7f, which are not allowed in the content of a SysEx message, so they need to be converted to 7 bit chunks and for every 7 chunks an additional byte containing the 7 missing bits is added.Notice that MIDI USB messages are always 4 byte packages, which payload may vary from 1 to 3 bytes with 0 padding and where the first byte specifies the content type. See section 4 (USB-MIDI Event Packets) on the quoted document.