You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
pconerly
changed the title
Move to block_size KWarg to initialization?
Move block_size KWarg to initialization?
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.
I'm browsing through the backends, and it looks kind of inconsistent how we sometimes hand
block_size
orblock_samples
toread_data
, and sometimes we pass it to the initialization?Furthermore,
def audio_open(path):
doesn't take ablock_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
toaudio_open
. For the existing backends that haveread_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.The text was updated successfully, but these errors were encountered: