Difference between revisions of "Sounds"
m (Sound file length was extended.) |
m (Added link to full SL sound specs and minor formatting/spelling/links) |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
{{OSWikiFeatureNav}} | {{OSWikiFeatureNav}} | ||
=== Feature Design Document === | === Feature Design Document === | ||
The Sounds folder contains audio clips. | The Sounds folder contains audio clips. | ||
=== Functional Spec === | === Functional Spec === | ||
Sounds must be in .WAV file in standard PCM format, 16-bit/44.1kHz/mono or stereo (converted to mono), and less than thirty seconds in length. Thus, 29.99 seconds is fine, but 30.0 will fail to upload. | Sounds must be in <code>.WAV</code> file in standard {{Wikipedia|Pulse-code modulation|PCM format}}, (unsigned) 16-bit/44.1kHz/mono or stereo (converted to mono), and less than thirty seconds in length. Thus, 29.99 seconds is fine, but 30.0 will fail to upload. Specifically, if you do want to be able to upload 30 seconds exactly then your <code>.WAV</code> sample needs to be exactly 1,323,000 samples (30 * 44,100) and not a single sample more. | ||
(source: LL Knowledge base.) | (source: LL Knowledge base.) | ||
Full specs can be found on [[Sound Clips|this article about sound clips]]. | |||
=== Test scripts === | === Test scripts === | ||
Line 11: | Line 13: | ||
=== Discussion for future improvements === | === Discussion for future improvements === | ||
Sound Synthesis | ====Sound Synthesis==== | ||
[pardon the ramble... if it is inappropriate here please contact me] | [pardon the ramble... if it is inappropriate here please contact me] | ||
IMHO a much ignored aspect of game sound design is Sound Synthesis. Presently the pervasive model is 'event driven file playback' which, although often workable (e.g. gunshots, explosions, physical interactions), also limits the sound designer's ability to craft more dynamic, deeply interactive sonic events. | {{HoverText|IMHO|In My Humble Opinion}}, a much ignored aspect of game sound design is Sound Synthesis. Presently the pervasive model is 'event driven file playback' which, although often workable (e.g. gunshots, explosions, physical interactions), also limits the sound designer's ability to craft more dynamic, deeply interactive sonic events. | ||
A simple example of this would be: | A simple example of this would be: | ||
Imagine a 'machine', emitting a low rumble, with a switch on the side which when touched, changed the sound (say to a higher pitch). | Imagine a 'machine', emitting a low rumble, with a switch on the side which, when touched, changed the sound (say to a higher pitch). | ||
In contrast, imagine the same machine with a lever on it, which allowed the user to arbitrarily change the sound (again say pitch) as they interacted with it. | In contrast, imagine the same machine with a lever on it, which allowed the user to arbitrarily change the sound (again say pitch) as they interacted with it. | ||
Whereas the former can be created with well crafted looping file playback and an interactive trigger to another looping file.... | Whereas the former can be created with well crafted looping file playback and an interactive trigger to another looping file.... | ||
the latter (arbitrary interaction on the | the latter (arbitrary interaction on the user's part) would be almost impossible to create using only 'file playback'. | ||
Instead, this type of dynamic interaction can only be created using standard sound design synthesis tools (oscillators, filters, etc.). | Instead, this type of dynamic interaction can only be created using standard sound design synthesis tools (oscillators, filters, etc.). | ||
And a quick look at the API of sound engine for SL (FMOD) reveals that it is fully capable of this. | And a quick look at the API of sound engine for SL ([https://www.fmod.com/ FMOD]) reveals that it is fully capable of this. | ||
So it is my suggestion that these features be revealed to the designer. | So it is my suggestion that these features be revealed to the designer. | ||
Whether this is functionally possible, I do not know... but if so: It would allow sound designers to craft much more dynamic and interactive sonic content. | |||
- Robb | - Robb | ||
Latest revision as of 03:31, 4 January 2025
Feature Design Document
The Sounds folder contains audio clips.
Functional Spec
Sounds must be in .WAV
file in standard PCM format, (unsigned) 16-bit/44.1kHz/mono or stereo (converted to mono), and less than thirty seconds in length. Thus, 29.99 seconds is fine, but 30.0 will fail to upload. Specifically, if you do want to be able to upload 30 seconds exactly then your .WAV
sample needs to be exactly 1,323,000 samples (30 * 44,100) and not a single sample more.
(source: LL Knowledge base.)
Full specs can be found on this article about sound clips.
Test scripts
Discussion for future improvements
Sound Synthesis
[pardon the ramble... if it is inappropriate here please contact me]
IMHO, a much ignored aspect of game sound design is Sound Synthesis. Presently the pervasive model is 'event driven file playback' which, although often workable (e.g. gunshots, explosions, physical interactions), also limits the sound designer's ability to craft more dynamic, deeply interactive sonic events. A simple example of this would be: Imagine a 'machine', emitting a low rumble, with a switch on the side which, when touched, changed the sound (say to a higher pitch). In contrast, imagine the same machine with a lever on it, which allowed the user to arbitrarily change the sound (again say pitch) as they interacted with it.
Whereas the former can be created with well crafted looping file playback and an interactive trigger to another looping file.... the latter (arbitrary interaction on the user's part) would be almost impossible to create using only 'file playback'. Instead, this type of dynamic interaction can only be created using standard sound design synthesis tools (oscillators, filters, etc.). And a quick look at the API of sound engine for SL (FMOD) reveals that it is fully capable of this.
So it is my suggestion that these features be revealed to the designer.
Whether this is functionally possible, I do not know... but if so: It would allow sound designers to craft much more dynamic and interactive sonic content. - Robb
Relationship to other features
List of features that need to be tested when this feature changes, and why.
(none)
User Guides
(none)