HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

SoundUtils

08-30-2009, 04:04 PM#1
Rising_Dusk
SoundUtils Library

Background:
This library's development spawned out of my need in a map to handle sounds easily. Sounds suck, through and through, and anyone that has attempted to work with them in the past will agree with me there. Just go do a search for threads relating to "Why doesn't my sound run?" This library removes a lot of the guesswork associated with handling sounds and simplifies their usage and troubleshooting tremendously.

Requirements:Code:
Expand Library:

Function List:
This library provides the following functions to the user.
  • function DefineSound takes string fileName, integer duration, boolean looping, boolean is3D returns integer
  • function DefineSoundEx takes string fileName, integer duration, boolean looping, boolean is3D, boolean stopwhenoutofrange, integer fadeInRate, integer fadeOutRate, string eaxSetting returns integer
  • function RunSound takes integer soundRef returns sound
  • function RunSoundOnUnit takes integer soundRef, unit whichUnit returns sound
  • function RunSoundAtPoint takes integer soundRef, real x, real y, real z returns sound
  • function RunSoundForPlayer takes integer soundRef, player p returns sound
  • function ReleaseSound takes sound s returns boolean
I remember first making this library, I had absolutely no idea how sounds work, and I wanted to make sure that no one else ever had this problem again. That was 8 hours of work that every mapmaker should be able to avoid with this library and (at most) a post in this topic.

I trust this will be useful to more than just myself!
Attached Images
File type: gifclear.gif (43 bytes)
08-30-2009, 04:08 PM#2
darkwulfv
I've never found sounds all that hard to work with, honestly. You declare a sound variable in the Sound Editor and then use it later and destroy it when done. I don't see where the guesswork or problems come in. I've also never experienced the "first time doesn't play" bug either... Perhaps it's just me?
08-30-2009, 04:39 PM#3
Rising_Dusk
Quote:
Originally Posted by darkwulfv
You declare a sound variable in the Sound Editor and then use it later and destroy it when done.
Ever try playing that sound twice within its own duration? You'll find that it doesn't work. That is the biggest limitation of the Sound Editor sounds and the main reason people look for better ways in the first place. Of course, I did explain that in this library's documentation... :)
08-30-2009, 04:44 PM#4
uberfoop
Quote:
Originally Posted by darkwulfv
I've never found sounds all that hard to work with, honestly. You declare a sound variable in the Sound Editor and then use it later and destroy it when done. I don't see where the guesswork or problems come in.
The main point of this is avoiding the doesn't-play-when-two-instances-are-attempted issue.



I think it's pretty neat.
08-30-2009, 04:46 PM#5
darkwulfv
Whenever I used sounds it was always a one-time deal (or the sound was repeated, but not at the same time).

After reading said documentation, I see this limitation now. I've just never experienced it.
08-30-2009, 07:26 PM#6
Na_Dann_Ma_GoGo
I found myself in really heavy trouble regarding sounds, I may check this out.
08-30-2009, 08:29 PM#7
Karawasa
I don't use sounds anymore but I remember back in Tropical Tag they were a huge pain in the ass. Thus, this seems like a useful library.
08-30-2009, 11:11 PM#8
Anitarf
Are there any reasons to use ExecuteFunc in lieu of .execute?

Also, is there any advantage to recycling sounds other than the small performance boost of not creating and destroying handles?
08-30-2009, 11:39 PM#9
Rising_Dusk
Quote:
Originally Posted by Anitarf
Are there any reasons to use ExecuteFunc in lieu of .execute?
Force of habit. If it's a problem, I can change it. They're the same, though, as far as I am aware.
Quote:
Originally Posted by Anitarf
Also, is there any advantage to recycling sounds other than the small performance boost of not creating and destroying handles?
You need multiple sounds to play multiple at a time and they're easy to recycle (and saves you from having to change their settings many times, since they remember their settings), so I figured might as well. You could consistently create new sounds if you wanted, but I figure that if you can recycle them easily, why not?
08-30-2009, 11:59 PM#10
Anitarf
Quote:
Originally Posted by Rising_Dusk
Force of habit. If it's a problem, I can change it. They're the same, though, as far as I am aware.
.execute is supposedly faster.

Quote:
You need multiple sounds to play multiple at a time and they're easy to recycle (and saves you from having to change their settings many times, since they remember their settings), so I figured might as well. You could consistently create new sounds if you wanted, but I figure that if you can recycle them easily, why not?
If you don't know which sound particular is getting recycled, remembering their settings can be a problem. If you always play sounds at their default volume except in rare cases when you modify the volume, then once one of those rare cases gets recycled for a normal case, it's volume would no longer be at the expected default value.

Recycling can be a bigger performance hit than creating/destroying, in your case you need to maintain a stack for each sound type, plus the extra timerutils operations for the RecycleSoundWhenDone feature. Also to consider is the fact that other recycling systems like Timer/GroupUtils exist primarily because of bugs associated with destroying those handles, performance is a secondary concern.
08-31-2009, 12:46 AM#11
Bobo_The_Kodo
.execute uses TriggerExecute rather than ExecuteFunc, and TriggerExecute is faster
08-31-2009, 01:05 AM#12
Rising_Dusk
Quote:
Originally Posted by Anitarf
If you don't know which sound particular is getting recycled, remembering their settings can be a problem. If you always play sounds at their default volume except in rare cases when you modify the volume, then once one of those rare cases gets recycled for a normal case, it's volume would no longer be at the expected default value.
You could always just do call SetSoundVolume(MySound, 127) if you're doing something weird like that.
Quote:
Originally Posted by Anitarf
Recycling can be a bigger performance hit than creating/destroying, in your case you need to maintain a stack for each sound type, plus the extra timerutils operations for the RecycleSoundWhenDone feature. Also to consider is the fact that other recycling systems like Timer/GroupUtils exist primarily because of bugs associated with destroying those handles, performance is a secondary concern.
I can't really argue with this. I guess it's just a matter of preference. I prefer to keep my handle count low, and since I will never use more than 5 or so sounds at once, performance is a non-issue. The contrast here is that you'd need to run 9 additional natives for each sound you create as opposed to those you recycle. Does that rival the array handling of the stack? Heck if I know, but what I do know is that either way the difference is going to be negligible in all applicable cases.
08-31-2009, 05:17 AM#13
Bobo_The_Kodo
RecycleSoundWhenDone_Child doesn't recycle the timer >.<
08-31-2009, 05:56 AM#14
Rising_Dusk
Lol, I win.
08-31-2009, 11:30 AM#15
Anachron
You should add an option what player to play the sound to, else this is pretty damn a waste of space in most maps.