3 comments

[ 2.9 ms ] story [ 20.8 ms ] thread
Spotify’s varied and extensive contributions to open source make the company so much more valuable to me. The service is great but what differentiates it for me (from the likes of Pandora or Apple Music) is their community engagement via open source. I really appreciate companies that do this despite any drama that may surround the company. It’s like I view their engineering arm as a whole separate entity. This may be bad on my part, because the means doesn’t justify the ends etc, but it is the reality for me (one I probably should wrestle with more).
In another vein - my initial perception of the oss that these companies provide is that it is high quality. Keep in mind this is before I even vet the code. I have this correlation in my head that code from successful companies that is exposed as open source is high quality. This is also probably a bad idea. While it wouldn’t make sense to expose bad quality code as open source for the bad PR it could generate, I imagine that won’t stop a company from doing it or even ensuring people like myself actually thoroughly reviewing the code before adopting it in some POC. I guess in other words the bar of scrutiny is much lower for code that comes from a recognized company. This has got to be bad - I’m in need of changing that about myself.
Wow, didn't expect this to hit HN! I'm the author of this project and super glad that it's getting some traction.

Under the hood, this is essentially a Python wrapper around JUCE (https://juce.com), a comprehensive C++ library for building audio applications. We at Spotify needed a library that could load VSTs and process audio extremely quickly for machine learning research, but all of the popular solutions we found either shelled out to command line tools like sox/ffmpeg, or had non-thread-safe bindings to C libraries. Pedalboard was built for speed and stability first, but turned out to be useful in a lot of other contexts as well.