Make NumPy optional
Closed this issue · 4 comments
Don't get me wrong, I really like NumPy and I'll probably use it all the time.
But I think it would make PySoundCard more useful to a larger group of people if there was also a way to use it without importing NumPy.
Maybe there are people who don't like NumPy, maybe they have a better library for their needs, maybe NumPy crashes, maybe NumPy isn't implemented on their Python implementation (but CFFI is), ...
I think it would be good to have a "raw" version of NumPy that doesn't even import NumPy. It would just pass around plain Python buffer objects (and/or CFFI pointers). The current API with NumPy could then be implemented on top of the "raw" API.
Maybe this should be a submodule (like from pysoundcard.raw import Stream) or maybe there could be separate classes Stream and RawStream ...
I don't have a very concrete idea how this should look like in detail, but I think it is a good idea in general.
Interesting idea. Initially, read() would read raw data if you wanted it to, and write() would accept it. I never used it.
The tagline says "PySoundFile is an audio library based on libsndfile, CFFI, and NumPy". The reason I built PySoundFile was that most modules out there only worked on raw data, and raw data is so very useless for any kind of signal processing.
Thus, this is not something I am interested in. Other modules are already doing it and I see no value in it. I'd be happy to merge it if someone else were to implement it in a way that does not interfere with the rest of PySoundFile though.
The tagline says "PySoundFile is an audio library based on libsndfile, CFFI, and NumPy".
I wouldn't worry about that, NumPy would still be used in a very large part of the code, there would just be one part (e.g. the submodule pysoundcard.raw which could be used without NumPy installed).
Of course there are other modules which work on raw buffers, but that doesn't mean PySoundCard shouldn't also supply such an interface.
And I guess the other modules don't use CFFI, or do they?
I think there would actually be a group of users for whom this would be useful.
But anyway, there is another aspect why I want to discuss submodules ...
I would like to have a higher-level interface and I don't know if you want it to clutter the main module namespace.
So probably this could be done in a submodule ...
I created a new issue for discussing this: #19
I still don't see the value in supporting raw data. But go ahead if you want to implement it.
Just for the record, I implemented this in https://github.com/spatialaudio/python-sounddevice/.
It still remains to be seen if anybody ever needs this ...