0
0

Hi!

I’m aware this topic has been brought up a few times before, but I have an additional question to which it relates.

As far as I’m aware, the current method of delaying a sound def from playing is to set up a parameter in the event, make the parameter have a velocity of 1, and then set the units and max value to whatever is appropriate, and then slide the sound def along the newly created time-line until it’s at the desired delay time.

When I tried this method, and "played" the event in fmod designer, the red marker/bar that I expected to start moving along the time-line did not move at all. The only time I could get the red bar to move along was to align the sound def back to 0:00:00.

I asked my fellow sound designer how to "preview" a sound definition with a delay and he said he usually adds a second sound definition at 0:00:00 to fake fmod into thinking a sound is there.

My question is, is this the only way to preview a time delayed sound definition?

Thanks!
North

  • You must to post comments
0
0

I came across this post looking to see if there were other ways to delay a sound. I don’t believe this delay parameter has been added yet, correct?

As a side note for anyone else having trouble getting one-shots to play when delayed via the timeline parameter method (as described above), it can be done with oneshot set to true provided that you have the ‘keyoff on silence’ checked and that you have a sustain point located somewhere on top of the delayed sound (i.e. no need for a fake/silent sound to fool the red cursor/bar into thinking there’s a sound playing).

Sean

  • You must to post comments
0
0

It looks like this happens if OneShot is true. If OneShot is false, then the velocity param works. I’m pretty sure this behavior is relatively new.

  • You must to post comments
0
0

+1 for this feature.

Although we ended getting our audio programmer to provide this functionality with user properties.

That said, I’d prefer it to be managed internally by Fmod EX so that event stealing / max playbacks can be considered / controlled.

  • You must to post comments
0
0

[quote="audiodev":i403s0h9]It looks like this happens if OneShot is true. If OneShot is false, then the velocity param works. I’m pretty sure this behavior is relatively new.[/quote:i403s0h9]

Yes audiodev is right, if the event’s ‘One-shot’ property is set to true, the event will end as soon as no sound def. instance is selected or silence is detected. I think behavior was included when ‘keyoff on silence’ was added…maybe???

I guess the only other point is to remember to release the event instance manually, once the oneshot property is set to no.

cheers,
Templar

  • You must to post comments
0
0

Good idea. I asked one of our programmers about going the user property route too. They said it’s not too much trouble, but I’ll need to decide at what point the volume of sounds requiring delays merits this effort from them. If it’s only a handful of sounds, then I’m okay with doing the delay via the timeline parameter approach. However, since I probably won’t be putting in the delays all in one shot, by the time I see that we have a lot of sounds requiring delays, it may be too late (i.e. I already implemented the delays myself). So, making this a standard FMOD feature could yield a pretty decent time savings when you add up all the projects implementing delays via these two methods (timeline parameter delay or user property delay).

Sean

  • You must to post comments
0
0

Ahh yes I understand.

So in order to have a timed delay and only use one sound definition, I have to set up the parameter, line up the sound definition, and set "One Shot = No". Which means the event will always be taking up a slot even though no sound is playing, which is not the desired effect.
Otherwise I will have to create a second sound definition in the event and add it to the start of the time line.

From my experience working on Bioshock, the delay function was just as commonly used as fade out and fade in functions, and was exposed to me in a very similar way. This made it very easy to iterate on the syncing up of sounds to any visual event/effect, and yet I didn’t have to worry about sound events sticking on, and adding extra sound definitions. I’d really like to have this on my current project too.

From reading the forums here, it seems like a simpler solution would be pretty popular.
I could imagine having a Delay or DelayRange (for randomized starts) where I could express a time in seconds (or milliseconds) like Delay=4000 on either the event level or within the sound instance properties. And that would be all there is to it.

Thanks!
North.

  • You must to post comments
0
0

I have a few events that are laid out as a sequence of 1 shot sounds over time, some with silence in between and at the beginning of the event. My solution to the problem of the 1shot event turning itself off before all sounds were played was to put in 1 extra layer, with a looping sound and volume all the way down, starting at the beginning of the event timeline and ending somewhere after the last sound in the sequence has started. It uses up 1 extra voice, but it works, and doesn’t require any programmer time.

  • You must to post comments
0
0

Agreed that a Delay event or sound instance param would be awesome.

To be clear, setting these events to OneShot = No is not an option. This sort of delay is most commonly used on sounds that are "fire and forget" sounds where the delay is used just to better sync the audio with some visuals. It would be a prohibative burden on the coders if we had to call stop() on all of these sounds.

  • You must to post comments
0
0

I’ve brought this one up before as well. Would really like this feature available at sound definition level (to maintain the event’s simple status).

  • You must to post comments
0
0

Well isn’t this a bug?
As I gather the behaviour, described by the original poster should only happen when "keyoff in silence" is checked and it should work as expected when it’s not checked.

  • You must to post comments
0
0

As per http://52.88.2.202/files/revision_tool.txt
It looks like our wish has been granted and this has been added to v4.29.07 (i.e. "Added trigger delay property for sound definition"). This is in the Development branch only. Not sure when it will make it to the Stable branch, but I assume it won’t be too long. Thanks, Firelight!

Sean

  • You must to post comments
0
0

It seems like a bug to me for sure.

Even when the bug is fixed, it would also be really nice to just have a delay time built into the event. It’s such a common operation that it would be nice to be able to author it without going through the steps of adding a parameter, setting the units, setting a velocity, and moving the sound instance.

  • You must to post comments
0
0

Yay! :)

  • You must to post comments
0
0

I don’t think its a bug, its doing what it advertises it does. We’ll look at adding some delay stuff into an upcoming version though.

  • You must to post comments
0
0

That’s awesome news!
Thanks guys.

  • You must to post comments
0
0

+1. This would be great :).

  • You must to post comments
0
0

this is a much needed addition! – feature request 😀

  • You must to post comments
Showing 17 results
Your Answer

Please first to submit.