Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for buffer overlap? #50

Open
johnellmore opened this issue Dec 12, 2017 · 1 comment
Open

Support for buffer overlap? #50

johnellmore opened this issue Dec 12, 2017 · 1 comment

Comments

@johnellmore
Copy link

I'm loving Beethoven. Great library.

Currently, the pitch engine processes the incoming audio stream in consecutive, separate buffers. There's no overlap in the data between buffers. So for a 44.1kHz input stream and a standard 4096 sample size, the engine returns about ten results per second to the delegate.

I'd like to see support for buffers with overlapping samples. For example, I could specify a sample size of 4096 but an overlap of 2048 samples. Then the pitch engine would pass overlapping windows of audio data to the estimator. In this example, the estimator would end up doing twice as much work, but it would return twice as many results per second with full accuracy.

A basic implementation of this could be done entirely in the existing PitchEngine class, without altering the interface used by the Estimator. A more advanced implementation could be done down the road using algorithms better suited for real-time audio processing (i.e. adding incremental data without reprocessing the whole window).

Would this kind of feature be welcomed in this project? If so, I could write this real quick and submit a pull request.

@vadymmarkov
Copy link
Owner

vadymmarkov commented Dec 12, 2017

Hi @johnellmore and thanks for your feedback. I think it could be a great feature and yes, it's welcomed as well as any kind of contribution 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants