I think it’s quite interesting to speculate on what supercollider (or something like it) could be on a more permissable licence (say MIT). It’s a shame that students who learn software designed specifically for interactive audio aren’t able to use that software in the largest interactive audio industry (games). I wonder if there is a whole to be filled here?
It’s a shame that students who learn software designed specifically for interactive audio aren’t able to use that software in the largest interactive audio industry (games).
You can, just use Godot 
Godot Asset Library → License
In reality, game dev has its own set of audio engines and authoring tools, so if you want to work professionally, you need to learn and use these anyway. SC can still be used for internal prototyping, though!
But you can’t release the game as closed source if you embedded supercollider, or can you - licences confuse me?
I actually don’t know what other alternatives there are and how they compare 
A while ago I looked at wwise, so this is probably our of date, but it seems quite limited compared to the what you could do with, say, altering patterns based on game state.
You can’t I’d agree that it might be nice if SC was released under a more permissive license (personally, I think LGPL is a decent middleground), but it won’t ever happen.
1 Like
I think GPLv3 would permit a closed-source client to run a separate scsynth process and communicate with it using OSC. If it’s an unmodified scsynth + plugins, it wouldn’t be necessary to publish the source. Any mods would have to release source code.
Linking libscsynth AFAIK wouldn’t be allowed (since that’s one of the key cases for GPL: to prevent closed-source projects from appropriating open-source libraries).
hjh
I’ve already wanted to write this after your previous post: please don’t use an AI to write your forum posts (beyond grammer/spelling fixes)! Nobody wants to read a wall of verbose AI talk.
To address the most important point:
In terms of open-source licensing, we might also consider the case of SuperCollider and its adoption of the MIT license.
You cannot simply change the license, that is the very point of the GPL! The only way to do this is to get the written permission of every contributor. Some major contributors have already said that they would never agree to such relicensing (see for example Commercial licensing (again) - #2 by VIRTUALDOG).
is at least grammarly ok, for the sake of text proof reading? like i said, i want to be a cyborg (or at least an AI agent). but only when it will become safe
Yes, I think that’s definitely ok.
like i said, i want to be a cyborg (or at least an AI agent).
I think your fellow readers prefer if you don’t…
On a more serious note: please don’t spam this forum with AI generated content.
2 Likes
Incidentally (or, crucially), this isn’t just a matter of opinion – it’s a clause in the forum Terms of Service:
By making Content available, you represent and warrant that: … the Content is not spam, is not machine- or randomly-generated…
Accordingly I’ll flag and remove a couple of posts in this thread.
Grammarly isn’t en-masse generation of large blocks of unreliable material – machine correction of human-written text is fine.
hjh
1 Like
I would imagine language translation (if/when it is good) would be acceptable too?
As a sound designer working in the game industry I would love to see Supercollider integrated within the game audio workflow but as mentioned previously by @jordan is at the moment impossible due to licenses. While ago I’ve tried to authoring my own plugins for Wwise converting PureData patches into C++ code using the Havoc compiler. It was very fun and powerfull but eventually we couldn’t use it because licences 
I wonder if things are different with Godot, could we potentially use SC within its engine? They’ve recently released a Wwise integration for Godot.
Godot is licenced under MIT, SC under GPL2 and GPL3. According to this, they are compatible.
The MIT License is highly compatible with other permissive licenses. Including the BSD family of licenses. It is generally compatible with GNU GPL group of licenses. However if you distribute the code that contains or is derivative of GNU GPL code the final project must of GPL compliant. In other words any source code must of publicly available.
1 Like
That’s great!
I’m very ignorant about this topic how hard would it be to give Godot the the access to scsynth?
Not difficult at all, depending on your needs.
I’ve used Godot to control SC/SonicPi in the past. Since Godot can send OSC messages, the easy setup is to launch SC with Godot when the project starts (piping through shell), then to send OSC messages with Godot when needed to control synths, or to trigger larger events (possibly using sclang to do so). This comes at the cost of a small latency (OSC needs to travel through network), which, depending on your needs, might be acceptable or not.
There are other considerations to take into account depending on the scale of your project. Godot aims to help video games business, it tries to provide a software that is competitive with other commercial softwares, even if licenced under MIT (see the recent game Dome Keeper). Providing a simple executable that includes Godot + SuperCollider and runs out of the box on every OS might be too costly to be envisaged. CPU/RAM management is way simpler when there’s only one program running at once.
As an example, I’ve seen in the Godot documentation (I think) that most of the time, video games sound designer do not apply reverb to their sound before exporting them, because reverb increases sound file length dramatically. Instead, they provide ‘dry’ sound which are played through a single dedicated reverb bus that is running while the game is running.
To give this a better context as far as I understand:
- Already publishing SuperCollider as-is in e.g. e.g. the Apple AppStore is difficult b/c of the GPL, see More about the App Store GPL Enforcement — Free Software Foundation — Working together for free software - IIUC: Apple TOS states you are not allowed to copy anything from the AppStore, which is contrary to the GPLv2. SuperCollider actually uses GPLv3 which changes nuances about this, but there is a consent that this still is not compatible.
- To my understanding: Linking GPL code can only happen in a GPL environment - so if you want to use sclang or scsynth directly within your project/binary, this is only possible if your project is licensed under GPL - this is what copyleft is about.
- GPL only affects when one is linking the program/lib, but scsynth can be used without linking by sending OSC messages to the server - so one could use scsynth from within a non-GPL project. It would be even possible to bundle scsynth with such an application (e.g. during installation), but this is also most likely not feasible due to the first point. If SuperCollider would be licensed under AGPL, this would not be possible.
A bit OT but a really interesting talk as a primer about state of the art sound synthesis in recent game development: https://www.youtube.com/watch?v=N-dPDsLTrTE (starts at around 37:00)
2 Likes
I see your points.
The problem is that using OSC to communicate with SC will imply having SC being opened and running at the same time. That’s not very useful when it comes to build the game and distrubuting through different platforms.
SC should be embedded within the game engine such as Godot or Unity. I remember watching a talk where a developer managed to use SC within Unity through its visual scripting language, something similar to Metasound in Unreal engine.
You can, of course, start scsynth from your game.
SC should be embedded within the game engine such as Godot or Unity.
It depends what you mean by “embedding”. As @dscheiba tried to explain, if you run scsynth as a separate process, that would work, but if you link directly against libscsynth the whole program would need to be licensed under GPLv3. But again, even in the first case you might run into problems with some app stores or SDKs. To give another example, SteamWorks does not accept the GPL: Distributing Open Source Applications on Steam (Steamworks Documentation)
1 Like
I see, it looks like using SC for a game production is at the moment impractical. It’s a pity, it would bring such a huge benefit to the whole game audio community. FMOD and Wwise have both very few DSP and they sound poorly.
Would people be willing to abandon/migrate-from/supplement supercollider for such a new program?
How many benefits/new features/possibilities would a different framework need to be attractive to people?
I doubt this is enough by itself, but it is a shame!
I think the game audio community has shown a growing interest in DSP and real time audio synthesis. Games as Cocoon are definitely going in that direction but building custom tools for FMOD and Wwise involves a deep understing of C++ and DSP which is (most of the times) out of a sound designer expertise.
Metasound is getting a lot of hype but it’s still far from being an audio middleware that is able to handle a whole game development. I think environments such as SC, PD and Max/Msp could fill the gap and make Wwise or FMOD powerful tools and not mere play and stop software. My 5 cents 