Playlist data structure error

[Renzic-Stone]

(如果你需要中文版本-请滑到下面)
(If you need a finished tool........Click here(FlpInfoer-By-Renzic_Stone))
An Arduous Journey to Decipher FL Studio Playlist Data Structures
-By Renzic_Stone
The origin of the problem: mysterious missing data
We encountered a puzzling dilemma when we started trying to parse the playlist structure of the FL Studio (.flp) project file in order to sort the pattern. According to the official PyFLP documentation, playlist events should contain the key attributes position, length, track and pattern. However, in actual parsing:

Properties mysteriously disappear
During parsing, all document-described properties mysteriously disappeared. the PlaylistEvent object, as if by magic, did not provide any of the expected data structures (position, length, track, and pattern).

misleading documentation
There is a serious disconnect between official documentation and reality, with promised attributes that simply don't exist in the project files, like chasing a phantom that doesn't exist.

So we decided to start parsing the raw data backwards

The Hard Road to Reverse Engineering

Phase I: Blind groping
Initially, a direct output of the complete raw data was attempted:
Each attempt was like groping in the dark, with 8000+ lines of debug output flooding the console without getting anywhere.

Phase II: Breakthrough Discoveries
On the verge of giving up, a chance output ignites hope:
'event type: PlaylistEvent, value type: ListContainer'
This unassuming output suggests to us that the really valuable data is gosh darned well hidden in the nested structure!

After parsing, we find:

Playlist events are double-wrapped
Outer layer: PlaylistEvent object with value attribute only
Inner layer: 26 real playback events disguised as normal values

Spooky track index deciphering:
Track index is not track but track_rvidx (requires 500 - track_rvidx conversion)
The pattern ID is not stored directly but calculated from item_index - pattern_base
Temporal attributes are physically present but not at the same level as the orbit

Stage 3: The Endgame
Through tireless efforts, the real data structure of the playlist was finally deciphered:

Attribute name Actual use Remarks
position Event start position (number of ticks) aligned with document but nested in the inner layer
length Duration of the event (number of ticks) You need to calculate the end position yourself.
track_rvidx track reverse index (0-499) need to be converted: track ID=500-track_rvidx
item_index Event global index for schema ID calculation
pattern_base pattern_id base value pattern_id = item_index - pattern_base
Lasting experience: for those who come after
This grueling reverse engineering taught us that:

The official documentation may only be an idealized model, the real data structure is often more complex and hidden (nested data structures why not write into the documentation AAAAAAAAAAAAAAAAAAAAh!)
Multi-layer nesting is a common strategy in audio software, where you have to peel the layers like an onion.

This difficult deciphering journey will open the way for all developers trying to parse FL Studio project files. Please add this knowledge, gained through blood and tears, to the open source knowledge base so that future generations will not have to repeat the hardships we went through!

这是中文版本(自动翻译可能会丢失原意,故添加)

破译 FL Studio 播放列表数据结构的艰苦旅程
-by Renzic_Stone
问题缘起：神秘的缺失数据
当我们开始尝试解析 FL Studio (.flp) 工程文件的播放列表结构以便于排序pattern时，遭遇了令人费解的困境。根据 PyFLP 官方文档的描述，播放列表事件应包含position、length、track和pattern等关键属性。然而在实际解析中：

​​属性神秘消失​​
解析过程中，所有文档描述的属性都神秘失踪。PlaylistEvent对象像被施了魔法般，没有提供任何预期的数据结构(position、length、track和pattern)。
​​
误导性文档​​
官方文档与现实严重脱节，承诺的属性在工程文件中根本不存在，像追逐一个不存在的幻影。

于是我们决定开始逆向解析原始数据

艰苦的逆向工程之路

第一阶段：盲目摸索
最初尝试了直接输出完整的原始数据：
每次尝试都像在黑暗中摸索，8000多行调试输出淹没了控制台却毫无进展。

第二阶段：突破性发现
在濒临放弃之际，一个偶然间的输出点燃了希望：
'事件类型: PlaylistEvent, value 类型: ListContainer'
这个不起眼的输出提示我们：真正有价值的数据被天杀的隐藏在嵌套结构中！

​​解析后,我们发现​​：

播放列表事件被双层封装
外层：仅有value属性的PlaylistEvent对象
内层：26个真正的播放事件被伪装成普通值

诡异的轨道索引破译：
轨道索引不是track而是track_rvidx（需要500 - track_rvidx转换）
模式ID不是直接存储而是通过item_index - pattern_base计算得出
时间属性实际存在但与轨道不在同一层级

第三阶段：终成正果
通过不懈努力，终于破译出播放列表的真实数据结构：

属性名 实际用途 备注
position 事件起始位置(嘀嗒数) 与文档一致但嵌套在里层
length 事件持续时间(嘀嗒数) 需要自己计算结束位置
track_rvidx 轨道反向索引(0-499) 需转换：轨道ID=500-track_rvidx
item_index 事件全局索引 用于模式ID计算
pattern_base 模式ID基准值 模式ID = item_index - pattern_base
永续经验：致后来者
这场艰苦卓绝的逆向工程教会我们：

​​官方文档可能只是理想化的模型​​，真实数据结构往往更加复杂隐蔽(嵌套数据结构为什么不写进文档里啊啊啊啊啊啊啊啊啊啊啊)
​​多层嵌套是音频软件的惯用策略​​，须像剥洋葱般层层深入

这一艰难的破译历程将为所有试图解析FL Studio工程文件的开发者开辟道路。请将这份用血泪换来的知识加入开源知识库，让后人不再重复我们经历的艰辛！