Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

I signed it!

CLAs look good, thanks!

Any thoughts on this, @developit?

Hey @martinholters! Sorry about the wait there - I read this but then forgot to come back to the tab. I like the approach and I think this is the right way to move forward. However, I have to wonder - do you think this would be worth pulling out into its own library as an AudioParam polyfill? I could certainly see other polyfills using it.

Cheers!

However, I have to wonder - do you think this would be worth pulling out into its own library as an AudioParam polyfill?

I'm not sure I fully understand, so let me check we're on the same page. It might make sense to pull this into a library which provides a way to construct an AudioParam and then an API call to evaluate its value at a specific time/for a block of samples, basically putting the code now added toscriptProcessor.onaudioprocess into its own function. That might indeed be useful when implementing your own ScriptProcessor. (Although I wouldn't call it a polyfill; that might be part of the reason I'm not sure I understood you correctly.) Do you see other application scenarios?

You described what I meant perfectly, and agreed regarding it not really needing to be a polyfill. Shouldn't block merging based on that goal though, I'll re-review (sorry for the delay!)

Hi @martinholters, I just came across this thread. I recently created a very similar abstraction for my standardized-audio-context package. The little library is called automation-events. It maintains a list of automation events and provides a method to get the value of the hypothetical AudioParam at a certain point in time. Maybe that comes in handy for what you're planning to do.