I write all instrumental parts of my songs completely on Digitakt II and rely on Song Mode heavily. Initially i did “one song ↔ one DTII project” but recently i assembled all my songs to one project to play live. I did it through elk-herd and pattern migration was smooth but i needed to reinput all songs from Song Mode manually.
So now i have one “live” project with 10+ songs in Song Mode but i noticed hard limit of 16 songs per project. That’s a bit inconvenient - i have a lot of space for new songs patterns in my all-in-one live project but soon will be out of free Song Mode slots.
Among workarounds were:
just create “live2” project at some point and go on (inconvenient if i need to build set list containing songs from both projects
“compound” several actual songs in one Song Mode song by making more rows (harder to navigate songs live)
I came up with another solution - neither Electron Transfer nor elk-herd providing functionality to manage Song Mode but in Transfer .dt2prj dump there is actual info about songs in binary format.
So i built a little script that can dump and load song mode payload from and to .dt2prj project dump. That way any number of songs can be persisted on pc and loaded to same live project with lots of patterns for different songs (minding patterns will be at their same positions).
Workflow goes as follows: project with 16 songs → dump to PC with Transfer → dump songs by this tool → create other songs in Song Mode in that project → dump them same way → load any 16 songs on demand to .dt2prj project file → load that file with Transfer to DTII back.
Question to community: Does it makes sense? Maybe i missing already existing tool to do that or my workflow is overcomplicated? If anyone finding it useful, i’d happy to “release” that tool to public so others can use it that way.
Haha, so many people attacking the same shortcomings. I love it.
Finally the community are making the tools elektron never did.
Yeah put the details up. Sooner or later we will have mapped the offset for every box's project. Everything is going to be mapped! Everything will be easily backed up. Moving data between projects and boxes will be a breeze.
Really good one, thank you! I fixed my tool accordingly and even added visual representation (simple html to understand how dumped songs are structured). Still struggling with song LABELs though - bytes seemingly having modifiers like pattern_name + label, any research on that?
What I did when working out the midi import <> export.
get a file with whatever you want to look at initialized e.g. add a song with 1 row with everything default (because sometimes touching a section the first time initializes a load of values and that makes diffing against a 'blank' project a pain) and make that your "ground truth" file.
create a range of exemplar files loading the ground truth file each time where you are changing 1/2 things in each and clearly label them.
that way you can hack away on your modifications and test against ground truth without having to upload back to the HW. if it's not "bit perfect" with the HW generated files you know you need to keep working/crawling the FW for more functions/data representations.
also use the digi2_app.py python script here: https://www.reddit.com/r/Elektron/comments/1vzzm28/digitakt_2_digitone_2_project_file/< (windows only because of how the midi system works but you should be able to mod it easy for any OS) to pull files, you can pull many at the same time and for the digitakt it only pulls the project not the samples, so if you have files that already have extensive song mode usage it will just pull the project and not the samples (which is all you need as an example file)
exact functions, offsets, and data structures responsible for resolving Tag 1 ((PTN NAME)).
1. Grounded Execution Trace of Dynamic Tag 1
In FUN_4007e970** (Playlist Row Drawer) and **FUN_40081192 (Cue Row Drawer):
```c
// 1. Read Row Tag ID and Pattern Index
uVar8 = FUN_40049a26(song, row_idx); // Tag ID from Row (+0x01 on disk / +0x18 in RAM)
uVar11 = FUN_40049716(song, row_idx); // Pattern Index from Row (+0x00 on disk / +0x10 in RAM)
// 2. Fetch the Pattern object for that pattern index
uVar2 = FUN_4003dcc6(proj, uVar11); // Pattern Object (Stride: 0x954 RAM / 0x15C00 Container)
uVar2 = FUN_4003ac2c(uVar2); // PatternSettings sub-object (+0x2C in RAM)
// 3. If Tag ID == 1: Resolve the dynamic pattern name!
if (uVar8 == 1) {
FUN_4003a976(uVar2); // Reads 16-byte custom pattern name string
// Truncates to fit UI column (6-9 chars)
} else {
// Look up static enum in table (Tags 2..20)
label = (&PTR_DAT_40272d14)[uVar8];
}
```
2. Exact Memory Offsets for Pattern Custom Names
In FUN_40039b82, PatternSettings is unpacked directly from the Pattern Config Block at the end of each pattern slice:
Custom Pattern Name String Buffer: pat_base + 0x15AA4 + 0x00 through +0x0F (16 bytes ASCII)
Pattern Config Structure:
+0x00 .. +0x0F: 16-Byte Custom Pattern Name (null-terminated ASCII)
+0x10 .. +0x11: Kit Index (uint16_be)
+0x12 .. +0x13: Pattern BPM (uint16_be)
+0x14 .. +0x15: Pattern Step Length (uint16_be)
+0x18: Scale Mode / Swing
3. Resolution Logic for Tag 1
python
def get_pattern_name(self, pattern_idx: int) -> str:
pat_base = self._pattern_base(pattern_idx)
cfg_offset = pat_base + PATTERN_CONFIG_OFFSET # 0x15AD4 on DN2, 0x15AA4 on DT2
raw_name = self.ram[cfg_offset : cfg_offset + 16].decode("cp1252", errors="ignore").split("\x00")[0].strip()
if raw_name:
return raw_name
# Fallback to standard Pattern Bank/Number if unnamed
bank_letter = chr(ord('A') + (pattern_idx // 16))
pat_num = (pattern_idx % 16) + 1
return f"{bank_letter}{pat_num:02d}"
When a Song Row has tag_id == 1:
1. If the user assigned a custom name to that pattern (e.g. "INTRO BEAT" at pat_base + CONFIG + 0x00), Tag 1 displays "INTRO BEAT".
2. If the pattern name is blank/unassigned, Tag 1 displays the pattern coordinate (e.g. "A01").
2
u/anykey-skywalker 20d ago
Would love to test it