Home    LittleBigPlanet 2 - 3 - Vita - Karting    LittleBigPlanet 2    [LBP2] Help!
#1

Audio range problem

Archive: 22 posts


I made the silly mistake of creating my level with the sound turned down, now I'm stuck with this:

My level is a top-down shooter. The sackboys are stored off-screen and the game view area is a fully zoomed-out movie camera. The problem is, the sound effects (spaceships exploding etc.) are really quiet when they occur near the left or right edge of the screen. I'm guessing the movie camera picks up sound from the middle of the screen. Top and bottom isn't such an issue because the screen is wider than it is high.

I changed all the FX in my level to non-positional sound... but that didn't seem to affect the volume, just the stereo position. ****.

Is there any way to rescue this without rebuilding the whole level?

edit: I tried using a 'game camera' instead - same problem. It looks like the only solution is to size all the level assets down until the fit inside the audio radius. Not fun with 50+ emitters in a level. Sigh Any ideas at this point would be a ray of hope...
2011-03-09 00:33:00

Author:
Bovrillor
Posts: 309


Ok, go to the tools section of the poppet then scroll all the way to the right, then go down to audio, and I think you can fix it from there.2011-03-09 03:26:00

Author:
fireblitz95
Posts: 2018


Setting "positional" to false should make the sound play at full volume (Whatever volume in the sound is set to) at all times.2011-03-09 03:31:00

Author:
Foofles
Posts: 2278


What Foofles said. Also, make sure that the level's sound settings an the general sound settings in the options menu do not interfere with the overall volume for sound effects. Setting each sound object's positional setting to false should do the trick all by itself.2011-03-09 11:30:00

Author:
sny
Posts: 144


Setting "positional" to false should make the sound play at full volume (Whatever volume in the sound is set to) at all times.

This doesn't seem to affect the volume of sounds at all, just the 'stereo position' of the sound.

I'm pretty sure the problem is inherent to the game.... the camera can be zoomed out further than the maximum audio radius - so with max zoom-out sounds at the edge of the screen will always be near-silent. I was up 'til 3am sizing everything down
2011-03-09 13:28:00

Author:
Bovrillor
Posts: 309


This doesn't seem to affect the volume of sounds at all, just the 'stereo position' of the sound.

No, positional = false eliminates the entire 3D sound position AND volume dampening. Trust me, I've used it thousands of times. I have sounds playing on chips from the total opposite boundary of the level that are completely audible.

What you might want to do is hook logic into the sounds to activate them when they're needed. Like give them a player / tag sensor and play them when you're within range. If a signal goes into a sound set to non-positional, you will hear it anywhere and everywhere in the level. You could even use the volume input method of a sound to give the illusion of positional sound.
2011-03-09 13:41:00

Author:
Foofles
Posts: 2278


All the sounds are emitted from 'enemy spaceships' that are bouncing around the (fixed position) screen. They're all set to non-positional and they are still inaudible at the left and right extremes of the screen. They're all on microchips, activated by a tag sensor that senses the player's bullets, triggers the sound then destroys the ship. By your logic, Foofles, they should be working... and yet they're not

Likewise, sounds caused by the game engine (emitted objects being destroyed, collisions etc) are also inaudible at the edges.

Shrinking the whole construction down and zooming in the camera to compensate did rectify the issue, at the expense of my visuals. I still have the original in the hope of figuring this mess out.
2011-03-09 15:04:00

Author:
Bovrillor
Posts: 309


Very strange. If you have the time, I would encourage you to pass this on to Mm as a bug. It should not work as you describe, and there should have been no need for you to "shrink" your level to accommodate the problem.2011-03-09 15:13:00

Author:
v0rtex
Posts: 1878


I wonder if you got your level default settings a bit wonky? You might check your current settings against a new blank level.

..another thought, are you using any global audio tweakers? Posssibly one is on that is dampening all your other sounds.

..also to insure your speakers are indeed firing, hook some lights to that same input to the speakers and have them placed large and where you can see them. I went nuts on one speaker once and found it was due to my impact switch not set correctly and thus not firing my speaker.
2011-03-09 15:33:00

Author:
jwwphotos
Posts: 11383


I wonder if you got your level default settings a bit wonky? You might check your current settings against a new blank level.

..another thought, are you using any global audio tweakers? Posssibly one is on that is dampening all your other sounds.

I'm not using any global tweakers. I cannot think of any other 'default settings' that could be 'wonky'. The only master sliders I've changed are gravity, light and darkness.
2011-03-09 15:39:00

Author:
Bovrillor
Posts: 309


All the sounds are emitted from 'enemy spaceships' that are bouncing around the (fixed position) screen. They're all set to non-positional and they are still inaudible at the left and right extremes of the screen. They're all on microchips, activated by a tag sensor that senses the player's bullets, triggers the sound then destroys the ship. By your logic, Foofles, they should be working... and yet they're not

Likewise, sounds caused by the game engine (emitted objects being destroyed, collisions etc) are also inaudible at the edges.

Shrinking the whole construction down and zooming in the camera to compensate did rectify the issue, at the expense of my visuals. I still have the original in the hope of figuring this mess out.

Send me an invite from my planet and I'll see if I can help solve it. I think you're missing something very simple here.

Game physics sounds are always set to "positional" so that is normal behaviour there. Is your movie camera flatness all the way down?

The other thing is, are your sounds set to use input method "On/off" or "Play once" ... Try using play once. IT's also possible in the case of being destroyed that the destruction takes priority. You can use a counter of 1 to make a single cycle delay to make sure the sound fires, or try using the "On Destruction" playback method.
2011-03-09 15:46:00

Author:
Foofles
Posts: 2278


Send me an invite from my planet and I'll see if I can help solve it. I think you're missing something very simple here.

Game physics sounds are always set to "positional" so that is normal behaviour there. Is your movie camera flatness all the way down?

The other thing is, are your sounds set to use input method "On/off" or "Play once" ... Try using play once. IT's also possible in the case of being destroyed that the destruction takes priority. You can use a counter of 1 to make a single cycle delay to make sure the sound fires, or try using the "On Destruction" playback method.

Aha! Problem located...

It seems that with the input method set to on/off, the sound FX were always subject to positional sound, no matter how I set them. Setting them to One-Shot or removing the switch and triggering the sound on destruction both seemed to correct the issue.

Thankyou Foofles for your advice, and likewise everyone else for your efforts. In solving this I've noticed another bug - something to do with emitters not updating the emitted object when you change the 'master copy' - only seems to apply to certain materials though? WTF? I'll make another thread for this.
2011-03-09 16:41:00

Author:
Bovrillor
Posts: 309


something to do with emitters not updating the emitted object when you change the 'master copy' - only seems to apply to certain materials though? WTF? I'll make another thread for this.

If an object is emitted, and that object emit i.e. projectiles, (all dynamically loaded) you need to reload the emitter that will be emitting last in the chain (in this case the projectiles)
2011-03-09 16:47:00

Author:
Luos_83
Posts: 2136


something to do with emitters not updating the emitted object when you change the 'master copy' - only seems to apply to certain materials though? WTF? I'll make another thread for this.

If an object is emitted, and that object emit i.e. projectiles, (all dynamically loaded) you need to reload the emitter that will be emitting last in the chain (in this case the projectiles)

And this applies in all instances where there are 2 or more 'layers' of emitted objects?
If there were, say, 3 layers of emitter, I would only need to reload the last one? Or everything after the first?

(Had I known about this emitter stuff in the first place, the audio problem would have been resolved in seconds, lol)
2011-03-09 17:00:00

Author:
Bovrillor
Posts: 309


In solving this I've noticed another bug - something to do with emitters not updating the emitted object when you change the 'master copy' - only seems to apply to certain materials though?

The "dynamic emitter" stuff is kinda broken, so expect it to randomly fail. Bearing that in mind, were you implying that this problem was responsible for your audio issue, i.e. that the Sound Objects were on emitted objects, and weren't being updated in the emitter when you changed the reference copy?
2011-03-09 18:41:00

Author:
Aya042
Posts: 2870


The "dynamic emitter" stuff is kinda broken, so expect it to randomly fail. Bearing that in mind, were you implying that this problem was responsible for your audio issue, i.e. that the Sound Objects were on emitted objects, and weren't being updated in the emitter when you changed the reference copy?

Indeed - I believe I had tried setting the destruction sounds to 'Play Once' but the emitters had not registered it. As soon as I re-set the emitters, the fix provided by Foofles worked just fine.

It's worth noting that Sound FX Objects with input set to 'On/Off' still only seem able to emit positional sounds and are therefore not very useful when working with massively zoomed-out cameras. If someone else could confirm this theory it'd help out somewhat with the bug report.
2011-03-09 19:01:00

Author:
Bovrillor
Posts: 309


It's worth noting that Sound FX Objects with input set to 'On/Off' still only seem able to emit positional sounds and are therefore not very useful when working with massively zoomed-out cameras. If someone else could confirm this theory it'd help out somewhat with the bug report.

Works for me. Perhaps it was the same problem, i.e. you turned Positional sound off, but the emitted copies weren't updated?
2011-03-09 19:24:00

Author:
Aya042
Posts: 2870


Works for me. Perhaps it was the same problem, i.e. you turned Positional sound off, but the emitted copies weren't updated?

Very strange. Perhaps something to with the object being destroyed at the same time then. Arrrgh I don't know, too many variables... the problem's gone I should just be grateful lol
2011-03-09 20:01:00

Author:
Bovrillor
Posts: 309


Good thing that got sorted.

Any ideas what's causing the emitters to stop tracing changes made to the template object? As witnessed, it can be quite an annoying problem and cause a lot of unnecessary work.
2011-03-09 21:25:00

Author:
tameturtle
Posts: 150


Any ideas what's causing the emitters to stop tracing changes made to the template object? As witnessed, it can be quite an annoying problem and cause a lot of unnecessary work.

Never really put much effort into tracking it down, but at a guess I'd say that it's either:-

A bug whereby some minor changes to the reference object aren't being registered as actual changes, and don't update the emitter. I remember a similar bug in LBP1 where changing the contents of a Prize Bubble didn't mark the level state as 'dirty' and thus didn't ask if you wanted to save changes when you return to the pod.
A 'feature' whereby emitters pre-populate the simulation event queue with the current state of the reference object as far as "Max Emitted" or "Max Emitted At Once" is set to, and won't update the pre-queued events if you change the reference object, or something like that.
2011-03-10 15:18:00

Author:
Aya042
Posts: 2870


Never really put much effort into tracking it down, but at a guess I'd say that it's either:-

A bug whereby some minor changes to the reference object aren't being registered as actual changes, and don't update the emitter. I remember a similar bug in LBP1 where changing the contents of a Prize Bubble didn't mark the level state as 'dirty' and thus didn't ask if you wanted to save changes when you return to the pod.
A 'feature' whereby emitters pre-populate the simulation event queue with the current state of the reference object as far as "Max Emitted" or "Max Emitted At Once" is set to, and won't update the pre-queued events if you change the reference object, or something like that.


Here's hoping the feature gets improved in future patches, dynamic emitted object selection is one of the best new features of LBP2 in my opinion (mainly because most my projects use multi-stage emitters).

It'd be even better if they could implement some kind of 'sandbox' where one could modify stored objects in an isolated environment without leaving the actual project... with a UI similiar to the microchip where it can be expanded/collapsed when not in use. Normally I create an area for this somewhere out of sight, but some things (particularly sound fx) have a tendancy to escape, lol
2011-03-10 16:06:00

Author:
Bovrillor
Posts: 309


I think the "event queue" idea might point in the right direction. If I'm not mistaken, the 2nd-stage emitters in my current project failed to update when I didn't rewind after unpausing once (which I usually do). Will try to confirm this in a proper test later on.

Edit: that's not it. A 2nd-stage emitter fails to track reference object changes right away, nothing to do with unpausing/undoing.
2011-03-11 07:48:00

Author:
tameturtle
Posts: 150


LBPCentral Archive Statistics
Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Datenschutz
Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.