Events#
This section is intended for those who want to delve into PyFLP’s low-level API or understand how internally events are ordered. A good understanding of FL Studio’s GUI is assumed.
When to use the low level API?#
If PyFLP fails to parse a particular model or you want to dive deep into the true / raw / real (whatever you want to call it) representation of an FLP.
See also
Binary layout of an event
Structure#
Very early versions of FL Studio were literally a dump of the changes taking place in FL’s GUI. Say for example, you create a channel and then add notes to some pattern; the events for those would be dumped in the same order.
Hopefully its not the same now, but some of those characteristics are still visible.
Caution
DO NOT use the following section as a definitive / complete source of information for adding / removing your own events. While most likely your events will get parsed correctly, there’s always a chance of corrupting your FLPs.
This is roughly the order of the events (as of latest FL Studio):
Project-wide / metadata
Display groups / channel filters
Initialised controls
Pattern notes / controllers
MIDI remote controllers
Internal remote controllers / automations
1st channel
Pattern metadata
Remaining channels
Arrangements:
Index, name
Playlist items
Time markers
Tracks:
All data except name
Name
Mixer:
Inserts:
A list of events in the order:
Color, name, icon and flags
Effect slots
Post EQ, input/output, routing
Remaining insert data
Channel rack height
Channel#
There are currently 5 types of channels (specified in ChannelType
).
Although some of them don’t use certain events, FL Studio dumps the same
event tree for any type of channel. For e.g. a Layer
channel will have
all the events a Sampler
channel has, irrespective of whether the
events have any meaning in that context. Certain channels have extra events.
# |
Event ID |
Model / property |
---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
|
|
5 |
|
|
6 |
|
|
7 |
|
|
8 |
|
|
9 |
|
|
10 |
|
|
11 |
|
|
12 |
|
|
13 |
|
|
14 |
|
|
15 |
|
|
16 |
|
|
17 |
|
|
18 |
|
|
19 |
|
|
20 |
|
|
21 |
|
|
22 |
|
|
23 |
|
|
24 |
|
Quite a few, refer code. |
25 |
|
|
26 |
|
|
27 |
|
|
28 |
|
|
29 |
|
A lot; spread across many models. |
30 |
|
|
31 |
|
|
32 |
|
|
33* |
|
|
34 |
|
|
35 |
|
|
37 |
|
|
42 |
|
Certain |
43 |
|
|
44* |
|
|
Pattern#
Pattern
events are serialised at 2 different places inside an FLP.
The first section contains the notes and controllers held by a pattern if any.
# |
Event ID |
Property |
---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
The next section contains colour, icon, timemarkers and any new events get added here. Some events aren’t listed because their order is not confirmed yet.
# |
Event ID |
Property |
---|---|---|
1 |
|
|
2 |
|
|
3 |
|
|
4 |
157 [7] |
N.A. |
5 |
158 [7] |
N.A |
6 |
164 [7] |
N.A. |
Acts as an identifier here.
Unknown events; complete list here.
VST plugin parsing#
Implemented in VSTPluginEvent
, this is arguably the hardest event to
parse cleanly. If you are familiar with PyFLP’s internals, you might be
surprised to know that this event has events inside events. Why a struct
wasn’t usable is beyond me.