Known Bugs and Problems (and Gripes)
This section is divided into two parts. Resound Bugs are known bugs in my own code. NeXT Bugs are bugs in the NeXT Sound Kit that Resound simply cannot work around. Frankly, I don't know if NeXT will ever get around to fixing them... oh, well. I do not include known bugs with any modules included with Resound--those are dealt with in the documentation for each module.
Resound has been tested on NeXTstation, NeXTstation Color, NeXTstation Turbo Color, Canon Object.Station 31, and Intel Professional GX workstations.
Resound Bugs
Resound prints only the visible window contents.
The ticks ruler often has rounding errors.
For module writers: Resound modules may receive the soundDidPlay and soundDidRecord methods more than once for the same sound.
For module writers: Some combination of Resound and the SoundKit corrupts sounds in soundviews that have been written out to a stream using writeToSoundfile:. For the time being, if you're programatically writing the sound, make a copy of it first, and write out the copy.
Rhapsody Bugs
A whole host of bugs have been introduced with Rhapsody's weak SoundKit. First and foremost, many sound formats have bugs when playing (including 16-bit, 44.1KHz!). Most mono formats have bugs in playing and in recording. Several formats (including 8-bit linear) don't display properly in the SoundView. And a nasty new gotcha: hooking SoundViews to windows often produces exceptions. See ModuleProtocol.rtf for more information on this bad one.
Older Next Bugs (which may or may not be still valid)
The time delay between a sound starting to play and its data finally making it out the speaker is so large that small sounds never even get a chance to update Resound on their status, and so never get any drawing on Resound's sound meter. Likewise, the sound meter (and tracker) often finishes 1-2 seconds before the sound has finished playing! This affect also occurs for the play mark, since its movement is tied to the meter and trackers.
Curiously, NeXT's own sound meter doesn't demonstrate anything like this, which suggests to me that NeXT is using some internal tracking mechanism that is bypassing the standard methods. If anyone can set me straight here, I'd really appreciate it.
Not all conversions are supported (namely, Emphasized, Emphasized/Compressed, 24-bit, and 32-bit formats).
Setting an unavailable combination of recording data formats, recording channels, and recording sampling rates in the Record Format Panel may confuse NeXT's sound system and make Resound unable to record.
Cutting and pasting a compressed or otherwise undisplayable sound may bomb the program.
If a sound is paused while playing, then after unpausing it, NeXT's sound system forgets how many samples had been played up to that point. As a result, the tracker and play mark are reset to 0 (try it and you'll see).
NeXT's Sound Views do not display oscilliscopic information properly, and often spit out PostScript errors when trying to do so. This bug was reported in the 0.8 version of NeXTSTEP and has still not been fixed.
NeXT's Sound Views allow you to select more than the actual sound, off to the right edge of the sound, when the window is larger than the sound data at its current scaling (zoom). Resound bypasses this for the most part, so the only effect is that you may have occasional odd results when shift-clicking in sounds.
NeXT's Sound Views restrict selection in a sound to the resolution of the zooming scale, which makes the selection change as scaling is changed. As a result, you may find that after zooming in or out, your selection has changed slightly.
The first sound recording on an Intel machine may result in zero sound bytes.
Because of what appear to be bugs in NeXT's sound conversion function, some conversions will bomb Resound on Intel systems.
Sometimes Sound Views do not display properly or at all on Intel machines.