Has anybody in the open source audio work considered the possibility that at any moment, PACE, the new owner of JUCE, could pull the rug on that project and seriously fragment the FOSS ecosystem?
@paul its crossed my mind. I believe one version of it is gpl3 but should they pull the plug, plugin developers will have to choose between open sourcing their products (to comply with gpl) or reimplementing. I can't imagine that would be a wise move (to pull the plug) but it is PACE we are talking about.
@xinniw Another direction is they could close source it or add enough proprietary components to it to cripple the functionality of the core project.
People say it can't be done with the GPL, but with a corporate owned project and enough lawyers, they could find a loophole.
Muse Group and Audacity has changed my outlook on what's possible here.
@xinniw The solution here is to be a good programmer and code in an escape hatch into your plugin.
If there's no way your plugin could exist without JUCE, did you really even make a plugin to begin with?
The trouble with JUCE is it has an overreaching scope. It's not just a wrapper for plugin architectures, but it also has lots of GUI and DSP components as well.
@paul great point. I sort of accidentally did this with a plugin I built earlier this year. I wanted to learn the DSP from scratch so I did all the important stuff off to the side in my own library that had no idea juce existed. If I have to, I could throw the ui away (which is juce) and still have all of my synth code untouched by the refactor. I think I'll do this all the time now, if I even use juce for the next one.
@xinniw Also make sure you have things set up so you can offline render your DSP code to a WAV file without any threading. I never see anyone mention this at all, but I can't tell you how useful it has been for me over the years. Just being able to pop a simple CLI C program with determinant behavior into Valgrind or GDB is a great thing to have in your back pocket.
@paul that's a great idea! GDB saved my butt once or twice but running it on the compiled plug in was tricky to set up. In theory, I should be able to make a CLI version as all the DSP logic is made of referentially transparent calls.
@xinniw oh yeah. I've never found shared objects and dynamically loaded code easy to debug or deal with. I've given up trying to make plugins, mine or otherwise, work. It was making me too grumpy. Now I just statically link everything into a single binary.
@xinniw since we're talking about plugins, I thought I'd mention the strategy I use in my music software ecosystems to get plugins using static linking.
the design pattern I use is to create a pseudo main function that takes in a loader callback. I can then build and link a new version of this program.
For example, here is Gest, my gesture sequencer, being loaded as a "plugin" inside of sndkit + LIL (the tiny scripting language that I use with sndkit):
@paul I wouldn't call something dual licensed FOSS. If you can't contribute to something under the same terms as you receive it, that's not a free/open source project, even if it's a free/open source license.
Welcome to post.lurk.org, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that.