My 2cents:
I spent a lot of time on sc by writing uGens, making music, and writing sc code. While I personally disagree that it’s a niche language and would like to see it survive and improve, an integration within python (as someone suggested) - in my opinion - should point more on shared memory rather than (as currently) osc control or total change of language paradigm (python as somebody proposed). Secondly, what I would ~really really~ like to have is the possibility of not having to compile ugens against the whole source code, an approach similar to gen~. Maybe a mechanic like synthdef, where the ugendef is written (preferably in c++) and sent to the server. That would make it easier in academic contexts both for teaching (a “soft” approach for students to c++ and low level dsp) and also for research and testing/importing libraries - secondary to this, (maybe a non popular opinion with “the creator”) a full on modern c++ refactoring of the source code would be amazing.
You can have a small CMake project to hack UGens and copy it to the lib folder.
You just will need to restart the language, like we used to do with language classes.
EDIT: but yes, compiling C++ at runtime and sending it to the server would be a breakthrough. Huge stuff.
Thanks smoge. Yes, I already have the cmake hack, the issue i was pointing to is, as you said, not having to restart the whole thing. I was planning (still am) on looking into it on a fork but it’s on hold for the forseable future because of other work.
If you have the skills, that would be something. Hope you find the time!
I’d say i do have the skills (wrote a new audio engine+node style audio processors for a light console company), maybe i will try to apply to some eu funds (similar to flucoma ones) after my current research grant has ended, time will tell, the will is stong 
That would be the main enhancement, or do you have a plan with more redesign?
(There are so many possibilities in the air…)
I had sone ideas of a pre-synthesis stage for synthdefs on the server, where you could declare osc tx/rx, before your func instead/complementing the || args. But that idea came out of a specific workflow(ping pong-ing buffers filled with 0/1 trigs and info for sequencing, i don’t like patterns) i’m using so maybe wouldn’t be so useful.
UGens, Plugins, and SynthDefs, could all be just C++ compiled at runtime. Why not
Yes, it might sound as an unpopular opinion seeing the previous thread posts, but c++ and sclang should be here to stay!
interesting unpopular opinion > boring popular opinion
So people don’t see Chuck as a alternative for sclang/scsynth apparently? I rarely see it mentioned.
It can be used via the web ide and it has a plugin for visual studio code and nvim (SC has nvim plugin). That would help SC as well.
It has been slower and less supported for 20 years, so I don’t see it as an alternative. It only ever really caught on at Princeton, and once Ge and Perry left, it left with them. It looks like Ge is working on it again, so that’s a good thing. Back in the day it could play like 2 sine waves at a time before it overloaded the cpu. But maybe it is better now?
Sam
Was he the only developer? If I’m not mistaken, in Stanford he was working more time with iPhone apps or something similar. I wonder how challenging is to restart development after 10+ years.
ChucK’s “roll your own rates” looks good in a doctoral thesis, and it natively handles problems like shorter delays with feedback, but I never quite grasped how to run multiple “roll your own rates” in the same shred. Also imagine running a routine (“sporking a shred”) for every polyphonic note. (I think…? Seemed to me this was ChucK’s way of doing concurrency.) I do like the double-dispatch => operator and stole the idea for my work.
Btw, out of SC, Max/MSP, Pd and ChucK, SC is by far the easiest for polyphonic usage (“add a synth, now add another one,” vs “save a patch file with your note player, then poly~ it, and don’t forget that you can’t use regular inlets and outlets here, you have to use special [in] and [out] objects that aren’t used anywhere else, and also don’t forget that it’s 1, mute 0 and not 1, run 1 going to that [thispoly~]” which isn’t germane to SC, just pointing out that in a major, expen$$$ive audio platform, polyphony is awkward but in SC, it’s fully idiomatic).
I never heard whether Ge finally put really good garbage collection in it. In ChucK’s early days, it would leak memory until it crashed, while I can easily run SC for a few hours, no trouble.
Ge, btw, was an undergrad at Duke while I was a grad student. Our paths crossed briefly and it was pretty clear he was going to make it in the field.
hjh
Or wfscollider
Why is there talk of Sc4 when there is so much broken code? There is still two crucial libraries in the quarks
SC4 does not exist. There is SuperCollider Server / SC3, and other people have other ideas. That’s it.
So people don’t see Chuck as a alternative for sclang/scsynth apparently?
CSound is a serious alternative if you want to try something else. The language is kind of unpleasant, but it’s undeniably powerful and can do things that SuperCollider can’t. There are also some good written resources for CSound that teach synthesis/DSP pretty well.
I contemplated using CSound-expression (haskell bindings for CSound), but I was not sure CSound is capable of doing all the things I do with SC in terms of real-time control, the node tree model, etc
The author of csound-expression, a Russian hacker, did some work writing documentation and tutorials, which is not common in the Haskell world. It’s “beginner-friendly”. It would be good for someone trying out DSP (on that level) for the first time, for example.
(I’d be glad to know more what CSound can do today, I’m not really well-informed)
What is this thread about then?
Been many years since I looked at csound. What can it do that SC can’t?