Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

[Idea] Sound attenuation based on nearest player token

1605979407

Edited 1605979946
Pat
Pro
API Scripter
Okay, so here's what i'm going to be trying to do here, as script number two: instead of re-doing an existing script from scratch, a new idea that I'm not sure has been done. The concept of audio linked to location is up in the ideas forum; could we emulate that with at least taking into account all player tokens, since we can't per-channel player audio?  Maybe - I'm already detecting player proximity to a target with teleport, so the idea is using a GM layer "audio" token, associated with a sound file in the player library, and maybe integrating Roll20AM integration, but operating without, and have the auras indicate minimum and max volume distance - and maybe even having a "player count" or "percentage" so it only starts up and goes when enough players are close, or give the option to tie it to a player having a minimum perception.  So, I'll be posting here as I develop, and try and develop an interface similar to teleport - I'll keep working on teleport.  Next post will be the first iteration. AAFX (Attenuating Audio Effects)
Really cool, Pat. Looking forward to seeing the first iteration of this!
Very cool!  I'm guessing that you could probably take a look at the Radar script for inspiration!
1606032597
Pat
Pro
API Scripter
Beginnings are there - I'm getting output based on place of player token within the aura of an emitter token -  Next I wire it up to a soundtrack and see if it works for real for real! 
1606191282
Pat
Pro
API Scripter
Update It's got the rudiments of working: it acts like teleporter with regard to creating an emitter. And it detects players in range and starts the sound playing and sets the volume and the sound to looping - and adjusts the volume depending on how far away the target token is - it uses the two auras to calculate the "min" and "max" so you can adjust the range at which it goes to 100 volume - probably will set up some kind of sliding min and max scale for volume too...   To do: check for any tokens in range on drop, not just dropped token.  calculate sound volume based on closest token (otherwise one token moving away lowers sound for all tokens) check when no tokens are in range and turn off Try it yourself here: AAFX Gist
1606226474
David M.
Pro
API Scripter
Very interesting concept, Pat! The engineer in me wants the sound volume to follow an inverse square relationship with distance, but in practice I think the linear relationship you implemented may actually be a more effective...effect, as it results in more noticeable changes at longer distances for each increment. I've never used Roll20 for audio, but things like this make it tempting. Nicely done.
1606226966

Edited 1606227180
Pat
Pro
API Scripter
David M. said: Very interesting concept, Pat! The engineer in me wants the sound volume to follow an inverse square relationship with distance, but in practice I think the linear relationship you implemented may actually be a more effective...effect, as it results in more noticeable changes at longer distances for each increment. I've never used Roll20 for audio, but things like this make it tempting. Nicely done. Ah! Why didn't I think of that - a simple linear relationship was what jumped out at "percentile" - I can do inverse square, this was truly a first stab at "can it be remotely done?"  I could make that a toggle - Linear or Real? Make it a property of the emitter, so they can vary? And maybe force a global so you don't have to set individually? 
1606257948
David M.
Pro
API Scripter
Looking into this some more, and apparently the inverse square relationship is for sound energy (intensity), not sound pressure. According to this explanation , while sound intensity has a 1/r^2 drop-off, sound designers are mainly interested in the sound pressure, which follows a more gradual 1/r relationship! Who knew?! The 1/r will also probably showcase the script a bit more than the inverse square anyway, since the drop-off won't be as steep and players will be more likely to notice the difference at longer distances. Having it handle both linear and 1/r sounds great! (no pun intended) 
I made a suggestion for something like this based on FoundryVTT's feature (which works like Dynamic lighting but for sound - so a DL wall will block it) but it never got any traction. I'd give you my firstborn if you can get something like this working! ;)
1606275298
David M.
Pro
API Scripter
Pat, if you were interested in following up on this request, I have something in the radar script that Jarren mentioned above that could help out. Look at the code in the github for the  isLoSBlocked function. Actually, line 944 starts the section that finds all the DL lines on the page and parses the JSON into pts, then isLoSBlocked is called, which checks the center and four corners of a given token against a "source" token, and returns True if all five of the resulting line segments intersect a DL line segment. The code isn't very pretty, but it seems to work, and could give you something to work with. Doug E. said: I made a suggestion for something like this based on FoundryVTT's feature (which works like Dynamic lighting but for sound - so a DL wall will block it) but it never got any traction. I'd give you my firstborn if you can get something like this working! ;)
1606278286
Pat
Pro
API Scripter
David M. said: Pat, if you were interested in following up on this request, I have something in the radar script that Jarren mentioned above that could help out. Look at the code in the github for the  isLoSBlocked function. Actually, line 944 starts the section that finds all the DL lines on the page and parses the JSON into pts, then isLoSBlocked is called, which checks the center and four corners of a given token against a "source" token, and returns True if all five of the resulting line segments intersect a DL line segment. The code isn't very pretty, but it seems to work, and could give you something to work with. Doug E. said: I made a suggestion for something like this based on FoundryVTT's feature (which works like Dynamic lighting but for sound - so a DL wall will block it) but it never got any traction. I'd give you my firstborn if you can get something like this working! ;) Sure - I'll plug away at the basics here - this is my first from-scratch original concept, so I wanted to get as far as I could. The LOS blocking... I want to completely understand it before I take a look at it - and the issue with sound is that unless it's only one player online, it's calculating all players and taking the closest and part of me wants to crunch down the number of times things get pinged for data as much as I can.  I wish we had sound that was per-player - unfortunately this will be at best a rudimentary cousin to other scripts because of the lack of capability. 
1606307536
David M.
Pro
API Scripter
Ah, yep, no per-channel volume would be a serious impediment! Plus, not all LoS blocking elements would necessarily completely block sound for every case. Seems like a chat menu UI for volume adjustment/presets could work if there was some sort of Max Volume property on the token (or stored in state object). If on token, could also just use a token-mod chat menu without adding much complexity at all to the script.
1606326104
The Aaron
Roll20 Production Team
API Scripter
I really like how this is shaping up!  I'm looking forward to trying it out when I'm not so busy with work stuff! I like the idea of walls blocking the sound.  Even better might be having 2 intervening walls block the sound, and 1 only half its volume or something along those lines.  You can probably optimize things a bit by maintaining a graph for each page where the nodes are either sound sources or tokens that can hear, and the edges store information about the distance, intervening paths, and what sound settings to use for that hearing relationship.  When a token is moved, you'd adjust all its edges' values, and then check all the sound's edges for any sounds that you had to decrease the volume for on the original token.
1606351874

Edited 1606351902
Victor B.
Pro
Sheet Author
API Scripter
What about multiple tokens going hither and thither as players are want to do?  That could get wild.  You'll want to play with volume or possibly fade and possibly even delay if you're integrating Roll20AM
1606409813

Edited 1606413255
Pat
Pro
API Scripter
Update Baby steps for the neophyte API Scripter - basic check for any player tokens in the vicinity of any sound emitters, each emitter checks for all player tokens within its audible range, calculates the closest, sets the (linear for now) volume accordingly, and turns off and stops playing if there are no tokens to hear it.  Illustrated: Emitter, Closer Character, Further Character, Edge of Aura Logged output:  Both tokens out of range "Test Character Too" moved to close range. Second character moved to further range. Another illustration: two player tokens, two sound emitters, both tokens only in Boiling Mud emitter field...  Next is individual emitter editor with emitter properties settable and re-settable (aura range, track, max volume, falloff type (linear or 1/r) etc.  Gist is here.
1607008758
Pat
Pro
API Scripter
I haven't forgotten this - it's taken a backseat to troubleshooting teleport.js issues, which hopefully are now resolved. I'll switch to developing this, then once this is stable with most of the basic features I'm looking for (and after I ask a few questions about sound management and why I have ghost tracks haunting my audio files) I'll finish up what I want to fix on teleport (pad crowding and follower pull options).
1607271567
Pat
Pro
API Scripter
Update New version - the transition now fades instead of changing abruptly Basic edit for pad Catch for crashing errors Next: expanded edit max volume set both auras attenuation type edit which track is playing warning if track is in use by another emitter
It doesen't work for me.. but anyway, I think it automatically transfer the sound emitter token to the gm it seems ? It would be awesome if something like this could be attached to a normal token ( thinking about the patrol tokens with footstep sounds )
Haven't forgotten about this. Going to play with the script tonight or tomorrow night and report back!
1610065438
Pat
Pro
API Scripter
Renar said: It doesen't work for me.. but anyway, I think it automatically transfer the sound emitter token to the gm it seems ? It would be awesome if something like this could be attached to a normal token ( thinking about the patrol tokens with footstep sounds ) You need a player controlled token in proximity for it to work. If you put it down, it won't make any noise until a player-controlled token is within range; this means it won't pick up GM controlled NPCs as listeners. 
Tested it out tonight. I really like what you've got so far, Pat! The emitter setup is really easy; I'm looking forward to scaring my players with soundscapes as they approach the ruined keep or what have you.  I did notice that a token dropped onto the outer edge of the aura didn't trigger the emitter. Tried this a few times with different tokens and two different emitters. Besides the features others have mentioned and what you're planning to implement, my user requests are: - The ability to limit the max emitter volume. I definitely don't want it always going to max on Jukebox, as my players and I all play with headphones and we'd find it too loud. - The ability to set a default radius type (square or circle) in configuration (when you get config up and running). I prefer squares to circles, as it allows me to track the edges of each sound effect more closely. I can certainly change the emitter token's aura to square, as I did tonight, but it would be nice not to have to do it manually every time. - Definitely seconding the idea of two walls blocking sound and one wall blocking half sound. From an immersion standpoint, I'd love that. - Roll20 Audio Master integration would be obviously very welcome. :) - Would love to control fade-out time for the sound.
A couple more requests: - The ability to toggle off a sound emitter quickly. - Organizing sound emitter lists by page.
1610651246
Pat
Pro
API Scripter
Jay R. said: Tested it out tonight. I really like what you've got so far, Pat! The emitter setup is really easy; I'm looking forward to scaring my players with soundscapes as they approach the ruined keep or what have you.  I did notice that a token dropped onto the outer edge of the aura didn't trigger the emitter. Tried this a few times with different tokens and two different emitters. Besides the features others have mentioned and what you're planning to implement, my user requests are: - The ability to limit the max emitter volume. I definitely don't want it always going to max on Jukebox, as my players and I all play with headphones and we'd find it too loud. - The ability to set a default radius type (square or circle) in configuration (when you get config up and running). I prefer squares to circles, as it allows me to track the edges of each sound effect more closely. I can certainly change the emitter token's aura to square, as I did tonight, but it would be nice not to have to do it manually every time. - Definitely seconding the idea of two walls blocking sound and one wall blocking half sound. From an immersion standpoint, I'd love that. - Roll20 Audio Master integration would be obviously very welcome. :) - Would love to control fade-out time for the sound. Setting max emitter volume is in the works. Radius type I don't think would be meaningful - I'm planning on hiding the radius (transparent color) unless you toggle it visible - I guess I'm confused as to the "why" of this if we're talking walls blocking sound. The calculation is done based on radius to radius, not on the actual area you see - the token is calculated this way as well, so "square" area calculations would be an entirely different set of numbers. And the stated radius and the radius image don't always map one to one.  Walls blocking sound only matters for the closest player - I might simplify the calculations due to that.  I'm not sure I could integrate Roll20AM due to the number of pass-through commands necessary to make it work correctly. I could see about incorporating playlists outside of Roll20AM if the concern is multiple tracks played at once. As it is, this isn't set up for one-time sounds as it always assumes a looping track, and "It'sATrap" is probably better for one-time sound encounters.  Fade-out is only there to make it so there aren't abrupt shifts - the time is fixed, the amount is a step-down based on the distance between sound volumes. The fade-out for Dimmerswitch will be configurable on the other hand. 
Pat said: Radius type I don't think would be meaningful - I'm planning on hiding the radius (transparent color) unless you toggle it visible - I guess I'm confused as to the "why" of this if we're talking walls blocking sound. The calculation is done based on radius to radius, not on the actual area you see - the token is calculated this way as well, so "square" area calculations would be an entirely different set of numbers. And the stated radius and the radius image don't always map one to one.  Walls blocking sound only matters for the closest player - I might simplify the calculations due to that.  I'm not sure I could integrate Roll20AM due to the number of pass-through commands necessary to make it work correctly. I could see about incorporating playlists outside of Roll20AM if the concern is multiple tracks played at once. As it is, this isn't set up for one-time sounds as it always assumes a looping track, and "It'sATrap" is probably better for one-time sound encounters.  Fade-out is only there to make it so there aren't abrupt shifts - the time is fixed, the amount is a step-down based on the distance between sound volumes. The fade-out for Dimmerswitch will be configurable on the other hand.  Radius Type: Oh, ok, I think I was confused about what was projected and how it interacts. If walls come in, then radius type doesn't matter. And yes to toggling the radius invisible. There are enough overlays and other things on the map (like Dimmerswitch) that I don't want another aura to be visible unless I select and toggle the token. OK, got you on Roll20AM. If max emitter volume is controllable it's not a huge issue. And I'd forgotten about It's a Trap, will check it out, thanks. On fade-out, I guess it felt abrupt to me when I tried it last night, but again, not a big deal.
1610655537
Pat
Pro
API Scripter
Jay R. said: Radius Type: Oh, ok, I think I was confused about what was projected and how it interacts. If walls come in, then radius type doesn't matter. And yes to toggling the radius invisible. There are enough overlays and other things on the map (like Dimmerswitch) that I don't want another aura to be visible unless I select and toggle the token. OK, got you on Roll20AM. If max emitter volume is controllable it's not a huge issue. And I'd forgotten about It's a Trap, will check it out, thanks. On fade-out, I guess it felt abrupt to me when I tried it last night, but again, not a big deal. Fade-out I think is half a second - I don't know that I'd want to have it on a per-token basis, but I could look at a global fade-to-next-volume setting. Its not as noticeable when  you're moving within the audio field (from volume 30 to volume 40 for example) but is noticeable when you go from 0-100 or 100-0. It's meant to cover all audio transitions for multiple emitters at once, and I didn't want it hanging around forever.