comparison decoders/timidity/TODO @ 199:2d887640d300

Initial add.
author Ryan C. Gordon <icculus@icculus.org>
date Fri, 04 Jan 2002 06:49:49 +0000
parents
children
comparison
equal deleted inserted replaced
198:f9a752f41ab6 199:2d887640d300
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?