1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
//! IT-style mix-plugin table (OpenMPT extension).
//!
//! ScreamTracker / Impulse Tracker file formats can carry an
//! optional plugin section, originally introduced by OpenMPT, that
//! describes a chain of DSP / VST plugins applied to channels and
//! buses at mix time. The plugin payloads themselves are opaque
//! binary blobs (typically VST chunk dumps) — xmrs does not host
//! the plugins, but it preserves them verbatim so a round-trip
//! through the editor doesn't lose the author's mix settings.
//!
//! Non-IT formats leave the containing `Module::mix_plugins` field
//! at `None`.
use ;
use Vec;
/// Identification + routing fields for a single plugin slot,
/// mirroring OpenMPT's `SNDMIXPLUGININFO`. Identifiers are kept as
/// raw `u32`s because the four-character codes used by the format
/// are not always valid UTF-8 (and aren't always meaningful as
/// FOURCCs — some are numeric IDs).
/// One plugin slot. The `data` blob is the plugin's serialised
/// state (typically a VST chunk produced by `effGetChunk`); xmrs
/// treats it as opaque bytes.
/// Mix-plugin table for one module. Two parallel pieces of data:
/// per-channel routing assignments, and a flat list of plugin
/// slots referenced by those assignments.