Parse FL Studio 2024/2025 playlist items (80-byte records)

[CryptoJones]

What

FL Studio 2024/2025 (21.2+ / 25.x) grew each playlist item to an 80-byte record — a 20-byte tail (_u4) after FL 21's 28-byte tail (_u3). PlaylistEvent only knew the 32- and 60-byte layouts, so FL 2024/2025 playlist events fail the size check and their clips are dropped. Fixes #200 and the same underlying cause behind #199 / #177.

The record

Full 80-byte layout, verified byte-for-byte against FL Studio 2025 (25.x) saves:

offset	field	notes
0	position	u32, PPQ ticks
4	pattern_base	u16, always 20480
6	item_index	u16
8	length	u32, PPQ ticks
12	track_rvidx	u16, 499 − track
14	group	u16
16	_u1 / item_flags / _u2	existing constants
24	start_offset, end_offset	f32 ×2
32	_u3	28 bytes (FL 21)
60	_u4	20 bytes — new in FL 2024/2025

item_index selects the item type: < 20480 references a channel by iid (an audio clip if that channel's ChannelID.Type == 4, an automation clip if == 5); >= 20480 is a pattern clip (pattern_base + pattern#).

The change

• Add _u4 gated on a new fl2025 struct param; extend SIZES to include 80.
• Detect the record size by which fixed length divides the payload, preferring the 60-byte reading on a 60/80 common multiple, so files that parsed before are unaffected.
• Add a synthetic-event unit test asserting the 80-byte records parse and round-trip; full suite stays green.

Known limitation (documented in-code)

A freshly placed clip is exactly 80 bytes, but clips edited in FL (fades, slices, resizes) carry extra per-clip data and grow past it — so a heavily-edited project's Playlist event can be variable-length and still not match a single fixed size. Fully general handling would need the project's FL version to disambiguate; this PR fixes the common (fresh / programmatically-written) case without regressing anything.

How this came up

I hit this building FL-Studio-MCP-Server — an MCP server that lets Claude Code drive FL Studio and generate/edit .flp projects, with PyFLP powering its offline route. Writing FL 2025 audio-clip arrangements is what surfaced the 80-byte record, so the parse fix belongs upstream. Thanks for PyFLP — it's a joy to build on. 🙏

🤖 Generated with Claude Code

Proudly Made in Nebraska. Go Big Red! 🌽 https://xkcd.com/2347/

[Meowrium]

Additional findings: FL26 needs two more fixes on top of this PR

I hit the same wall parsing FL26.1.1 projects (both re-saved FL26 files and legacy FL20.5 files on my rig). This PR's 80-byte layout is correct for FL 2024/2025, but FL26 grows each playlist item to 88 bytes — a further 8-byte tail (_u5) after the 20-byte _u4. Verified byte-for-byte: 32 base + 28 _u3 (FL21) + 20 _u4 (FL2024/25) + 8 _u5 (FL26) = 88.
More importantly, the 80/88-byte PlaylistEvent is not the first thing that derails PyFLP on FL26 files. There are two earlier format changes:

1. Event 0xAC (DWORD+44) is varint-length in FL26, not fixed 4 bytes. This is the real stream derailer — itoccurs in the project header (right after FLBuild), so every subsequent event is misaligned and channels ends upempty (NoModelsFound). Old files never contain 0xAC, so gating it as a varint read is regression-free:

elif id < TEXT:
if id == EventEnum(0xAC):
size = c.VarInt.parse_stream(stream)
value = stream.read(size)
else:
value = stream.read(4)

2. FL26 writes a small NotesEvent (0xE0, ~21–34 bytes) in the project header before any PatternID.New. PyFLP'sPatternCollection.iter buckets it under cur_pat_id=0 and surfaces a phantom pattern (1 junk note, no Newevent → Pattern.iid raises KeyError → arrangements crashes). Skip the id-0 bucket when it contains noPatternID.New.

With all three changes (this PR's 80-byte + the 88-byte extension + 0xAC varint + phantom-pattern skip) I parseFL26 projects fully: 10 channels / 616 notes, and a 15-channel project at 1302 notes, with legacy FL20.5 filesunaffected (regression-checked). Happy to open a PR with the combined diff + tests if you're interested.

Sorry for AI sloping, as I'm really poor at progamming, but it works.