4 ms·
I'm ashamed to admit I didn't even test this on anything other than the devices and browsers I had open at the moment (Chrome on Mac and on Android). I'll check
by ohadron 9y ago
I'm ashamed to admit I didn't even test this on anything other than the devices and browsers I had open at the moment (Chrome on Mac and on Android). I'll check what's the deal with FF - should probably be easy to fix.
Thanks for the heads up!
- fenomas 9y agoIt's extra surprising to me, because I've been doing some nontrivial procedural Web Audio stuff, and I've also never checked my project in FF, but now that I do I find it sounds identical to Chrome. If you wouldn't mind, please post what the problem was if you figure it out! Edit to add: my best guess is that you need to add a "setValueAtTime" call between these two lines, so that the exponential ramp has a scheduled value to start from. https://gitlab.com/inverted3/drum-machine/blob/master/src/components/Machine.vue#L161-162 https://gitlab.com/inverted3/drum-machine/blob/master/src/co...
- ohadron 9y agoI figured it out - I hope. Your suggestion was a major part of the solution - Chrome works great with just setting osc.gain.value = 1 But for this to work on Safari & FF it needs to be set like this: oscVol.gain.setValueAtTime(1, startTime)
- fenomas 9y agoThat's what I meant, yeah. Ramps in web audio params don't go from the current value to the target value, they're treated as starting from whatever the previously scheduled value was. In this case there wasn't a previously scheduled value, so I guess behavior was undefined and the browsers differed in how they handled it.