[z64555]

I actually want to get started on this, but it's probably likely that another coder is interested and/or people have comments. 



This feature surfaced after this other request was made. Short story is that Spoon chimed in about how it would be nice to assign multiple launch sounds per weapon, and I mentioned that another mod project I had worked on (DF:BHD if your wondering) had something called Sound Sets.

•     Any sound sound set can have its pitch and/or volume randomized by some defined amount.
•     Sounds can be grouped into sound sets. When the sound set is called, one of the sounds in the set is played.
•     Sound sets can either sequentially cycle (forward or backward) between the included sounds, or randomly pick a sound whenever the sound set is played.

The above strike-through edit is due to the fact that:

•     I forgot that the DF:BHD engine only did this in soundsets, and not per individual sound and
•     It's probably a better idea to do pitch and/or volume randomization only within the sound sets, anyway.

Possible table format for soundsets:

Code: [Select]

#Sound Sets

$Set: 0               ;; The ID number for this set
    +Cycle: random    ;; Will cycle randomly. Defaults to forward cycling (top of the list down)
$Sound: 10                     ;; The ID number of the first sound
    +Randomize Pitch: 0.3      ;; Pitch Randomization percentage ( between +/- 30%)
    +Randomize Volume: +0.1    ;; Volume Randomization percentage ( up to +10%)
$Sound: 11                     ;; Second Sound ID
$Sound: 12                     ;; Last sound in this set

$Set: 1
$Sound: 13

#End

The + and - there is an additional feature, which would essentially allow the tabler some flexibility for the randomization. The value is a % of the volume or pitch (might actually be the .wav's total playtime), and has to be a float value to allow for fine adjustments (especially for randomizing the pitch). [See below]

Next problem for the .tbl's would be to figure out how to differentiate between individual sounds and sound sets with the existing system. Ideally, the implementation would be backwards compatible... so if you don't specify to use a sound set somewhere, the sound ID will be used.

A better method to define the range the volume, pitch should randomize in would be like so:

Code: [Select]

    +Randomize Pitch: 10.0, 10.0        ;;First value is positive (higher pitched), second value is negative (lower pitched)
                                        ;;  ex. values of 10.0, 10.0 would result in a pitch range of +10.0% to -10.0% of the sound's original pitch
As for the differentiation between sounds and sound sets, we could overloard the existing sound function(s) with an optional flag:

Code: [Select]

sound_function( ... , bool Is_a_sound_set = FALSE )
(No, that's not the actual sound function. )

Lastly... Sound set's might also include sub-groups to be used in particular environments. Although I personally think it would be better to come up with a way to apply distortions to the sounds/sound sets depending on the environment the player is in (read: atmospheric vs. space), for now, it may be good to make an $Environment Group: option.

Code: [Select]

#Sound Sets

$Set: 0               ;; The ID number for this set
    +Cycle: random    ;; Will cycle randomly. Defaults to forward cycling (top of the list down)
$Environment: 0       ;; Environment sub group. Defaults to 0 if not specified
  $Sound: 10                     ;; The ID number of the first sound
      +Randomize Pitch: 0.3      ;; Pitch Randomization percentage ( between +/- 30%)
      +Randomize Volume: +0.1    ;; Volume Randomization percentage ( up to +10%)

$Environment: 1
  $Sound: 11
  $Sound: 12
#End

[Iss Mneur]

Interesting.

This is a large undertaking.  The FSO sound code is only ready for this in spirit.  The largest problem for implementing this would be extending the sound information enough to carry the metadata required to do this and to correctly reset channels after having used these more advanced OpenAL features.

The functions in question would be ds3d_play and ds_play, but the problem for you in implementing this feature would be that both functions are actually too low level for what you are wanting to do, so you would have to implement a shimlayer that would allow these soundsets to be implemented using ds3d_play and ds_play.

As far as implementing the interface to this feature, please, please don't use another set of numbers that are interchangeable but orthogonal to the stuff that is in sound.tbl.  Instead use names (probably force them to start with sset_ or something similar (remember identifiers in FSO need to be less than 32 chars)) and modify/extend parse_sound (which is used by the weapons.tbl parser to do a couple of neat tricks with sound filenames already).  This will allow a tabler to use a soundset just like they could a filename.  Also, remember this is going to basically require that you do this for everything or nothing because otherwise SCP is going to be forever adding support for this feature one location at a time.

As for the proposed table format.  I already went over the use of numbers, but I feel so strongly about it I am going to repeat it, just don't number these as well.  Also, make sure that this table can be used as a modular table because otherwise this feature is going to be a mod data bug farm.  I would also suggest allowing the sets to include sounds based on its filename like weapons.tbl does already.  Is the randomize pitch and volume per sound or per soundset?

A better method to define the range the volume, pitch should randomize in would be like so:

Code: [Select]

    +Randomize Pitch: 10.0, 10.0        ;;First value is positive (higher pitched), second value is negative (lower pitched)
                                        ;;  ex. values of 10.0, 10.0 would result in a pitch range of +10.0% to -10.0% of the sound's original pitch

This is a bad idea.  Just make it +Randomize Pitch: and two numbers between -100 and 100 (or whatever range makes sense). That is, require the tabler to specify a negative number to get a negative pitch shift.  This way a tabler (and I know one will ask) can use a +10% to +20% random shift.  Also, drop the comma in the data and just make it whitespace because the comma just complicates the parsing of the data and is different than how the rest of the .tbls are parsed.

As for the differentiation between sounds and sound sets, we could overloard the existing sound function(s) with an optional flag:

Code: [Select]

sound_function( ... , bool Is_a_sound_set = FALSE )
(No, that's not the actual sound function. )

Not a real fan of this, because the current sound functions already have several default variables, I would prefer if all sounds were assumed to be in a soundset of 1 with the default (read no) variations and they are assigned a name of their specific number.

Lastly... Sound set's might also include sub-groups to be used in particular environments. Although I personally think it would be better to come up with a way to apply distortions to the sounds/sound sets depending on the environment the player is in (read: atmospheric vs. space), for now, it may be good to make an $Environment Group: option.

Code: [Select]

#Sound Sets

$Set: 0               ;; The ID number for this set
    +Cycle: random    ;; Will cycle randomly. Defaults to forward cycling (top of the list down)
$Environment: 0       ;; Environment sub group. Defaults to 0 if not specified
  $Sound: 10                     ;; The ID number of the first sound
      +Randomize Pitch: 0.3      ;; Pitch Randomization percentage ( between +/- 30%)
      +Randomize Volume: +0.1    ;; Volume Randomization percentage ( up to +10%)

$Environment: 1
  $Sound: 11
  $Sound: 12
#End

Again. Use names for the Environments and default to the first one listed and let the FREDer pick the environment with a sexp, that way they can do whatever funky thing they want.

Anyway, this is my 30 minute shoot from the hip response to this, hopefully it is useful to you.

[m!m]

I actually experimented with this at the time it was posted first and I already have an addition to the sound code which adds classes that are capable of holding informations like this. I also have another addition to the sound parsing code which adds modular table support for the sound table which should work nicely.

Now the more important part is, like Iss Mneur pointed out, that the sound play functions (snd_play and friends) need to be able to use this information. I'd be in favor of having a generic SoundInformation class which could be passed to the sound play functions which encapsulates a game_snd or a sound set (meaning that we have a game_snd class and a SoundSet class which extends the SoundInformation class).
Now the other problem is that currently a reference to a sound is saved as an int which is an index into the Sounds vector which is obviously not suited to be used in conjunction with the proposed sound sets. A solution would be to change the indexing values to be of a special type which could hold the information needed to reference either a plain sound or a sound set.

Also I'm attaching a patch containing the modular sound table parsing changes in case somebody would like to take a look at it as that would make it much easier to implement this feature if the sound table is already modular.

[attachment deleted by a ninja]

[zookeeper]

One thing that might be desirable (either as an option or not) would be making a sound list never play the same sound twice in a row. Meaning that whenever triggering a sound list sound, the game would check which one was picked from the list the last time, and pick any other sound than that.

[z64555]

One thing that might be desirable (either as an option or not) would be making a sound list never play the same sound twice in a row. Meaning that whenever triggering a sound list sound, the game would check which one was picked from the list the last time, and pick any other sound than that.

That's item #3 in the first quoted list. 

[mjn.mixael]

Also I'm attaching a patch containing the modular sound table parsing changes in case somebody would like to take a look at it as that would make it much easier to implement this feature if the sound table is already modular.

Any chance you can share with us how it works? (As in sounds-XXX.tbm, what the syntax is, etc.)

[redsniper]

Code: [Select]

+Randomize Pitch: 0.3      ;; Pitch Randomization percentage ( between +/- 30%)
+Randomize Volume: +0.1    ;; Volume Randomization percentage ( up to +10%)
Why cap it? Or at least... why at 30%? I figure as long as it doesn't break the game, might as well give modders as big a range to play with as possible.

[Spoon]

I can't really offer anything but my support for this from the sidelines

[m!m]

Any chance you can share with us how it works? (As in sounds-XXX.tbm, what the syntax is, etc.)

The table uses -snd.tbm as modular table prefix and the syntax stays the same for new entries. If you want to modify an existing entry then you use +nocreate to tell the parser that it should not create a new entry.
So if you want to change the retail tracking sound which was defined like this:

Code: [Select]

$Name: 0 trk-loop.wav, 0, 0.40, 0with the sound in my_cool_sound.wav you would need the following entry:

Code: [Select]

$Name: +nocreate 0 my_cool_sound.wav, 0, 0.40, 0

[mjn.mixael]

What happens if you specify a sound index in a modular table that is taken in sounds.tbl.. or if you specify an index that is not next on the list? (Sounds.tbl ends at 195, and you specify 203)

More specifically, how can one append new sounds to the list of interface sounds. for example?

[m!m]

The index isn't really an index into the storage vector but rather just a unique number so every new entry just gets appended to the vector. If you specify an ID which is already taken and you're not using +nocreate then a warning will be displayed saying that the specified ID already exists.
Adding interface sounds isn't treated specially so it should work as usual.

[mjn.mixael]

This is win and has been needed for a LOOOOOONG time. I shall test.

Although.. would it be possible to get a flag like +nocreate, but that instead just appends the new sound after the ID of the latest in the section?

My specific usage is with the mainhall packs I've been working on. With that capability, anyone can drag-n-drop one of the Mainhall VPs and the sounds won't cause errors like that because they are appended to the end of the list. This is helpful because the mainhall.tbl (as well as some other tables, iirc) can reference sounds by sound file instead of ID number, so ID number doesn't matter.

Of course, then you have to worry about what to do with multiple .tbms... which you could just append in the order they are loaded or something?

I dunno.. just thoughts.

[m!m]

It is possible to search for the next free ID after the specified ID but that would be a bit harder to implement with no big improvement as you could just pick a number at random and hope that it isn't taken yet.

[mjn.mixael]

Well is the Wiki still current in saying "Note: These MUST be sequential, no gaps are permitted. Also note that some indices are reserved for hardcoded effects, see here for a full list. You can use empty entries as padding to fill out any gaps."?

[m!m]

Well, there's nothing code wise that would need that AFAICS so I guess that that information is just outdated.

[Iss Mneur]

@m!m: Why are you passing the "sounds" vector by value to gamesnd_lookup_signature?  Also there is a typo in the comment on line 93 of the patch.

Well is the Wiki still current in saying "Note: These MUST be sequential, no gaps are permitted. Also note that some indices are reserved for hardcoded effects, see here for a full list. You can use empty entries as padding to fill out any gaps."?

That warning is still valid.  Nothing that I see in m!m's patch changes that warning.

The requirement is a result of most sounds indexing directly into the Snds vector and the Snds_iface vector, which means that the vector has to be contiguous and in the same order as retail.

IIRC, only parts weapons.tbl and mainhall.tbl really uses the lookup code (any place in the parser that is serviced by parse_sound basically).  This is something I never got back to fixing after Vectoring sounds.tbl.

[mjn.mixael]

So, it would definitely be helpful for an +Append option. That would allow us to much more dynamically include special sounds with weapons and ships. (According to the Wiki, certain flags in ships.tbl accept the string filename or ID.)

[m!m]

@m!m: Why are you passing the "sounds" vector by value to gamesnd_lookup_signature?  Also there is a typo in the comment on line 93 of the patch.

I don't know why I'm doing it by value I'll fix that later...

That warning is still valid.  Nothing that I see in m!m's patch changes that warning.

The requirement is a result of most sounds indexing directly into the Snds vector and the Snds_iface vector, which means that the vector has to be contiguous and in the same order as retail.

IIRC, only parts weapons.tbl and mainhall.tbl really uses the lookup code (any place in the parser that is serviced by parse_sound basically).  This is something I never got back to fixing after Vectoring sounds.tbl.

I'm not sure but the signature of the game_snd structure is never used as an index into the Snds (or Snds_iface) vector, every sound reference in the code is (or should be) parsed by parse_sound which results in actual indexes but every new game_snd instance is just added to the vector if I'm not missing something here.

[Iss Mneur]

True. Any place that you can use a string filename then its a pretty good bet that it does use the lookup functions and as such is not affected by moving of things in the sound table.

I think the better solution would be to allow the .tbl or .tbm to have a -1 as the id and have the parser just defer assigning them the actual id number until after all sounds have been parsed.  It could then go through the deferred list and append them all to the end of the sound.tbl this way no problems with accidentally stomping on someone else.  Remember tbms do not guarantee ordering.

An alternative, that would be more work, but less trouble all around, would be to take a page out of ships.tbl and weapons.tbl and just don't use numbers at all and refer to sounds by filename or allow a soundname to be specified in the sounds.tbl/.tbm.  This way the numbers are completely hidden from the tabler and much less likely to cause problems with .tbms.  The existing sound indexes would be assumed to be named their number just like CommanderDJ did with the mainhalls.

I'm not sure but the signature of the game_snd structure is never used as an index into the Snds (or Snds_iface) vector, every sound reference in the code is (or should be) parsed by parse_sound which results in actual indexes but every new game_snd instance is just added to the vector if I'm not missing something here.

Yes, I quite sure you are missing something.

Most of the sounds in the engine do are not parsed by parse_sound (or are not parsed all, in the case of most sounds).  This means that they can only be changed by changing the entry at its index in sounds.tbl or replacing the soundfile itself.  This reality is what prompted torc to asked for the ability to do player impact sounds per weapon.

For example (because I was just looking at this code for mantis 2266) take FlakLaunch (sound.tbl id 116) (the sound of a flak gun firing), and boom_4 (sound.tbl id 117) (the sound of a flak shell exploding) are both referred to in code with a define that has the value of 116 or 117, respectively.  Most entries in the sound.tbl are this way, in particular the interface and misc sounds are all referred directly by their index in sounds.tbl.

I think the defines are in gamesnd.h.

[m!m]

I was talking about the sound definitions which were added in addition to the hard coded indexes, I'm sorry if that wasn't clear in my posts, used in the code which obviously need to stay in those places and if there are places where sounds are parsed without the parse_sound function then those need to be changed and I'll do so if you can point out where that happens.

I already thought about extending the syntax of a sound definition to have a cleaner syntax which could include a name option and using the current signature numbers as the default name will make it much easier to manage the sound entries .