Music and sound in AGS

[GarageGothic]

Now that the sound system is being revised so thoroughly, would there be any chance of adding stereo panning for channels? I've always thought it was a bit weird that the PlayAmbientSound coordinates only affected volume (not to mention that it's relative to the character rather than the viewport).
It would be quite cool if you could set a panning percentage (-100 to 100 with 0 being even distribution between left and right) from repeatedly_execute so that sound sources at the off-screen left end of a scrolling room would only play in the left speaker and gradually center as the viewport scrolled towards the sound source. This would also work great with characters/vehicles moving across the screen or simply to distinguish the positioning of two characters speaking.

[arrr]

How about an equalizer? I think that people would find that useful.

[HammerBlade]

Now that the sound system is being revised so thoroughly, would there be any chance of adding stereo panning for channels?

If you can edit your own sounds outside of AGS you could acheive this effect manually (e.g., Audacity, Kristal, etc.), although that would mean adding multiple versions of the same sound, which might be tedious depending on your purposes.

[alex]

Stereo panning shouldn't be hard to add.  I have programmed a few synthesizers and generally I include a panning, volume and stereo separation knob.

Linear panning is simple.  Use a float value between 0 (left) and 2 (right), with 1 equal to the center point.  When the sound is fully left, the resulting left channel is Left + Right.  The resulting right channel is 0.  Vice versa for the right channel.

With linear panning as the sound moves from side to center it seems to move closer then further away again, peaking in volume/percieved closeness at about 45 degrees.

Circular panning gives a more realistic impression of a sound source moving around your head.  Rather than a linear relationship between pan position and volume / mix of left and right channels, the relationship is nonlinear.  You can use any parametric function to define the relationship but generally an inverse square law ensures the power of the sound remains at the same percieved level as a sound pans from left to right.

Various stereo seperation techniques can be used to give a wider perception of the soundfield than your speakers or headphones can really produce, thanks to some interesting psychoacoustic effects.  A basic technique is to sightly delay the left or right channel by a few milliseconds.  By adjusting the delay you can give an interesting panning effect without changing the power of either channel.

You can make a stereo field greater than 100% panning.  If you invert the left channel and mix it in with the right channel and vice versa, you begin widening the percieved stereo field.  The more inverted signal you mix in, the greater the percieved surround effect.  Combine this with channel delay and circular panning, and you have 3 basic tools for creating more immersive sounds.

Then we could always add HRTF's...

[Pumaman]

Just bringing this thread back from the dead for a quick question...

At the moment when you set the volume in AGS you have to pass in a number from 0-255, where 0 is the quietest and 255 is the loudest.

In the new system would people prefer it to use a 0-100 base to make it more intuitive, or would you prefer to stick with the more fine-grained control that a 0-255 range allows?

[Ryan Timothy B]

I'd prefer 0-100 for the percentage look and understanding.
I can't see 0-255 being a very noticeable difference compared to 0-100.

[GarageGothic]

Definitely keep it 0-255, changing to 0-100 would be purely cosmetic and allow for less flexibility. If the 8-bit range bothers anyone it should be super easy to whip up a conversion module with percentile based functions.

[TheMagician]

I'd also prefer 0-100. Can you really hear a difference between a fade from 0 to 100 and from 0 to 255?

[GarageGothic]

I have no idea whether the difference between 1/255 and 1/100 (or rather, 3/255) is audible, but I think it's slightly silly losing "resolution" just because it's easier to imagine sound volume going from 0-100. I mean, does anybody find it problematic to use an 8-bit scale for RGB values?

[Sslaxx]

I noticed someone talking about per-track looping options, but could we please have this extended to (at least) per-room as well, if you do decide to implement something along these lines?

[monkey0506]

It wouldn't be too horribly difficult to just do:

Code: ags

int base10to8(int base10) {
  return FloatToInt((IntToFloat(base10) / 100.0) * 255.0, eRoundNearest);
}

int base8to10(int base8) {
  return FloatToInt((IntToFloat(base8) / 255.0) * 100.0, eRoundNearest);
}

I agree that 0-100% music volume does make more logical sense than 0-255, but I also understand that changing it does decrease the precision available. Arguably there may not even be an audible difference, but I still think leaving it as-is would probably be for the best.

[fovmester]

I agree!

Keep 8-bit sound volume.

[subspark]

Chris would be at all possible to allow the user to input the BPM of a music track in the editor pane? That way we could make use of this value in the script editor to allow for iMuse functionality with digital sound files.

I also would like to request subfolders. Ideally the ROOT folder should be Audio. In that there should be, Speech, Sound, Music.
I don't see any sense whatsoever in having the speech folder outside of the root audio folder.

I agree with option #1 too btw. A sound-based audio system makes the most sense to me. It covers everything we need including cosmetics and its very clear what it is at first glance.

Cheers,
Sparky.

[Shane 'ProgZmax' Stevens]

0-100 is the more commonly used and logical method for audio volume so I am behind this change.  8-bit precision simply isn't needed for volume control and is proven to us every day on virtually everything that has a volume knob.

[LimpingFish]

Indeed, 0-100 would make more sense.

[densming]

Just a couple of thoughts:

If each piece of audio were an object/class, it might be possible to have each Audio contain two methods: SetVolume() and SetVolumePercent().  SetVolume could use the 0-255 range and the SetVolumePercent could use 0-100.

If that's too confusing for new people, then maybe have just a single SetVolume method, declared like: SetVolume(int Level, optional LevelType), where LevelType is an enum of ePercentage (0-100) or eEightBit (0-255).  Personally, I think the default should be percentage-based since this seems the most intuitive.

[subspark]

I agree on the 0-100 method. Name one practical advantage 8bit volume has over the percentage method!

Cheers,
Sparky.

[Gilbert]

Sorry for bumping this, but I just noticed this.
After adopting the OO approach, are the numbering of the audio clips lost? It seems that we can no longer do this anymore.
This is very annoying, as we still have numbering for GUIs, characters and sprites, etc.
Numbering are very useful in cases such as(just a random example):

Code: AGS

sound[20+Random(39)].Play(); //plays a random clip from #20 to #59

I know that a workaround is to use speech voices instead, but a workaround is a workaround and this isn't a good one either.

If there is no other solution I may add a suggestion to the development section.

[Crimson Wizard]

I am usually against using numbers when accessing items, since, in my opinion, game logic should not rely on how items are stored.
Only case I knew it could be useful is iterating through all array, but that could be replaced by the use some sort of enumerator/iterator object.
Here you gave another interesting example:

Code: AGS

sound[20+Random(39)].Play(); //plays a random clip from #20 to #59

May I suggest feeding a separate array with clips you want to use at random? Like this:

Code: ags

AudioClip *randomclips[40];

function game_start()
{
   randomclips[0] = aSound1;
   randomclips[1] = aSound2;
   ...
}

function play_random_clip()
{
   randomclips[Random(39)].Play();
}

As for further development, a possible approach could be to define Item Groups concept, and allow to play randomly selected item from the group, like

Code: ags

MyAudioGroup1.GetRandom().Play()

Or something like that.

[Gilbert]

Code: ags

   randomclips[0] = aSound1;
   randomclips[1] = aSound2;
   ...

IMO this is retarded. If one can manage it tidily, using numbers is much more elegant than referring everything via an object. It is fine to give people a choice to make their codes more descriptive(and more bloated) but giving up a good feature just to please the OO people is not a good move and more stupidly, the engine is already referencing the sound clips by numbers internally, just not directly accessible.