--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
That is a fantastic demo and visualization, Ray! The legend says that yellow and blue should be Orig Mag and Phase, but those don't show up in the graph. What I was trying to see is how big the difference would be. Do you know what the very worst case in terms of audible change to existing usage of BiquadFilterNode?
As for what merits going through the intents process and not, I think that if this is sufficiently unlikely to be noticed by any user or require any change to code in the wild, then it's in the "trivial" bucket. You're in the best position to make that judgment, though.
Needless to say, it's important that there's some agreement between implementors in https://github.com/WebAudio/web-audio-api/issues/771 before going ahead so that we don't end up with both the old and the new models in various browsers for a long time. If the difference is ever large enough so that a developer would want to code against both models, then some means for feature detection would be needed too.
Agreed. Obviously a lot of bug fixes can be "user visible" and occasionally even "require change to code in the wild" to some extent, but it would be crazy to add the intent process to most bug fixes. So it's a little grey.
Another good rule of thumb is "would we want to update the MDN docs to reflect this change" (or otherwise communicate it to developers proactively). If so it's probably worth having the intent discussion (or at least starting a thread on blink-dev like this one to discuss the specifics).
On Wed, Apr 27, 2016 at 7:41 AM, Philip Jägenstedt <phi...@opera.com> wrote:That is a fantastic demo and visualization, Ray! The legend says that yellow and blue should be Orig Mag and Phase, but those don't show up in the graph. What I was trying to see is how big the difference would be. Do you know what the very worst case in terms of audible change to existing usage of BiquadFilterNode?Oh. Try setting Q to a small value like 0. You'll see four curves. For higher values of Q, the magnitude and phase curves for the two filters overlap. For these small values, the differences between the filters are easily audible, even for my poor ears.I don't have a good feel for what the change will be existing usage. I'm guessing that most usages of lowpass and highpass filters either just use the default or Q was "randomly" changed until it sounded right.
On Wed, Apr 27, 2016 at 7:41 AM, Philip Jägenstedt <phi...@opera.com> wrote:That is a fantastic demo and visualization, Ray! The legend says that yellow and blue should be Orig Mag and Phase, but those don't show up in the graph. What I was trying to see is how big the difference would be. Do you know what the very worst case in terms of audible change to existing usage of BiquadFilterNode?Oh. Try setting Q to a small value like 0. You'll see four curves. For higher values of Q, the magnitude and phase curves for the two filters overlap. For these small values, the differences between the filters are easily audible, even for my poor ears.I don't have a good feel for what the change will be existing usage. I'm guessing that most usages of lowpass and highpass filters either just use the default or Q was "randomly" changed until it sounded right.
On Wed, Apr 27, 2016 at 11:38 AM, Raymond Toy <rt...@google.com> wrote:On Wed, Apr 27, 2016 at 7:41 AM, Philip Jägenstedt <phi...@opera.com> wrote:That is a fantastic demo and visualization, Ray! The legend says that yellow and blue should be Orig Mag and Phase, but those don't show up in the graph. What I was trying to see is how big the difference would be. Do you know what the very worst case in terms of audible change to existing usage of BiquadFilterNode?Oh. Try setting Q to a small value like 0. You'll see four curves. For higher values of Q, the magnitude and phase curves for the two filters overlap. For these small values, the differences between the filters are easily audible, even for my poor ears.I don't have a good feel for what the change will be existing usage. I'm guessing that most usages of lowpass and highpass filters either just use the default or Q was "randomly" changed until it sounded right.If you are worried (I have no idea whether you ought to be), you could add a histogram for the values of Q that are used in practice, and (assuming the change to do so isn't too intrusive) request a cherry-pick to beta.
Philip
On Wed, Apr 27, 2016 at 8:46 AM, Jeremy Roman <jbr...@chromium.org> wrote:On Wed, Apr 27, 2016 at 11:38 AM, Raymond Toy <rt...@google.com> wrote:On Wed, Apr 27, 2016 at 7:41 AM, Philip Jägenstedt <phi...@opera.com> wrote:That is a fantastic demo and visualization, Ray! The legend says that yellow and blue should be Orig Mag and Phase, but those don't show up in the graph. What I was trying to see is how big the difference would be. Do you know what the very worst case in terms of audible change to existing usage of BiquadFilterNode?Oh. Try setting Q to a small value like 0. You'll see four curves. For higher values of Q, the magnitude and phase curves for the two filters overlap. For these small values, the differences between the filters are easily audible, even for my poor ears.I don't have a good feel for what the change will be existing usage. I'm guessing that most usages of lowpass and highpass filters either just use the default or Q was "randomly" changed until it sounded right.If you are worried (I have no idea whether you ought to be), you could add a histogram for the values of Q that are used in practice, and (assuming the change to do so isn't too intrusive) request a cherry-pick to beta.An interesting idea! Do you have a pointer to how to do this (or a simple CL)? Delaying the change makes the pain greater, but we should measure this.
On Thu, Apr 28, 2016 at 12:33 PM, Raymond Toy <rt...@google.com> wrote:On Wed, Apr 27, 2016 at 8:46 AM, Jeremy Roman <jbr...@chromium.org> wrote:On Wed, Apr 27, 2016 at 11:38 AM, Raymond Toy <rt...@google.com> wrote:On Wed, Apr 27, 2016 at 7:41 AM, Philip Jägenstedt <phi...@opera.com> wrote:That is a fantastic demo and visualization, Ray! The legend says that yellow and blue should be Orig Mag and Phase, but those don't show up in the graph. What I was trying to see is how big the difference would be. Do you know what the very worst case in terms of audible change to existing usage of BiquadFilterNode?Oh. Try setting Q to a small value like 0. You'll see four curves. For higher values of Q, the magnitude and phase curves for the two filters overlap. For these small values, the differences between the filters are easily audible, even for my poor ears.I don't have a good feel for what the change will be existing usage. I'm guessing that most usages of lowpass and highpass filters either just use the default or Q was "randomly" changed until it sounded right.If you are worried (I have no idea whether you ought to be), you could add a histogram for the values of Q that are used in practice, and (assuming the change to do so isn't too intrusive) request a cherry-pick to beta.An interesting idea! Do you have a pointer to how to do this (or a simple CL)? Delaying the change makes the pain greater, but we should measure this.(I'm sure there's a better guide to this somewhere, but for the life of me I can't find it right now.)I don't know the audio code well enough to know where the right place to record a sample is, but have a look at base/metrics/histogram.h (but if the code in question is in Blink, use Source/platform/Histogram.h instead). Roughly, you wind up putting in code like this (giving a Blink example here):// sample is an int32_t (if your sample is a float, you may have to scale it so that the interesting range of values fits)DEFINE_STATIC_LOCAL(CustomCountHistogram, qHistogram, ("WebAudio.HighPassFilter.Q", minValue, maxValue, numberOfBuckets));qHistogram.count(sample);You then add a corresponding entry to tools/metrics/histograms/histograms.xml, and send those changes together as one CL.
On Thu, Apr 28, 2016 at 4:00 PM, Jeremy Roman <jbr...@chromium.org> wrote:On Thu, Apr 28, 2016 at 12:33 PM, Raymond Toy <rt...@google.com> wrote:On Wed, Apr 27, 2016 at 8:46 AM, Jeremy Roman <jbr...@chromium.org> wrote:On Wed, Apr 27, 2016 at 11:38 AM, Raymond Toy <rt...@google.com> wrote:On Wed, Apr 27, 2016 at 7:41 AM, Philip Jägenstedt <phi...@opera.com> wrote:That is a fantastic demo and visualization, Ray! The legend says that yellow and blue should be Orig Mag and Phase, but those don't show up in the graph. What I was trying to see is how big the difference would be. Do you know what the very worst case in terms of audible change to existing usage of BiquadFilterNode?Oh. Try setting Q to a small value like 0. You'll see four curves. For higher values of Q, the magnitude and phase curves for the two filters overlap. For these small values, the differences between the filters are easily audible, even for my poor ears.I don't have a good feel for what the change will be existing usage. I'm guessing that most usages of lowpass and highpass filters either just use the default or Q was "randomly" changed until it sounded right.If you are worried (I have no idea whether you ought to be), you could add a histogram for the values of Q that are used in practice, and (assuming the change to do so isn't too intrusive) request a cherry-pick to beta.An interesting idea! Do you have a pointer to how to do this (or a simple CL)? Delaying the change makes the pain greater, but we should measure this.(I'm sure there's a better guide to this somewhere, but for the life of me I can't find it right now.)I don't know the audio code well enough to know where the right place to record a sample is, but have a look at base/metrics/histogram.h (but if the code in question is in Blink, use Source/platform/Histogram.h instead). Roughly, you wind up putting in code like this (giving a Blink example here):// sample is an int32_t (if your sample is a float, you may have to scale it so that the interesting range of values fits)DEFINE_STATIC_LOCAL(CustomCountHistogram, qHistogram, ("WebAudio.HighPassFilter.Q", minValue, maxValue, numberOfBuckets));qHistogram.count(sample);You then add a corresponding entry to tools/metrics/histograms/histograms.xml, and send those changes together as one CL.Is there already a UseCounter for this API? If not you should add one too - that way we can tell both how common the API usage is, and of that what fraction would be impacted.
On Thu, Apr 28, 2016 at 12:33 PM, Raymond Toy <rt...@google.com> wrote:On Wed, Apr 27, 2016 at 8:46 AM, Jeremy Roman <jbr...@chromium.org> wrote:On Wed, Apr 27, 2016 at 11:38 AM, Raymond Toy <rt...@google.com> wrote:On Wed, Apr 27, 2016 at 7:41 AM, Philip Jägenstedt <phi...@opera.com> wrote:That is a fantastic demo and visualization, Ray! The legend says that yellow and blue should be Orig Mag and Phase, but those don't show up in the graph. What I was trying to see is how big the difference would be. Do you know what the very worst case in terms of audible change to existing usage of BiquadFilterNode?Oh. Try setting Q to a small value like 0. You'll see four curves. For higher values of Q, the magnitude and phase curves for the two filters overlap. For these small values, the differences between the filters are easily audible, even for my poor ears.I don't have a good feel for what the change will be existing usage. I'm guessing that most usages of lowpass and highpass filters either just use the default or Q was "randomly" changed until it sounded right.If you are worried (I have no idea whether you ought to be), you could add a histogram for the values of Q that are used in practice, and (assuming the change to do so isn't too intrusive) request a cherry-pick to beta.An interesting idea! Do you have a pointer to how to do this (or a simple CL)? Delaying the change makes the pain greater, but we should measure this.(I'm sure there's a better guide to this somewhere, but for the life of me I can't find it right now.)I don't know the audio code well enough to know where the right place to record a sample is, but have a look at base/metrics/histogram.h (but if the code in question is in Blink, use Source/platform/Histogram.h instead). Roughly, you wind up putting in code like this (giving a Blink example here):// sample is an int32_t (if your sample is a float, you may have to scale it so that the interesting range of values fits)DEFINE_STATIC_LOCAL(CustomCountHistogram, qHistogram, ("WebAudio.HighPassFilter.Q", minValue, maxValue, numberOfBuckets));qHistogram.count(sample);You then add a corresponding entry to tools/metrics/histograms/histograms.xml, and send those changes together as one CL.