I would like to make some small suggestions that might hopefully bring some quality-of-life improvements to working with frame-linked audio:
1) Having some kind of visual indicator for frames with linked audio, like a simple dot above the frame, or an "x", or a music note symbol, or something of the sort, would make it so much easier to identify at a quick glance which frames have audio linked to them, something that can be a huge nuisance when you have views with a lot of long loops and you need to find that *one* frame with a specific audio clip.
2) More engine- than editor-related, but having the audioclip DefaultVolume property be accessible and modifiable by script would be incredibly useful; for example, to be able to easily do fading footsteps, among many other situations.
3) Maybe this one is a bit more complicated, but would it be possible to make it so that, when an animation is played in the preview panel, the frame-linked audioclips play too?
Quote from: Laura Hunt on Mon 25/01/2021 21:05:06
2) More engine- than editor-related, but having the audioclip DefaultVolume property be accessible and modifiable by script would be incredibly useful; for example, to be able to easily do fading footsteps, among many other situations.
Is this related to not being able to configure frame audio's volume when it starts? If so, perhaps it would be better to find a direct solution to that.
Quote from: Crimson Wizard on Mon 25/01/2021 22:09:13
Quote from: Laura Hunt on Mon 25/01/2021 21:05:06
2) More engine- than editor-related, but having the audioclip DefaultVolume property be accessible and modifiable by script would be incredibly useful; for example, to be able to easily do fading footsteps, among many other situations.
Is this related to not being able to configure frame audio's volume when it starts? If so, perhaps it would be better to find a direct solution to that.
I wasn't aware that this was being looked into, but yes, that approach would also fix the issue.
Well, I would not say it's looked into right now (unless I am not aware of that), but it seems more natural to be able to setup how the frame trigger plays the sound rather than modify original clip's properties.
Ofcourse original clip may also be made modifiable, because why not, the property is just a number, but it feels like a wrong solution for the frame sound problem.
I briefly played with adding an indicator for audio in the frame
(https://i.imgur.com/S3nKrUf.png)
Wonder if it's alright or too subtle. I used the existing icon for audio.
Quote from: eri0o on Sat 18/09/2021 22:13:08
I briefly played with adding an indicator for audio in the frame
Wonder if it's alright or too subtle. I used the existing icon for audio.
Hey, that looks really cool! I personally would be totally ok with this icon, it's not intrusive and it's pretty self-explanatory, I think.
Another possibility for the sound indicator, trying to figure out which one works best.
a)
(https://user-images.githubusercontent.com/2244442/134773064-e190d11a-9feb-416b-90ab-ada88704307f.gif)
b)
(https://user-images.githubusercontent.com/2244442/134771622-17053bca-c426-46bb-b7e0-c6a65f8c6e24.gif)
c)
(https://user-images.githubusercontent.com/2244442/134772517-dfd75c97-bdc9-46ea-84e6-b644109a0fad.gif)
I think the audio indicator should go outside of the sprite box. In these three cases the icon is clearly visible because the sprite has a large transparent area, but if the sprite is not transparent, the icon will be much harder to see (if not completely invisible, depending on the sprite colours). I think the very first example you posted is the right way to go here.
Next iteration of the previous idea of use the Frame. The icon green square is actually the reverse color of whatever color is below, and the icon itself is draw with only white and green.
I think being inside the frame translates better the sound linked to the frame idea, so wanted to do an additional test. :)
(https://user-images.githubusercontent.com/2244442/134784755-570711cc-7104-4d62-bf37-c272482ec73c.png)
I think also it should stay outside the sprite, as it risks covering an important part of the sprite.
Sorry for not having dropped by in a while :) This latest revision does look much better, but I think I have to agree with Cassie. It might be a bit of an edge case but I'm not sure having anything on top of the sprite is a good idea...
I'd rather the icon be inside. Nobody has ever managed too see jack squat in those ant-sized frames anyway.
Besides, eri0o implemented a magnifying slider and i can make a smaller icon made only of inverted color, so there's no actual obstruction. The complaints are invalid.
Moreover, I wonder if anyone would actually notice, since linking audio to frames doesn't happen very often.
- Alan
I believe having the icon in frame would be a problem in the example Dave Gilbert provided in the thread talking about the magnifying slider. He has a whole view of the character lying or rolling on the ground rather than standing at the farleft. In frame would be acceptable if one could drag it around to an ubobstructive location.
https://www.adventuregamestudio.co.uk/forums/index.php?topic=59418.msg636639980#msg636639980 (https://www.adventuregamestudio.co.uk/forums/index.php?topic=59418.msg636639980#msg636639980)
(https://user-images.githubusercontent.com/2244442/149632626-a1d974e4-18be-4492-bfc0-95c1cad2aad3.png).
I removed the DLY as indicator of delay, and now if the delay is non zero, I added an icon for it with it's value. A sound in the frame is also indicated below. Hopefully this is good enough so we can go this way.
Edit: it will be in the next release of 3.6.0
Well, I don't know what others will think, but this looks good to me! Very elegant and not intrusive at all.
Personally I feel like these icons should be locked to certain position, like they often do on status bars.
Example: the clock icon at the left, and sound icon aligned at the right, so that it would always be on same relative spot.
But I guess one needs to work with the editor for a while to see how it is.
NOTE: the icons are included in the latest release of 3.6.0 alpha
(https://www.adventuregamestudio.co.uk/forums/index.php?topic=58976.0)
there are still 2 and 3 that are open if someone finds this thread.
Quote2) More engine- than editor-related, but having the audioclip DefaultVolume property be accessible and modifiable by script would be incredibly useful; for example, to be able to easily do fading footsteps, among many other situations.
3) Maybe this one is a bit more complicated, but would it be possible to make it so that, when an animation is played in the preview panel, the frame-linked audioclips play too?
3 is probably easily doable (maybe I will eat my words), should possibly default to being mute and have a flag and a default preference setting for that.
Quote from: eri0o on Mon 31/01/2022 12:56:04
there are still 2 and 3 that are open if someone finds this thread.
Quote2) More engine- than editor-related, but having the audioclip DefaultVolume property be accessible and modifiable by script would be incredibly useful; for example, to be able to easily do fading footsteps, among many other situations.
I already replied to this above (my comment (https://www.adventuregamestudio.co.uk/forums/index.php?topic=58788.msg636631604#msg636631604)), but might reiterate, that I disagree that this should be done through clip's DefaultVolume, as the clip as a central resource that may be used from several objects, even simultaneously.
For the given case, in my opinion there could be a volume control for particular
sound/animation user instead. In general, imo, we need to move away from controlling clips idea towards the idea of controlling audio source.
For a draft example, literally have a AnimationVolume property in Character and Object.
If there are other cases where this solution won't work, we need to discuss these and investigate solution separately.
EDIT: this unfortunately would only let to set volume, but not other playback properties, available at the AudioChannel. It would be curious to figure out whether there may be a good solution to automatically receiving an audio channel where the frame is playing. On the other hand, is it wise to give full control to frame playback? E.g. user then may even rewind it indefinitely until replaced by another sound...
There's something I'd like to try adding to 3.6.0:
* an extra "volume" parameter to Animate functions (Character.Animate, Object.Animate, Button.Animate), which defines the sound volume for the duration of this particular animation.
* a Character.AnimationVolume property, which defines the sound volume for all animations played from this character.
Here I tried to keep additions to minimum necessary to control the frame volume.
Both solutions treat the volume setting as a relative (percent of the default clip's volume). Default value of -1 means "use default volume".
The reasoning for having AnimationVolume only in Character is that Characters have animations run implicitly (walking, speaking, idle), unlike other types which require explicit Animate call.
Animate's parameter has a priority over AnimationVolume, - this way you may have implicit character's animation volume and still override it with the Animate param when necessary.
On another hand, it is still possible to change Object and Button's volume in the middle of animation by re-calling Animate with different starting frame and volume, like:
obj.Animate(obj.Loop, delay, eRepeat, eNoBlock, eForward, obj.Frame, new_volume);
If the above is not convenient, it's technically possible to add AnimationVolume also to these types, but I would not do that unless really necessary. (From what I understood, character's volume is a main issue here)
Hey sounds have a type, and we can set the volume of sounds of a specific type, but we can also set the volume of a playing clip (an instance) through modifying the audio channel volume.
Unfortunately both of these modify the absolute volume. So you can't make a volume slider in your game menu and then have the volume of the sounds in the game be scaled, instead you need to script your own sound system to provide these relative volumes.
With the proposed addition, we have more volumes to track in the scripted system, and the functions need to be extended to use a different one that will apply a relative audio volume.
Is it possible to simply change how things work and have the volume percentage of the type be multiplied by the other volume, so we can have in game volume sliders for the player to configure, while also being able to play sounds at different volumes, without scripting such mixing system?
Here's a post where I explain more of what I mean by relative volumes: https://www.adventuregamestudio.co.uk/forums/index.php?topic=55194.0
I keep thinking about wrapping the current implementation of the above system as a module, but then I hope it will not be needed someday.
Quote from: eri0o on Tue 26/04/2022 16:22:56
Is it possible to simply change how things work and have the volume percentage of the type be multiplied by the other volume, so we can have in game volume sliders for the player to configure, while also being able to play sounds at different volumes, without scripting such mixing system?
Yes, indeed, it's possible to make all engine's volume "sliders" relative; and maybe even worth to do this in 3.6.0 (with backward compatible mode).
However, that does not fix anything for the animation sounds; the problem remains:
* you cannot control single character's volume using a sound type volume, because that sound type may be shared among many things in game, and you might want individual volume for this particular character.
* there's no explicit way to tell on which channel particular character's animation frame is played.
* even if there were a way to access such channel, it may be too late, as the frame sound is started not by the script but by the engine during its internal update, and when the script runs it may be already playing, so setting volume in script will affect the playback a moment later.
The channel access problem is still a problem even with the proposed solution for animation volume, so this will have to be addressed anyway at some point. Maybe revamping sound system to have control over playback instances rather than channels will make this easier to manage.
Quote from: eri0o on Tue 26/04/2022 16:22:56
With the proposed addition, we have more volumes to track in the scripted system, and the functions need to be extended to use a different one that will apply a relative audio volume.
Not at all; the proposed AnimationVolume is supposed to be relative to the sound clip's starting volume, which is taken from the sound type volume. In other words, AnimationVolume will be a factor combined with a AudioType's Volume factor.
The way I see this, the future audio system may be consisting of several levels, for example:
Sound emitter's volume (emitter = object spreading sound) -> Playback instance volume -> Global audio volumes (per type, etc).
If all of these are relative, then this system will work well, you'll have global sliders, and a way to adjust individual game elements too.
Yes, having the behavior being relative, so we get the final volume as a multiplication of the volumes (1.0 being 100%) type and the specific clip would be very helpful!
Regarding the character, would panning or sound location be a thing that makes sense? Or better to save for later - like if we have the concept of sound emitter.
Quote from: eri0o on Tue 26/04/2022 18:05:53
Yes, having the behavior being relative, so we get the final volume as a multiplication of the volumes (1.0 being 100%) type and the specific clip would be very helpful!
I
suppose, that it should normally work like this:
AudioChannel.Volume is a % of -----> Audio Type volume, which is a % of ------> System.Volume
(and default clip's volume assigns the initial AudioChannel.Volume)
Right now AudioChannel.Volume and Audio Type volume are basically same absolute units, and setting them would override each other in a playing clip.
Yes, the relationship you wrote is what I had in mind. If we assume volume goes from 0.0 to 1.0 range, we simply multiply all of these to get the final volume.
This will be great, because then we can simply use the types to provide say a sound effect, a music and an ambient sound slider. And the character stepping sound can be like a sound effect or ambient or even it's own type, so we can control the volume in a relative way.
If anyone likes to try out, here's an experimental build containing Character.AnimationVolume, and extra "volume" parameter in all Animate() functions (for Character, Object and Button):
https://cirrus-ci.com/task/5930020521639936
An example of use:
function repeatedly_execute() {
player.AnimationVolume = (player.x * 100) / Room.Width;
}
will scale volume of player's animation (like, footsteps) depending on its X position in the room.
So, both indicator and the way to change animation's volume are now in the latest 3.6.0 beta.
Apparently, this was resolved in 3.6.0.