Resuscitate Freesound?

[emlyn]

This is just #2360 rebased onto the ~~new main~~ dev branch. I've copied the description and my comments below.

---

I was poking around the Freesound API, and realised it should be possible to make it work again in Sonic Pi.

I reverted the commits that removed Freesound support, and then modified the downloading code to use the v2 API to get the sample information. In that info there are links to the previews, so I download the high quality .ogg preview. This is all done with just an API token for authentication.

To show how/that it works, I made a quick screen cast that shows it downloading and caching a sample on the first run, then playing it once it's cached.

There are a number of remaining issues to be ironed out, but I think there's enough here to prove that it can be made to work. The things I see that need to be sorted out are:

• The API (in Sonic Pi) needs rethinking. You used to be able to pass an integer to sample to play the freesound sample with that ID, but integers now have a different meaning, so you have to use sample freesound_path(1234), which is a bit verbose. Maybe it should just be renamed freesound (and we do away with the current freesound function)?
• For simplicity, I just made it download the (high quality) ogg preview, but I think it would be possible to download the original sample when it is in a supported format (wav or flac). However it would then need some way to keep track of which format a particular sample is in so it knows what the cached sample file is called (or it could look for nnn.wav, nnn.flac and nnn.ogg and use the first one it finds?)
• I added a use_freesound_token function to set the token to authenticate with freesound because the terms of use don't allow publishing the tokens. Users could sign up for a token and set it in their init.rb file. But there could also be a default token compiled into release binaries, as long as it's not easily accessible by users that would be allowed (see here).
• It should really use https, but that didn't work. I think it just needs the openssl gem to be added but I wasn't sure how to do that.

@samaaron what are your thoughts on this?

---

I realised that since Ruby is not compiled, you can't really hide an API token in the release binary, so it might not be so easy to comply with the Freesound API terms. I guess it might be OK if the downloading is moved into a separate (compiled) binary that is called from the Ruby code?

---

@samaaron is this something that you would want back in Sonic Pi? I seem to remember reading that it was originally removed because the Freesound API changed so that token auth was no longer possible (but I don't remember where I saw that, so maybe I'm misremembering), and that now seems to no longer be the case. From my reading it seems that as long as the token is not visible in cleartext it should comply with the Freesound terms. That means that the component that actually builds the url and does the download would have to be moved to a compiled language, with Sonic Pi's Freesound token injected at build time. If I implement something like that, would this be acceptable to merge into Sonic Pi?

[lilyinstarlight]

Just a quick note about the requirement to prevent the token from being visible in cleartext, Ardour just released version 7.0 and has the token in their source code (and I mean even in a compiled language it'll usually still be plain text, just somewhere within the binary)

Ref: https://github.com/Ardour/ardour/commit/9fe0a4f4#diff-fe5be98b9f63b941e3f44fc26c56ae18a69f30a51f7672d49001f2c200660a6eR73-R74

[emlyn]

@lilyinstarlight that's good to know, I guess Freesound are not too strict with enforcing the terms. In that case maybe it would be fine even keeping the token in the Ruby source code.