-
Notifications
You must be signed in to change notification settings - Fork 146
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
sd.rec: dimensions of returned ndarray #232
Comments
Thanks for the suggestion! It isn't a "minor change", though. This would break a lot of existing code, so there has to be a reeeeeeeeally good reason to make that change.
Thanks, I appreciate that. If you like it, you should consider giving the project a star!
Yeah, I considered this. But I wanted the returned array to have the same shape as the arrays provided within the callback functions.
I'm well aware of this function (because I suggested and implemented it: bastibe/python-soundfile#34) and the
Well why should And it already works perfectly together with >>> import sounddevice as sd
>>> import soundfile as sf
>>> fs = 48000
>>> sf.write('delme.wav', sd.rec(100000, channels=1, samplerate=fs, blocking=True), samplerate=fs) There is no need to specify whether anything is 1D or 2D, isn't there?
Just that something is older doesn't mean more people are using it. I wouldn't make huge breaking changes to either of the three libraries at this point.
It absolutely does. The choice depends on priorities, I guess, and to some part on taste. IMHO, the OTOH, the And there is another argument: ... = sd.rec(..., channels=2, always_2d=False) The result would be always 2D and never 1D, which contradicts You might disagree, but you'll have to come up with an extremely good reason for me to change the default. We can talk about adding an option, though, as long as it isn't a breaking change. |
Thank you for use your time to read this! I gave you a star :) Your words are very reasonable. Some comments.
Yeah, I understand. To be honest, my only reason is this quarantine we are going through, I just came up with this idea and thought "why not...?". Anyway, I don't want to "break a lot of exiting code", maybe I didn't write my suggestion as I meant.
Exactly, this is what I meant, the
Ok, that does look a bit awkward, but I don't know what else could be done to make it look... less awkward? Well, thanks again for the interest. If this addition ("addition" seems to be a better word than "change", so thanks) is really that hard, I will close this issue. I don't want to make any kind of mess with this module, it works really well just the way it is. Maybe I just should get used to handle mono audio in 2D column matrices instead of 1D vectors, and that's it. Regards. |
OK, but would it be really useful then? You might as well use sd.rec(...)[:, 0] ... which is shorter than sd.rec(..., always_2d=False) Or you could do
Well one way would be for the I don't know anything else, but if something comes to your mind, let me know!
It depends on what you mean by "hard". It would be super easy to implement, barely an inconvenience. The question is whether it would be an actual improvement to the API. And that may well be, at least to some extent, a matter of taste.
No need to close this if you still have something to add. I'm open for changes/additions.
Don't worry, we're still just talking.
If you only ever use mono signals, there is no need to "upgrade" them to 2D everywhere. It's just a matter of doing Why are you even using And if you use it that often, why don't you just make your own little wrapper function that returns a 1D array? If you describe your typical workflow, I can probably better understand the problem? |
@fbosio Do you have any further comments/suggestions/answers/questions? If not, I think we can close this issue. |
Sorry, I didn't remember to close it the last time! Edit: actually, the "Close issue" button is not working for me, I wonder why... |
That's strange. I thought you should be able to close it because you created it. Anyway, I can close it right now ... |
Thanks! |
Hi! I'm not reporting a bug, but suggesting a minor change.
First, I have to say that I use
sounddevice
a lot in my projects, and I really like it, so thanks for that. The thing is, therec
function of the module returns anumpy.ndarray
(whenout
isNone
) whoseshape[1]
equals the givenchannels
, but the recorded data has always two dimensions (ndim
is2
). This could be okay, but bothscipy.io.wavfile
andsoundfile
read
functions return a 1Dnumpy
array when loading a one-channel audio file. So, bothand
show
1
. I think that, if one is loading a mono audio,sd.rec
should return a 1D array, like thoseread
functions. Besides, therec
function could take analways_2d
boolean argument, like the one in the read function of the Bastian Bechtold'ssoundfile
library, to let one decide thendim
of the returned array.So why I'm asking here, when I can ask both
scipy
andsoundfile
developers to change their functions to complainsd.rec
? My criterion is simple: those libraries are older, and consequently, there are more people using those than this one for a while. I hope that "sounds" reasonable. Regards.The text was updated successfully, but these errors were encountered: