9. Sound effects

9.1

Some games, from Version 3 onward, have sound effects attached.
These are not stored in the story files (or the Z-machine) itself,
and the interpreter is simply expected to know where to find them.
Other games have only one sound effect, usable in a much more restricted
way: a beep or bell sound, which we shall call a "bleep".

9.1.1

In Version 6, the interpreter should set bit 5 of 'Flags 1'
if it can provide sound effects beyond a bleep.

9.1.2

In Version 5 and later, a game should have bit 7 of 'Flags 2'
set in its story file if it wants to use sound effects beyond a bleep.
The interpreter should then clear this bit if it cannot oblige.

9.2

Sound effects are numbered upwards from 1. Number 1 is a
high-pitched bleep, number 2 a low-pitched one and effects from 3 upward
are supplied by the interpreter somehow for the particular game in
question.

9.3

Sound effects (other than bleeps) can be played at any volume
level from 1 to 8 (8 being loudest of these). The volume level -1
should be implemented as "loudest possible".

9.4

Bleeps are immediate and brief. Other sound effects take place
in the background, while normal operation of the Z-machine is going on.
Control is via the sound_effect opcode, allowing the game to prepare,
start, stop or finish with an effect.

9.4.1

The game may (but need not) "prepare" a sound effect before
use. This would indicate to the interpreter that the game intends
to use the effect soon: an interpreter might act on this information by
loading the sampled sound off disc and into a memory cache.

9.4.2

A sound effect (other than a bleep) can then be "stopped" or
"started". Only one sound effect is playing at any given time, and
starting a new sound effect automatically stops any current one.

9.4.3

In Versions 5 and later, a sound effect may repeat any specified
number of times, or repeat forever (until stopped).

9.4.4

Eventually, though, if it has not been stopped, it may end by itself.
A routine (specified at start time) can then be called. The intention is that
this routine may implement effects such as fading in and out, by replaying
the sound effect at a different volume. (A game should not place any important
code in such a routine.) The routine is only called when the sound has played the requested
number of times. If manually stopped or interrupted by another sound, the
routine is not called.

9.4.5

The game may, but need not, explicitly "finish with"
any sound effect which is not likely to occur again for a while:
the interpreter can then throw it out of memory.

Remarks

The safest way an Inform program can try to produce a bleep is by
executing @sound_effect 1. Some ports of Zip believe that the
first operand of this is the number of bleeps to make (so that
@sound_effect 2 bleeps twice), but this is incorrect.

Several Infocom games bleep (using sound_effect with only one
operand, always equal to 1 or 2). Two provided sampled sound effects
but did not bleep: 'The Lurking Horror' and 'Sherlock'.
Their story files contain the following usages of sound_effect:

except that, probably due to a bug in its own code, 'TLH' can also
generate

sound_effect 4 8
sound_effect 4095 2 15

A further difficulty with 'TLH' is that it assumes the interpreter is
as slow as Infocom's Amiga interpreter was: it fires off several sound
effects in one game round, assuming there will be time for it to play
most of each one. To simulate this, sound_effect must be rewritten
to pause sometimes:

if a new sound effect is begun while there is still one
playing which was started since the last keyboard input,
then wait until that earlier one finishes one cycle before
replacing it with the new sound effect.

Infocom's MS-DOS interpreters for V4 to V6 set bit 5 of 'Flags 1' in
all circumstances (i.e., whether or not sound effects are available).
This would be incorrect behaviour for a standard interpreter.

Infocom implemented sound effects differently on different machines.
The format of Infocom's shipped sound effects files has been
documented by Stefan Jokisch and his notes are available from
www.ifarchive.org.

However, modern interpreters are strong encouraged to support Andrew Plotkin's
Blorb format, which is a more modern way to make sound effects
available to newer games. Blorb files have been made available for the Infocom
sound effects, so that modern interpreters need no longer support the Infocom format.

The Blorb specification contains some revisions to sound features, which are not
formally part of this Standard. Future versions of the Standard will likely
incorporate these revisions. In the meantime, Standard 1.0 compliant interpreters
which support Blorb should follow those revisions, rather than the precise letter
of this Standard. We apologise for the ugliness.

When using Blorb resources, the default interpreter behaviour (unless over-
ridden by the player) should be for samples played at maximum volume (64), in
one channel of a SONG or MOD played at volume 8, to be of equal volume to
samples played at maximum volume (8) as an effect. This will be the natural
behaviour if effects use one physical channel and MODs/SONGs use four
physical channels.

Ideally, a sound played at volume n in a SONG played at volume m should
sound the same as when played as an effect at volume n*m/64. This mandates
that the volume scale for effects be equivalent to the scale defined for
samples in the MOD specification.

If multi-channel effects are used, the overall volume should be independent
of the number of channels used in the sound. Thus a stereo AIFF containing
the same samples for left and right should sound as loud as a mono AIFF
containing the same data. This will need adjustment of volume if stereo AIFFs
use two physical channels and mono AIFFs use one. No adjustment would be
required if an interpreter reduced all AIFFs to mono.