This is another of those little niceties that I've just found a potential use for-
The .animated object format currently makes no provision for loading sounds. I can currently make an object that moves backwards and forwards along a track, but the sounds remain in one place. I was also thinking about some actuation sounds for semaphore signals, more potential uses too
I suggest adding a [Sound] section to allow for the loading of sound files. Essentially, this should be identical to any other [Object] in terms of basic functionality.
Functions-

Code: Select all

States - Identical to the Object implementation
TranslateX - Identical to the Object implementation
TranslateY - Identical to the Object implementation
TranslateZ - Identical to the Object implementation
Volume - Allow for either increasing or decreasing the volume by any available formula
Speed - Allows for increasing or decreasing the playback speed, again via the current formula system

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Initiating the sounds by entries in an extended .animated file format certainly does sound interesting (no pun intended!); and would allow the possibilities such as targetted placement of door, engine, or fans sounds where they really are on the model. The sound system (internally) to Openbve is somewhat more advanced; rather than setting volume directly, you provide to Openbve attributes such as position, velocity, gain and attenuation allowing things like doppler to be calculated relative to the listener's position, direction and velocity.

I'd encourage having a look at the OpenAL documentation and see if you can suggest how these parameters could perhaps be exposed in a useful way:

• http://connect.creativelabs.com/openal/Documentation/OpenAL%201.1%20Specification.htm#_Toc199835871

Before that, michelle also heard similar ideas. She had shown out her agreement, and may add similar features.

I also support, but instead, we may do it with plugins... or so. Right?

sladen wrote:Initiating the sounds by entries in an extended .animated file format certainly does sound interesting (no pun intended!); and would allow the possibilities such as targetted placement of door, engine, or fans sounds where they really are on the model. The sound system (internally) to Openbve is somewhat more advanced; rather than setting volume directly, you provide to Openbve attributes such as position, velocity, gain and attenuation allowing things like doppler to be calculated relative to the listener's position, direction and velocity.

I'd encourage having a look at the OpenAL documentation and see if you can suggest how these parameters could perhaps be exposed in a useful way:

• http://connect.creativelabs.com/openal/Documentation/OpenAL%201.1%20Specification.htm#_Toc199835871

I don't deny that playing with these sorts of things is nice, but one of the better aspects of BVE/ OpenBVE has always been the fact that you don't need a degree in mathematics to understand the basic object/ route semantics.
With that in mind, this is a slightly revised list:

Code: Select all

Position - Allow positioning of the object
Volume - Volume in dB at 0,0,0 in terms of the object.
AttenuationX - Allow alteration of attenuation in the X- axis
AttenuationY - Allow alteration of attenuation in the Y- axis
AttenuationZ - Allow alteration of attenuation in the Z- axis
Speed - Allow increase or decrease of the playback speed

Thinking about it, allowing alteration of attenuation in the different directions is a logical step- Some sounds are far more directional than others
Gain could also be added in exactly the same way as attenuation, but TBQH while this would be a nicety, but not really needed.
Position is obvious, and should have been in my initial list, that was an oversight.
Velocity should be calculated internally from the movement of the object I'd have thought.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

I think that including options for sound would make more sense as part of the [Object] section. After all, when moving or rotating an object, you would want a sound attached to it to follow the object without having to duplicate formulas.

Therefore, I would suggest:

Code: Select all

[Object]
Position = X, Y, Z
States = obj1.csv, obj2.csv, obj3.csv
StateFunction = FORMULA
TranslateXFunction = FORMULA
TranslateYFunction = FORMULA
... and so on ...
Sounds = snd1.wav, snd2.wav, snd3.wav
SoundFunction = FORMULA
SoundPosition = X, Y, Z
SoundRadius = DISTANCE
VolumeFunction = FORMULA
PitchFunction = FORMULA

where SoundPosition would correspond to coordinates in object space (as in the B3D/CSV files).

I have to admit that I don't see a particular benefit to allowing pitch and volume changes. Can you think of any usage examples?

Also, should sounds play in a loop, or only once? Is it necessary to control this? Again, provide usage examples.

The main trouble I can see with including the sound in the [Object] section is that it wouldn't be possible to include dissasociated sounds (Unless the initial object was optional), triggered by formulas. That, plus I feel it's neater to have a separate section, as it's a distinct item within the context of the simulation

Pitch and volume changes would be of most use when building locomotive objects, as this would allow us to build an exterior soundset. Mathematical functions aren't my strong point, but something like this paraphrase, assuming pluginState1 is engine RPM with a max of 1000:

Code: Select all

VolumeFunction = (pluginState[1] / 1000) * 10

A similar thing could be done with pitch.


Definitely necessary to control whether sounds play in a loop, if only for completenesses sense (Although it could be argued that they should play in a loop and be turned on/ off by the basic function)
I'd probably implement a complete function for this, similar to the current StateFunction:
If we assume pluginState2 to be whether the locomotive engine is running, using LoopFunction allows us to switch sound playback from the single looped running sound to non-looped playback for the single file rundown sound, which would obviously be triggered later in the function tree

Code: Select all

LoopFunction = if[pluginState[2] == 1, 0,1]

Cheers

Chris Lees

http://www.bvecornwall.co.uk