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

Move block_size KWarg to initialization? #72

Open
pconerly opened this issue Aug 22, 2018 · 1 comment
Open

Move block_size KWarg to initialization? #72

pconerly opened this issue Aug 22, 2018 · 1 comment

Comments

@pconerly
Copy link

I'm browsing through the backends, and it looks kind of inconsistent how we sometimes hand block_size or block_samples to read_data, and sometimes we pass it to the initialization?

Furthermore, def audio_open(path): doesn't take a block_size parameter, so users can't use it unless they use a backend directly.

I think we could improve the lib by adding block_size to audio_open. For the existing backends that have read_data(blocksize=*) we could still allow them to override blocksize on the read_data level. It shouldn't be breaking change if we do it this way.

@pconerly pconerly changed the title Move to block_size KWarg to initialization? Move block_size KWarg to initialization? Aug 22, 2018
@sampsyo
Copy link
Member

sampsyo commented Aug 22, 2018

Yep, this is a good idea too. It’s inconsistent because we didn’t previously consider this part of the “public” (cross-backend) interface. But with some thoughtful consideration, we can totally make it consistent.

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