Ok, so these days the sound and music system in AGS stands out as being the last main part of AGS that you can tell was written back in the dark ages and hasn't really changed much since then.
You have to access all sounds and music by numbers (though the Media Manager Plugin does help with this), setting the volume correctly is a bit of a mystical art form, and relating sound channels to the sounds playing on them is not easy.
But rather than me just diving in and changing it all, I'd like to hear from you guys who work with it on a daily basis, how you think it should work.
Please don't suggest extra file formats. AGS will continue to support OGG/MP3/WAV/MIDI/MOD/XM/etc as it does at the moment, and I'm not planning to change that.
What I do want to change is the way that the sound and music is controlled from the script. Here are a couple of ideas:
1. Channel-based audio system
You'd do commands like:
channel[1].PlaySound(sExplosion);
channel[1].Stop();
channel[1].SetVolume(60);
2. Sound-based audio system
You'd do commands like:
sExplosion.Play(optional channelID);
sExplosion.Stop();
sExplosion.SetVolume(60);
Those are just two possible options I'm considering. While they eventually lead back to the same thing, which approach is most useful depends on how you like to script and control the audio. Other suggestions on how it should work are welcome.
Should you even have to worry about channels at all? Maybe you would give each sound a priority from 1-100, and AGS would automatically cut off a lower priority sound if all the channels were full?
I only fiddle around with this sort of thing irregularly , so my opinion might not mean much, but the channel based audio system seems the best for what I like to do.
Hmm.. at the moment I don't have any real suggestions, but I really like the ability to assign a name to a number. Would be very user friendly.
I imagine you're going to be adding a sound manager, from the sounds of it anyway.
The only problem I see from having a sound manager (if it were at least similar to the sprite manager) is that once you edit or switch the sound you'll have to re-import it just to have it in the game. Could be frustrating for the programmer when the sound guy gives his updated/edited sound files. Just something I was curious about.
Unless you plan on making it so that you assign which file number the 'sExplosion' will have in the sound manager, and hitting play will just play it from the sound folder, without any importing.
Anyway, I'll definitely think about any audio ideas I may have.
Giving the sound and music files a name is not only an imrovement, it's everything I'd ask for really..
I think I's prefer the sound-based audio commands to the channel ones... but it doesn't really matter to me. I guess I just would like to have the name of the sound at the beginning of the command..
Important to me is the ability to play speech sounds from custom scripting, and not just from the Say command, as its something I come across alot when writing modules. Also, the whole task of creating a voice pack for a game is very onerous, simply in the admin of matching huge numbers of speech files to text in the game. Perhaps another option is some kind of matching system that uses MP3 tags or filenames to match against speech lines semi-automatically. Or even word-based speech files.
Quote from: SSH on Wed 11/02/2009 12:35:23
Important to me is the ability to play speech sounds from custom scripting, and not just from the Say command
Yes, I agree. This is an issue that has been bothering me when I've wanted to create my own speech scripts too.
Like matti, I prefer the sound-based system, but the only improvement I'd ask for would be to be able to name the sounds. Ryan Timothy brings up a good point, though, and while I wouldn't have much problems with it (I have never made (or edited) any sounds--probably why most of my games (all unfinished) are silent), I think that something should be done for the people who do edit their music, like assigning a script name to a file, allowing the file to be changed (as long as the name stays the same) without having to do anything in AGS to accomidate the new version.
Quote2. Sound-based audio system
You'd do commands like:
sExplosion.Play(optional channelID);
sExplosion.Stop();
sExplosion.SetVolume(60);
Maybe you would give each sound a priority from 1-100, and AGS would automatically cut off a lower priority sound if all the channels were full?
This is the system I particularly like. Accessing sound by name would definitely help. ;D
Ooh, if you're overhauling the music/sound system, I'm indifferent about how the scripting works, but I do want a few features:
1) Ability to get what sound/music is playing on each track and at what volume.
2) At least two music tracks. (allow manual crossfading)
3) Toggle looping for each individual track.
4) No more music skip or stutter when changing rooms or loading large animations/sprites
5) Working music volume controls!
a) Track volume (set from 0 to 200)
b) Room sound & room music volume modifiers (set from 0 to 200)
c) Global sound & Global music volume modifiers (set from 0 to 200)
Actual volume would be a percentage of the regular sound file volume computed by multiplying the three percentages together. If the percentages multiply to less than 100, the sound or music is quieter, if the percentages multiply to more than 100, the sound or music volume is boosted. Setting any of them to zero would result in silence for the track/room/whole game respectively.
This way, you can change individual track volume for a sound that's too loud/quiet by adjusting the track volume, you can adjust the room volume if you want one room to just be quieter, or you can adjust the global volumes (like in a settings panel) to affect the entire game.
Perhaps there should also be something similar to a PlaySoundAtVolume(int sound, int volume); (adjusted to match whatever new scripting you decide on) that would set whichever track the sound would be placed on to the specified volume, play the sound, then return the track it to it's previous volume. Also, playsound functions should return the track that the sound was placed on.
I'm glad you're getting around to this, CJ! Aside from Vince's suggestions, I'd just like to make sure there will be a way to set music volume to actual zero (so it is not audible) and to start it again. Merging SetVolume and SetMasterVolume into one coherent volume setting that covers the range from 0 to max (as I suggested elsewhere) is probably the thing I'd like to see most. I do like the idea of sound based since it will automatically assign the sound to any available channel (it's cleaner that way). Would it be possible to have the sound-based system handle positional sound (sound emitting from a specific location) like you can with ambient sound?
Just a setting in the sound playback to specify whether it's ambient or not would do the trick, I think? I'd also like to see the way ambient sounds are handled worked on, since right now it's a bit hit or miss to be honest (you can go to a consecutive room and the audio will fade, but then you jump to another room and the music/sound is loud again). I think one way to handle this would be to allow the user, at the time the sound is created, to specify a range of rooms and volume settings for the ambient sound. Or, you could add an emitter option to the room edit and allow the user to place a sound emitter in a room and specify it's values. I'm sure there are other ways, but I definitely think ambient sound playback needs some tweaking.
Great initiative, CJ. The sound system definitely could use an overhaul, especially the volume settings. A few things I would like to see:
1) Ability to play speech files without using the Say command, as mentioned by SSH.
2) An analogue to Get/SeekMP3PosMillis() that works with any kind of sound file rather than just music. Possibly something like channel[1].GetAudioPosition.
3) And in extension of this, a GetAudioLength function that can either be called on a sound file or on the channel where it's played.
Thanks for your feedback so far.
Thinking about this further, do you guys think it's necessary for AGS to make a distinction between Music, Sound and Speech? Should there just be a single thing called Audio?
Conceptually an ambient sound is identical to music -- it's just a looping piece of sound. If, as has been suggested, the speech system was changed so you did something like this:
player.Say("&EXPLAINITALL I've been meaning to explain this for ages.");
which then played EXPLAINITALL.OGG, would we still need the distinction between the three types of audio?
I think the biggest hurdle in any change is likely to be backwards compatibility with existing scripts, but that's for me to worry about I guess.
Have been frustrated at times by what seems like an artificial distinction among sounds -- has meant having to duplicate something in sound and music or hacking stuff together in Audacity if I wanted to loop or control volume better. Would love to be able to queue and layer anything via channels or otherwise.
Would like full property panes for all sounds/music/speech -- ability to put name, description, duration, source, custom property, etc. (I haven't used the addon sound module yet, so this may already be available). Also, mark a sound/music as "include in compiled file" vs
. "put in separate file".
Channel object vs. sound object -- would love both (somewhat like views and characters -- sounds have channels).
Better control of sounds etc. as events and rooms are exited and entered would be great -- especially duration/fading/adding silence.
That's all.
Quote from: Pumaman on Wed 11/02/2009 20:27:47
player.Say("&EXPLAINITALL I've been meaning to explain this for ages.");
which then played EXPLAINITALL.OGG, would we still need the distinction between the three types of audio?
I think that this way would be extremely cumbersome in a game with thousands of lines of dialogs. As long as there is still an auto numberer (with the ability to customize it to search for string arguments to other functions) this would be fine.
Also, I would definitely want anything like cCharName.Say("&EXPLAINITALL Blah blah blah."); to play charnameEXPLAINITALL.OGG. So much easier to keep track of that way.
As for music and sound. As long as you can set specific tracks to looping/non-looping then there doesn't really need to be a distinction between sound and music. Ironically, in Linus Bruckman, I did all the music as sound and all the sound as music because I needed the ability to fade the volume all the way out (can't do it properly with music) and play more than one piece of music at a time (also can't do it properly with music).
The only issue I can think of where someone might want to have them separate is for separate music/sound effect volume sliders in a settings GUI. But you could just have them control certain tracks, and make sure to only play music/sounds on the proper tracks.
I don't think there needs to be a great distinction aside from what Vince mentions with being able to control music and sound levels independently. One set of inclusive functions for doing everything you need to with audio would work fine, I think, and save you a heap of time code wise and in the future. For dialog, I agree it could work a bit better than it does now. For example, SayBackground doesn't play speech lines, which is something I've never really understood. This forces you to play the speech as a sound instead. Allowing people to use any kind of filename for dialog would work fine, I think. It would be up to the user to make sure their filenames don't have duplicates, and the engine would then be able to read in any 'new' names added without renumbering the whole thing.
Quote from: ProgZmax on Wed 11/02/2009 22:06:53
Allowing people to use any kind of filename for dialog would work fine, I think. It would be up to the user to make sure their filenames don't have duplicates, and the engine would then be able to read in any 'new' names added without renumbering the whole thing.
What about "Auto-number Speech Lines"? I'm rather fond of that feature. I prefer to write, re-write dialog endlessly until I'm happy with it and at the end, I don't want to go all the way back through it and add a filename to each one.
The problem with auto-numbering is it really doesn't work well. You can't 'really' write and re-write lines endlessly without completely renumbering all of the lines as it stands, and if you add some new ones here or there it breaks the auto-numbering completely, forcing you to number the rest of them yourself. The numbering system either needs a rework so it can intelligently detect new lines and add them or it should be left in the creator's hands by allowing them to make unique filenames. If the numbering system would continue where it left off I'd have no problem with it, but as of now it does not.
Yeah, having the option in the wizard to only number un-numbered lines would be great. I suggested this a few days ago in the 3.1.2 wishlist thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=36284.msg483658#msg483658).
hi!
We are using a Tool that i've made in AGS. In this tool we can add image files for background, and play MIDI files too, but only if they have the name "music1.mid", or "music2.mid", etc.
I think that a playmusicfile("nameoffile") , compatible with MIDI, would be a great add.
thank you!
The suggestions here have been really quite good, and mostly align with what I would like to see, but in case I have some facet left untapped:
- Perhaps some way of organising the numbered speech lines, so we have the number of the speech line and the containing text available for viewing all at once (in a kind of database), that we can attach sound files to in the editor. Example, we have dialogue as such:
&1 I am Ego, Hear me Roar.
&2 Jolly Good, I hope that turns out well for you.
&3 That doesn't work.
Now, if we had thousands of lines, we'd have to make sure we're numbering all the files right, and we would be working pretty much blind. However, if we had something as simple as a menu list/database with:
[SPEECH NUM.][TEXT][PLAY |>] [SOUND FILE NAME]
For each line of the dialogues, we'd be able to quickly assign our audio files, and be able to test it there and then. The resulting data could then be easily changed and reassigned if you need to place new voice files in, without having to blindly stumble around the dialogue.
- (I'm a little out of the loop, but...) Is it possible to adjust the individual channels of a MOD/IT/XM file to, say, reduce the volume of MOD Channel 1 to 0, leaving the other three MOD channels playing normally? This would be a great help in creating dynamic music, but not that important.
- I like the idea of sound emitter objects for ambient sounds. In this update, will ambient sounds be unrestricted in how many channels they take up? (2-4 channels for ambient sounds might be as many as anyone needs, lest it turn into a cacophony.)
- I like the channel based system. It looks more precise and controllable - that way we can control exactly which channels we want to change at any one time.
Don't have much to add, mostly cause I haven't used AGS's audio anyways, besides just reading manual entries.
However, I do think that there should just be a Audio namespace (accompanied by an Audio folder in the Game directory), rather than Music, Sound, and Speech. However, I think it would be nice to have subfolders within the Audio folder, so that you can seperate them that way for yourself (optional too).
Also, if you can implement Metadata into a Media manager, that would be the best! Even if just reading it at this point, and worry about writing metadata later.
~Trent
One more note regarding lumping music/sound/speech together: Speech should probably be kept separate so we don't lose the ability to have a separate speech.vox for optional speech or multiple language packs.
If something like this :
channel[1].PlaySpeechFile(cEgo,1);
can be placed, it would be really really cool.
Quote from: Vince Twelve on Fri 13/02/2009 21:36:41
One more note regarding lumping music/sound/speech together: Speech should probably be kept separate so we don't lose the ability to have a separate speech.vox for optional speech or multiple language packs.
If we had access to metadata tags, then you could specify which ones are speech, which are sound, and which are music. Then when you want the build the .vox file, it could search for files with those tags and only build them.
Actually, even if it's not metadata. If you could specify your own tags in AGS, it'd be good enough.
~Trent
Would it be possible to get technical information on MIDI's used in the game? I know you can seek the position of a MIDI by beat, but it would be nice to be able to use information such as tempo, current measure, etc. for other things (such as synchronizing animations to line up with background music). Think of the potential for action-rhythm games! (or at least automatic adjustment of animation speed of environmental objects based on tempo: "fast-forwarding"/"Slow-down" effects?)
A list of commands such as
channel[1].AsMidi.getBPM(Beat); //gets the beats per minute of the MIDI at beat 'Beat'.
channel[1].AsMidi.getTimeSignature(Beat); //gets the time signature (such as 4/4) of MIDI at beat
channel[1].AsMidi.getPitch(Beat); //gets the pitch of the beat
channel[1].AsMidi.getVolume(Beat); //gets the volume of the beat
channel[1].AsMidi.get...(etc.)
...Okay, so most minute properties of MIDI's aren't important enough for most games to need such intricate data on a MIDI...but the BPM at least woud be nice to have access to.
Quote
sExplosion.Play(optional channelID);
sExplosion.Stop();
sExplosion.SetVolume(60);
It would seem like this approach would offer more possibilities and would be my preference. Prersummably there would be a an Explosion.wav or Explosion.mp3 file in the a Sound directory.
Quote
Important to me is the ability to play speech sounds from custom scripting, and not just from the Say command, as its something I come across alot when writing modules. Also, the whole task of creating a voice pack for a game is very onerous, simply in the admin of matching huge numbers of speech files to text in the game. Perhaps another option is some kind of matching system that uses MP3 tags or filenames to match against speech lines semi-automatically. Or even word-based speech files.
If the above sound object approach was used then instead of tryiung to match dialog text to voice files the sound object itself could also contain the dialog text.
sExplosion.Text = "Get down there's going to be an explosion!";
Display(sExplostion.Text);
Actually MP3 tags and other sound file attributes could also be exposed in this manner as well.
Quote
However, I do think that there should just be a Audio namespace (accompanied by an Audio folder in the Game directory), rather than Music, Sound, and Speech. However, I think it would be nice to have subfolders within the Audio folder, so that you can seperate them that way for yourself (optional too).
I would agree with ther need for subfolders as well.
Quote
If something like this :
channel[1].PlaySpeechFile(cEgo,1);
can be placed, it would be really really cool.
I would prefer something like:
sSound1.Play(eChannel-1);
or
cEgo.Say(sSound1, eChannel-1);
In the latter case if the sound object contained text then the text would be displayed and the sound played.
Thanks for your feedback, guys.
I think, in conclusion, it makes sense to go with the following:
* Keep the Speech folder for speech, and keep it numbered. This allows the Auto-number Speech Lines feature to continue working, and to have a separate Speech.vox file. Add a manual PlaySpeech script command.
* Combine Music and Sound into a single Audio folder, and allow each file to be addressed by name instead of number.
A priority and loop parameter when playing the audio would allow you to treat the audio as Music, Sound or Ambient Sound, as appropriate.
* The script would have no concept of Sound Channels. Instead, AGS would use the Priority setting of each Audio clip to destroy an existing lower-priority sound if it ran out of channels.
However, the audio.Play() method would return some sort of Channel/Sample object that you would be able to use later to adjust the volume or stop the audio.
Does anyone see any problems with this approach?
QuoteCombine Music and Sound into a single Audio folder
I'd like to see what 'Trent R' suggested: the possibility for subfolders in the audio folder. At least one for music and one for sounds.
And I hope - although the concept of channels will be dropped - we will still be able to modify the volume of each playing sound separately.
With channels we were able to do: "whatever is playing on channel 3 - make it louder". This seems more difficult to keep track of with the new "priority" concept.
The approach is right for at least... My suggestion doesn't fit here but it would be nice if sound wasn't compiled in the game exe, and create a separate file such as music.vox, eg: sound.vox
Quote from: TheMagician on Thu 05/03/2009 23:13:16
QuoteCombine Music and Sound into a single Audio folder
I'd like to see what 'Trent R' suggested: the possibility for subfolders in the audio folder. At least one for music and one for sounds.
But you can prefix your filenames with something like soundBigExplosion.ogg
Like I said before, I haven't used Audio much at this point. But I think your final decisions sound good.
~Trent
I don't see any problems with the approach, but I would like you to elaborate on whether these changes will extend to reworking MasterVolume to operate across the entire spectrum (overriding room sound settings) and to addressing the ambient sound playback issue (inconsistent sound levels between room changes, etc). I understand that these aren't directly related to your changes, but if you are indeed overhauling the sound system I think it's important to fix some of the pre-existing issues with it as well?
Would you somehow be able to retrieve the sounds currently playing, or would it be necessary to keep track of this in a custom play function? One example that springs to mind is a feature in my current game where calling up the pause menu will fade out the room music and play a pause menu tune. Returning to the game will fade the pause music out and resume the previous music at the same point it faded out. With the new system it seems I would have to store the ID for the background music when it originally started rather than just before fading it out?
Quote* The script would have no concept of Sound Channels. Instead, AGS would use the Priority setting of each Audio clip to destroy an existing lower-priority sound if it ran out of channels.
However, the audio.Play() method would return some sort of Channel/Sample object that you would be able to use later to adjust the volume or stop the audio.
Then, to play a sound, we'll use audio.Play(), but to stop or adjust volume we'll use chanel[ x ].Stop.
Then... we will need a command that returns the channel where an audio file is playing,
or -1 (or 0) if the file isn't exist or is not being played.
----------
Also, it would be useful to reproduce midis from files, during the game, such as it is able to load a bmp or pcx image with DynamicSprites, now that i´m making a tool for the creatives of our group.
Garage's post made me wonder... If there's going to be a new Audio object, will we be able to have pointers to it? (In his case, storing the currently played music into a pointer, then calling it when the pause menu is removed)
~Trent
Quote from: Pumaman on Thu 05/03/2009 20:36:40
Thanks for your feedback, guys.
* Add a manual PlaySpeech script command.
Marry me!!!
*Gets the hang of it*
Thanks!!!!
QuoteI'd like to see what 'Trent R' suggested: the possibility for subfolders in the audio folder. At least one for music and one for sounds.
Sub-folders are certainly a possibility, though they could easily be added later and wouldn't be essential to the initial version.
QuoteAnd I hope - although the concept of channels will be dropped - we will still be able to modify the volume of each playing sound separately.
Yes, of course.
QuoteI don't see any problems with the approach, but I would like you to elaborate on whether these changes will extend to reworking MasterVolume to operate across the entire spectrum (overriding room sound settings) and to addressing the ambient sound playback issue (inconsistent sound levels between room changes, etc).
The problem with this is how to maintain backwards compatibility.
In an ideal world I'd rip out all the sound and audio code from AGS and start again, but I can't really make a change which would break everybodys games. Therefore, I need to do some further investigation to see how well I can fix it without breaking existing games.
QuoteWould you somehow be able to retrieve the sounds currently playing, or would it be necessary to keep track of this in a custom play function?
Good idea, something like this should really be provided.
QuoteThen, to play a sound, we'll use audio.Play(), but to stop or adjust volume we'll use chanel[ x ].Stop.
Then... we will need a command that returns the channel where an audio file is playing,
or -1 (or 0) if the file isn't exist or is not being played.
QuoteGarage's post made me wonder... If there's going to be a new Audio object, will we be able to have pointers to it?
Ok, let me provide an example to clear this up. What I'm proposing is something like this:
SIMPLE SCRIPT:
aBullet.Play(ePriorityHigh, eLoopNone);
ADVANCED SCRIPT:
SoundChannel* channel = aBullet.Play(ePriorityHigh, eLoopNone);
...
channel.SetVolume(5);
channel.Stop();
etc
Because one sound effect could be playing several times simultaneously there needs to be some sort of separate concept of a Channel in order to control the individual playing instance of the sound.
I was wondering if there will still be a limit on the number of simultaneously playing sounds? If so then perhaps there could be a sound channel array that would work similar to the way the character array works. When a sound is played it would automatically be assigned to an available channel or alternatively played on a specific channel specified by an optional parameter.
Quote
SIMPLE SCRIPT:
aBullet.Play(ePriorityHigh, eLoopNone);
ADVANCED SCRIPT:
SoundChannel* channel = aBullet.Play(ePriorityHigh, eLoopNone);
With the Advanced script like this, wouldn't it cause some problems? Also seems a little confusing for those who might not understand scripting.
The 'SoundChannel* channel' should be part of the PlaySound command (as optional).
I feel the code to play sound should be like this:
aBullet.Play(eLoopType, ePriority, Optional Channel);
To make things easier, would be to make an ePriorityNone. That way you don't have to mess with priority if don't wish to (the way PlaySound used to be). Or with ePriorityNone, it could help the advanced scripters who know what channel each sound plays on, and doesn't care about Priority.
I imagine they could always just use ePriorityLow on all sounds and they would still play over each other?
Although if aBullet.Playing would return a Boolean, you could also have more control over the sounds.
Also will there be more channels available with the new sound system?
I'll have to give it some more thought.
Quote from: RickJ on Sat 07/03/2009 04:01:59
I was wondering if there will still be a limit on the number of simultaneously playing sounds? If so then perhaps there could be a sound channel array that would work similar to the way the character array works. When a sound is played it would automatically be assigned to an available channel or alternatively played on a specific channel specified by an optional parameter.
Yes there would still be a limit, but the question is how the sound channels are rationed. I think we seem to be going round in circles with this discussion now so I don't want to keep going over the same ground, but basically the options are:
1. don't allow channel numbers to be specified in the script, and use a Priority for each sound instead so that AGS manages them automatically
OR
2. allow the scripter to specify a particular channel, like PlaySoundEx at the moment.
My plan is to go with option (1) because it seems simpler and more intuitive to use.
QuoteWith the Advanced script like this, wouldn't it cause some problems? Also seems a little confusing for those who might not understand scripting.
Well that's why I've called it the Advanced scripting. Beginners would just use a simple scripting line like the one I posted to just play a sound. But if you wanted more control over the sound (eg. to change its volume etc later on), you could save the pointer that Play() returned in order to do so.
QuoteThe 'SoundChannel* channel' should be part of the PlaySound command (as optional).
I feel the code to play sound should be like this:
aBullet.Play(eLoopType, ePriority, Optional Channel);
I'm not sure what the advantage of this is. And of course, Priority could be an optional parameter to simplify things if you didn't want to worry about it.
Quote
Yes there would still be a limit, but the question is how the sound channels are rationed. I think we seem to be going round in circles with this discussion now so I don't want to keep going over the same ground, but basically the options are:
Sorry abouyt going around and around, I was just had a a little lack of understanding of the current proposal. Option #1 appeals to me the most and is, IMHO, most consistent with the OO paradigm.
If all the sound channels were busy and a new sound was played then how would the priority scheme work? Would the new sound not be played or queued until a channel was available or would the new sound be played on a channel playing a lower priority sound? If there were more than one channel playing sounds of the same priority which one would be canceled, the oldest one perhaps?
With this option how would one get a list of the currently playing sounds?
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.
How about an equalizer? I think that people would find that useful.
Quote from: GarageGothic on Sun 08/03/2009 19:06:04
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.
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...
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?
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.
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.
I'd also prefer 0-100. Can you really hear a difference between a fade from 0 to 100 and from 0 to 255?
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?
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?
It wouldn't be too horribly difficult to just do:
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.
I agree!
Keep 8-bit sound volume.
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.
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.
Indeed, 0-100 would make more sense.
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.
I agree on the 0-100 method. Name one practical advantage 8bit volume has over the percentage method!
Cheers,
Sparky.
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):
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.
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:
Quote from: Iceboty V7000a on Wed 15/08/2012 07:01:07
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:
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
MyAudioGroup1.GetRandom().Play()Or something like that.
Quote from: Crimson Wizard on Wed 15/08/2012 14:38:06
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.
Would being able to refer to the music/sound files by their AudioCache index number be at all a useful compromise there?
Quote from: Iceboty V7000a on Wed 15/08/2012 14:50:07
Quote from: Crimson Wizard on Wed 15/08/2012 14:38:06
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.
First of all, this is bloated because you have to do this in script "by hand". To think of this, every array in the game (characters, etc) is being constructed like that on startup, only internally. Here in this example I constructed my own "alternate" array of game items. Is there so much difference between getting a random item by number from "original" or "custom" array?
What if you won't have to write this in script, but manage items in project folders having editor/engine do the rest?
Then, addressing items by their array index may cause troubles because their positions may change in the future. You'll have to keep an eye on that every time you add/remove/change anything.
I totally agree that in current AGS it might be easier to do address things by using indexes in their main arrays (I myself did that many times), but IMO that's only because AGS script does not provide alternate appropriate ways to do this.
Also, I don't think this has anything to do with OOP... it is rather a question of Key type which is used to iterate/access data.
//---------------------------------------------------------------------------------------------------------------
EDIT:
I am sorry for not saying this first time I edited this post, but I think I should elaborate further.
You called using indexes ("numbers") an "elegant" solution. I have to disagree. That may be (or may seem) simple and fast to use, but I do not find it elegant.
Let's examine two options when you need to get some items from project data array.
Option 1 is when you need some certain item. Whether you access it by script name (cEgo) or by index (0) - it does not make much difference. In any case you must know its name (or "name" - an index).
Option 2 is when you need to get a group of items. It is here where method actually makes difference.
When you are getting a subset from a master set you are using certain rule of comparison. There's a reason why you are selecting these items and not the others. In you example you select them because they are appropriate candidates for a random sound.
Now, when you use numbers, you actually check the comparison rule
by yourself. It is you and only you who knows which items should be used. In other words you do the
extra work that could be done by the engine - if only you told it how to choose, which criteria to use. Not only this is an unsafe and error prone way, it is also a non-ultimate way, because, as I've already mentioned, you may change the number/indexes of your items later and also because you won't be able to reuse such code as-is.
What I want to say, there is always a criteria when certain items are being chosen from the set (aka collection). If AGS have means of defining these and getting items using these - that would be better solution.
What criterias might that be?
* All items from custom group.
* All items with custom property having certain value.
* All characters in the room.
* All room objects in the rectangle.
* ...
In your case that could be "all sound clips marked as 'use for random sound'" (or similar).
Quote from: Sslaxx on Wed 15/08/2012 14:58:57
Would being able to refer to the music/sound files by their AudioCache index number be at all a useful compromise there?
Yes. As I mentioned the sound clips are already numbered internally. Being able to address the clips directly with these numbers would be the most appropriate.
Quote from: Crimson Wizard on Wed 15/08/2012 15:20:54
First of all, this is bloated because you have to do this in script "by hand". To think of this, every array in the game (characters, etc) is being constructed like that on startup, only internally. Here in this example I constructed my own "alternate" array of game items. Is there so much difference between getting a random item by number from "original" or "custom" array?
This is very stupid. If as you mentioned, every array is already constructed that way internally, then there isn't much reason to waste time(and probably memory) in constructing more arrays manually when it is not necessary. You seem to think that the random sound example I mentioned is the only use of this feature but as I already pointed out, this is only a quick random example of how this can be used. In fact, there are numerous uses to this and you already mentioned earlier, that one use is to iterate through all the clips for some reasons, which cannot be done with the clumsy manual assignment way. Also, if it's done the way sprites are handled we don't even need to have an internal array. The point is to address the items by numbers. For sprites, while they're assigned automatically some numbers during import, you can change their numberings manually afterwards in the editor, so you can assign whatever "meaningful" numbers to them you like. (So sprites aren't really arranged in an array, as you can say have sprites #1,2,3,100,101,102 with #4-99 non-existing.)
Quote
What if you won't have to write this in script, but manage items in project folders having editor/engine do the rest?
This could be useful, but as I mentioned don't focus on just the random sound example. Sometimes I will need to have the clips arranged in a certain order for more complex stuff(such as using a formula in determining which item to use) so it is ideal to have numbers attached to them like the sprites.
Quote
Then, addressing items by their array index may cause troubles because their positions may change in the future. You'll have to keep an eye on that every time you add/remove/change anything.
If they are implemented like sprites as mentioned above this isn't a problem, as the numbering of existing items will not be renumbered by the editor every time you add/remove/change anything.
Quote
Option 1
No objection there.
QuoteOption 2
As I mentioned it is not limited to simple things like random sounds. If you think just being able to group items according to different criteria is enough this is your own preference. I actually abuse using the sprite numbers a lot, by say, choosing an appropriate sprite to display based on the result of a formula according to different parameters. Numbering the sprites appropriately can get the job done clean and straight and if you fear that people will not understand your own moonspeak, you can just put a few lines of comments to explain the numbering system. This is much more better than throwing in 100+ "descriptive" lines of assigning items to a custom array, which is prone to errors and is inconvenient.
Ah, pardon me, I made a mistake by focusing on "get all matching things" and forgot about "get things ordered so that a formula could be used".
I think I am also having "universalization" issue and that makes me go too far sometimes.
Currently I am trying to find out what would be better way to solve this problem so that it's both easy to use if you need to do some simple things and if you need something complex.
The problem with game items is that their organization in project tree either hides their order (e.g. audio clips) and/or makes it impossible to change that order (practically anything else).
You mentioned how sprites are being ordered by assigning numeric ids to them. If other game items could have same changeable numeric ID that would indeed make the situation easier.
//------------
EDITED.
Here was some lengthy suggestion, but later I decided to remove it, because I started to feel I went into wrong direction again. Probably I need to think more on this.
This might be too late to mention, but there's an option in General project settings: Enforce new-style audio scripting. When set to FALSE it enables older functions like PlaySound (which takes sound index as parameter). Probably it will allow to mix both styles in one game. Never tried that myself though. Not the best thing, but may work as a temporary solution.