I agree that it would be great, but I also recall watching a keynote by David Zicarelli of Max land, where he said the first version of gen took them 6-7 years to develop (with paid, full-time developers, which we don’t have).
So I suspect that a more realistic alternative is to leverage an existing toolchain, e.g. FAUST or… is there something else? Our own homegrown solution would feel more integrated from the user’s point of view, but I have doubts about its feasibility.
What if SC objects formed a graph and emitted Faust code, and the server could dynamically load plugins based on that? Let Faust do the really hard stuff.
Since some months I am working on some ideas on how to turn/rewrite Baryon into a complete package/project manager for sclang/scsynth, it is the next project that is on my shelf. But I still have to try out some more package managers and talk to some people which also mentioned they have ideas for such a thing. I’ll make a post once its shape becomes a bit more clearer.
Another nice thing about Faust/JSFX/SAPF/whatever is that you can distribute source code instead of binaries, which means you don’t have to solve the numerous problems with distributing binaries, which range from laborious (e.g. cross-architecture builds, including of transitive dependencies) to basically impossible (e.g. verifying non-maliciousness of binaries).
It also makes development much easier for casual SC users. Right now there don’t seem to be enough UGens in development to warrant (imo) the massive undertaking that is a package manager. Hopefully if it’s easier to make UGen-like things, that development could flourish!
Also since this thread is asking for user sentiment, +1 for reblocking/resampling, better FFT workflow, some gen~ alternative (I agree from a user perspective, running into some limitation and having to write a c++ plugin to solve it has always been a downer), and (pipe dream) 64 bit float samples on the server
Curious if anyone thinks there’s a path forward on a 64-bit server. The workarounds I’ve used to index into multi-minute, multi-channel buffers have been fairly ridiculous. Is this just something we’re stuck with for the forseeable future?
Curious if anyone thinks there’s a path forward on a 64-bit server.
Unfortunately, SC uses plain float types for all audio samples, so upgrading to double precision would be quite a bit of work. Not even mentioning the pain to update extensions… But it certainly can be done!
The first step would be to introduce a typedef (e.g. sc_sample) and try to replace all relevant occurances of float in the Server code with that typedef. As long as sc_sample is defined as float you should get the exact same behavior as before. Then you can try to set it to double and start testing. It would be even be possible to ship both the single and double precision build (e.g. scsynth and scsynth64) and users could select the desired precision at runtime. Again, the problems are mostly with externals. (Pd can be built as either single or double precision and externals have separate extensions, e.g. .m_amd64_64 for Windows 64-bit Intel double precision`)
Regarding Buffer playback, we could extend BufRd and BufWr to also take an (optional) offset input. The objects already use doubles internally, so you could index into large buffers without precision issues – and without having to change the actual Server code! (That’s what Pd has been doing with the second inlet of [tabread4~])
Double precision can also be important for recursive filters, but actually most built-in filters in SC already use double precision internally.
However, if you need your whole Synth to be processed in double precision, we would actually need to update the whole Server code…
We have a huge advantage these days, in the form of GH actions. It’s now pretty easy for a developer to clone a template repo with a full automated build setup, start writing their plugin, and get mac+window binaries automatically. I can imagine making actions we can share with the community to update a central package repository for every new tagged build, so the process of getting your plugin published and visible is just a matter of setting a configuration flag somewhere and pushing a tag to the repo. (Obv there are some considerations regarding how we would want to maintain that list, but at least in technical terms this would be a tiny effort to get working).
At the moment you still need a C++ glue layer. One thing that is on my list is making the plugin API a pure C API, i.e. get rid of the C++isms. See Convert server plugin API to C · Issue #6145 · supercollider/supercollider · GitHub. Then someone (not me ) can write pure Rust bindings by translating the C headers to Rust. (I guess this can be automated to some degree.) Then people can write pure Rust plugins. This would also open SC to other languages, like C, Zig or even Fortran
That’s actually what the IEM CI is doing: when I publish a new tag, the Pd externals are automatically uploaded to Deken. (The IEM CI is not available to the general public, though. However, the deken command line tool is pretty easy to use.) Regarding GH Actions: just keep in mind that not everyone is using GitHub…
We should certainly team up with @dscheiba since he has been working on a new package manager I guess we should continue this discussion in a new thread, though.
Although I think that Rust doesn’t give you that much of an advantage over C++ in DSP as Rust has IMO its biggest advantage when managing resources or working async - of which both are not common usecases for DSP.
At the same time you increase the complexity of the build by introducing Rust as a build dependency, which also somehow consumes some GBs on the hard drive.
You could probably already write those w/o any C++ glue code by importing the SCUnit struct using CXX?
Even a bit crazier than JIT compiling would be to include a wasm runtime which would allow us to distribute plugins in an uniform binary format… But building those isn’t fun either and I heard horrible things about including a wasm runtime.
This is indeed a great thing, though I agree with christof to not attach us even more to the GitHub ecosystem and instead provide shell scripts to this which then can be attached to any CI runtime.
If we also want to provide a multi-platform build system we should rely on something which we could evacuate, so e.g. GitLab, …
Uploading those artifacts to an index should be handled via the CLI of a package manager.
Good question. I would be quite suprised if that would work out of the box. Rust is not particularly famous for good C++ interop… Anyway, I think it would be much nicer to have a pure Rust version of the plugin API so you don’t have to worry about that. Also, languages like Zig can directly consume C APIs. Finally, there are some parts of the plugin API that (accidentally) rely on C++ ABIs, e.g. SCFFT_Allocator not ABI compatible · Issue #4438 · supercollider/supercollider · GitHub. No binding generator can overcome such ABI problems.
EDIT: to be clear, the problem are not inline C++ wrappers like SCUnit, but the use of C++ types in the actual API functions because the resulting ABI is not stable across compilers. (We can discuss this further in the linked GitHub issue!)
I have been mainly sharing that because its brand new and gives an impression of whats happening in the current VST landscape. I look at alot of new devices, because i find interesting what other people come up with.
I havent fully investigated the spectral Fx, but at least the two he was sharing in the video sounded cool and i founded the State Variable Filter preset morphing interesting.
I think some of the things from the Fx section will probaly sound way better then possible in SC.
In general i find it crazy that there is a common cliche fx chain where you take high distortion into a stack of multiband compressors, and in SC isnt even an implementation for that.
I think some of the things from the Fx section will probaly sound way better then possible in SC.
Hopefully! Otherwise they wouldn’t be worth the money Obviously, SuperCollider cannot compete with commercial plugin companies. Fortunately, it doesn’t have to, because we can just use all of these awesome plugins inside SC
AFAICS Max/MSP doesn’t have a built-in implementation for that either. I could see the criticism if “csound has it, ChucK has it, Max has it, Pd has it but SC doesn’t have it” but it’s more like… csound and ChucK, I don’t know; Max, build the multiband splitter yourself or use a vst~; Pd, build the multiband splitter and compressors [1] yourself or use a vstplugin~; SC, build the multiband splitter yourself or use a VSTPlugin.
[1] Max has omx.comp~ built-in; SC has Compander, whose sound isn’t ideal but at least it’s there. Pd to my knowledge has no built-in compander at all (though I’m sure there’s an external for it).
I don’t see that SC is far behind the curve on this specific issue.
If the precise question is “how can SC have something like gen~” I think an honest answer is, it’s a very hard engineering push, and realistically I think it could happen only if we have a couple really genius developers who are willing to hack at this in, like, all of their spare time for a few years. I keep referring to JMc’s keynote; it is quite clear about what’s involved in code emission for JIT compilation.
Hadron is a new sclang interpreter – which is very important, if the current sclang codebase ever becomes unmaintainable (nonzero probability there). I’d like to be part of the Hadron testing effort. But, wrt to this thread, it doesn’t touch server or plugins. It could become the basis for new synthesis options, though.
) can write pure Rust bindings by translating the C headers to Rust. (I guess this can be automated to some degree.) Then people can write pure Rust plugins. This would also open SC to other languages, like C, Zig or even Fortran 
I guess we should continue this discussion in a new thread, though.
. A precise question with a lot of side answers coming along… Maybe the future of SC is simply Hadron 
Obviously, SuperCollider cannot compete with commercial plugin companies. Fortunately, it doesn’t have to, because we can just use all of these awesome plugins inside SC 