199
|
1 * I don't like the indentation style at all, but for the most part
|
|
2 I've left it alone.
|
|
3
|
|
4 * Much of the code looks ugly to me.
|
|
5
|
|
6 * The return value from SDL_RWread() is checked inconsistenly.
|
|
7
|
|
8 * Group the members of MidiSong into logical units, i.e. structs?
|
|
9
|
|
10 * The debug messages are probably a bit too noisy. I've removed one
|
|
11 particularly annoying one, but...
|
|
12
|
|
13 Some of them should be turned into error messages instead.
|
|
14
|
|
15 * Can the instrument handling be made more efficient? At the moment
|
|
16 different MidiSongs may separately load the same instrument.
|
|
17
|
|
18 Note that the MidiSong's audio format affects how the instrument is
|
|
19 loaded, so it's not as easy as just letting all MidiSongs share tone
|
|
20 and drum banks.
|
|
21
|
|
22 At the moment they do share the data that is simply read from the
|
|
23 config file, but that's just a quick hack to avoid having to read
|
|
24 the config file every time a MIDI song is loaded.
|
|
25
|
|
26 * Check if any of MidiStruct's members can safely be made into static
|
|
27 globals again.
|
|
28
|
|
29 * TiMidity++ adds a number of undocumented (?) extensions to the
|
|
30 configuration syntax. These are not implemented here. In particular,
|
|
31 the "map" keyword used by the "eawpats".
|
|
32
|
|
33 * The other decoders generally only read as much of the file as is
|
|
34 necessary. Could we do that in this decoder as well? (Currently it
|
|
35 seems to convert the entire file into MIDI events first.)
|
|
36
|
|
37 * Can it be optimized?
|