added feature of manually setting "BUFFERSIZE" in amplitude analysis

[endurance21]

solves #417

not only feature is added but also example have been updated !

areas of impact
examples/amplitude_analysis/sketch.js
lib/p5.sound.js
lib/p5.sound.js.map
lib/p5.sound.min.js
lib/p5.sound.min.js.map
src/amplitude.js

[endurance21]

hey @therewasaguy !
after exploring a lot and playing around with P5.js-sound library , i pointed out a new feature and
have tried to implement the same!
please have a look!
thanks!

[therewasaguy]

Thanks for the PR!

As far as new features go, a key decision from the recent p5 Contributors Conference is that "p5.js will not add any new features except those that increase access" (more here)

So let's keep in mind that as p5 contributors. New features add complexity and we should focus on making the existing features as stable and accessible as can be.

That said, if this new feature came with a unit test, that would help :)

[endurance21]

@therewasaguy
It must be power of 2, thank you for pointing out 😅. I will be correcting it.
more accurately
" Its value can be a power of 2 value in the range 256–16384. " , source MDN /web Audio Api

[therewasaguy]

looks like this comment should be updated to read "power of 2"

[endurance21]

ya ofcourse !!

[therewasaguy]

the comment above this line should be deleted or updated. I'm curious if you considered the other options mentioned in the comment?

[endurance21]

@therewasaguy
actually comment must be modified 😄
and
as far as inheritance part is concerned i think , i need to modify p5.sound pass a optional argument "bufferSize " like i did in here , but right now let's leave it and i will make it another pr !
what do you say ?

[therewasaguy]

it's a good practice to use triple equals so that we check for type as well

[endurance21]

actually i have modified it in my local repo , i will be pushing it with your recommendations keeping in mind 😃

[endurance21]

@therewasaguy
I have read the w3 specs about web audio api and here is what i get
The bufferSize parameter determines the buffer size in units of sample-frames. If it's not passed in, or if the value is 0, then the implementation will choose the best buffer size for the given environment, which will be constant power of 2 throughout the lifetime of the node. Otherwise if the author explicitly specifies the bufferSize, it must be one of the following values: 256, 512, 1024, 2048, 4096, 8192, 16384. This value controls how frequently the audioprocess event is dispatched and how many sample-frames need to be processed each call. Lower values for bufferSize will result in a lower (better) latency. Higher values will be necessary to avoid audio breakup and glitches. It is recommended for authors to not specify this buffer size and allow the implementation to pick a good buffer size to balance between latency and audio quality
But i think p5 user barely cares about how frequently onaudioprocess task is dispatched and
Neither i find any glitches with or without setting bufferSize
Thus keeping present requirement in mind, i think we should be more focused on building our library more robust with documentations and caring more about our current api's.
(as you said)

[therewasaguy]

hey @endurance21, I've added a card for this to our GSoC backlog. It would need resolving of merge conflicts and the changes mentioned above, but before doing that...it sounds like we're on the same page that this feature isn't as much of a priority right now. How do you feel about closing this so that we can focus?