Open Andreya-Autumn opened 2 months ago
And by the way. Your no-exceptions changes are good and we'd be happy to upstream them if you want.
It would also help if you added the clap libraries as a submodule to the repository.
git submodule update --init --recursive
Had to hack the code with an absolute path to a folder that had clap.h
You shouldn't have to hack the code, just use "Makefile.local". I've added that to the README.
Thanks for your comments. I'll look into adding KBM support.
I have a question for you, actually: looking at my notes from last year, I see that I could build the plugin on one distro and use it on another (if both were glibc-based). But one of my machines has an older version of glibc, and it didn't work there. But Surge did. Are you doing anything special about that in your release build process?
Yes
we have a custom Ubuntu 18 gcc11 docker image and we use that to do all our release builds on Linux
if you look at sst-dockerimages and sst-githubactions repos at surge land or look at the surge or shortcircuit build release yml at head you can see how we put it together
it’s a total pain. Linux is such an unfriendly platform for binary distribution. But it works!
Thanks, that's definitely helpful! I also need to use a newer version of GCC. In my case it's because I won't give up designated initializers, which I find essential for interfacing with a C API like CLAP.
I love Linux, but I don't love GNU....
Yeah the vcv rack guys have a docker image that gives you gcc12 and Ubuntu 16 but that’s harder work since they have to compile the compiler to match the libc. But check out https://github.com/VCVRack/rack-plugin-toolchain
I also love Linux I just wish it existed. There’s so many disparate configurations all with the same name that it’s really difficult to do broad binary support. Luckily we are open source so we can just tell people to build it themselves if they insist on using some crazy distro but our closed source audio brethren have it trickier
Oh you may also want to check out open build service. A team member set up builds of surge there and now we get like 17 binary packages for free in each release and commit
Let me be that person... have you considered MTS-ESP support?
KBM support has been added.
Thanks again for that Dockerfile. I spent some time trying to get Nix to give me a new GCC on a old glibc -- it's exactly the sort of thing Nix is good at. And I did eventually convince it to do it, but not to build a binary that would run outside Nix. The Dockerfile lets me eliminate glibc versioning as a possible issue, but it turns out my real problem is with libstc++ versioning, so it follows GCC. The really annoying thing is that it looks like the only symbol pushing it to the newer version (GLIBCXX_3.4.29) is "std::throw_bad_array_new_length" -- despite the fact that I'm using "--no-exceptions"! "-static-libstdc++" is the workaround for this GCC bug, at a cost in binary size. Or maybe I'll give Clang a try....
Re: MTS-ESP: Another dependency? No thanks.
Yeah the Linux library situation is sooo much worse than macOS and windows for binaries. We ended up like I said making our build environment part of our release notes and also setting up open build service
mts esp is a small dependency (for the client) if you choose to ever reconsider and at this point how a large number of microtonal musicians make tuned ensembles. If you change your mind I’m happy to offer a hand.
Let me know if there’s any way we can help though!
Hey there! Surge synth team member here. Great fun to see that you've used our tuning library! That's what it's for. :)
If I'm seeing correctly, you're not using the .kbm file support. This limits the usefulness of the .scl implementation rather severely. They're really meant to work as a pair. The most common problem is if you load an unequal scale, you'll only be able to play it in one key. Though there are several other issues also.
So I'd encourage you to include that support also! All the functions are there in the tuning lib, and feel free to ask any questions you want!