Maybe a start to this would be to simply figure out which universities use SuperCollider as part of their curriculum?
A few (apologies if wrong or out of date) @elifieldsteel is at UICU I think - @muellmusik University of Birmingham - CCRMAat Stanford. has a workshop right about now (not sure who is teaching!) @dkmayer is at IEM Graz - @madskjeldgaard is at NOTAM DXArts at UW has had a lot of SC stuff through the years FluCoMA comes out of University of Huddersfield I think?David Cottle is associated with University of Utah…
2 Likes
The Institute of Sonology in The Hague (NL) has a SC module too
1 Like
indeed this is true. but UK academia definitely doesn’t give anyone any overhead to even do the actual job we’re supposed to do (don’t get me started) so until I find one of those fat unicorn chairs somewhere else, if they still exist, then expect the odd bug report from yours truly 
and a bit of money to help this site to survive, obviously.
@Sam_Pluta is at Peabody and teaches it. He and @tedmoore (and a bit of @groma too) are responsible for my late conversion from other platforms I won’t name…
FYI: I’m no longer at NOTAM
Very interesting recent comments here. A few thoughts:
While there are usually strong arguments for and against any given language design choice, and it is true that SC has become more of a hybrid/compromise as time has gone on, I am not sure that some particular set of ‘good design’ is really what makes a language successful. C++ is a horrible language in many people’s opinions (okay perhaps a little less horrible than it used to be, but still…) but remains immensely popular and widely used, even with numerous better designed alternatives available.
I think SC’s strengths are a mix of things, but realtime safety, powerful built-in domain-specific functionality and extensions, and a well established and overall (flame shield on) supportive community. As PA says it works for artists, and that’s the target community or at least the core of it. Many SC users couldn’t care less about hard or soft typing. But Patterns…! It also managed to provide convincing workarounds to some of the traps/pitfalls/shortcomings of the incumbents (Max family/Csound) at an opportune moment in the history of such environments. There was thus a real payoff in learning it. All that snowballed…
Of course if you were designing a new SC from scratch today, you’d do it differently. The available design models, target hardware, possible use cases etc are all different. But that alone won’t make it successful. So I think any future developments should strongly target maintaining those existing strengths, and any big disruptive changes need a big payoff for that core constituency. Otherwise I think they’re unlikely to gain traction, as we’ve seen with many very well intentioned and enthusiastic attempts over the years.
4 Likes
Regarding the idea of a foundation, I think it’s great in principle, but I wonder about the reach of SC. Python can do this because it has a huge user base and wealthy stakeholders.
Without that, I think longevity remains a concern. I would love for the University of Birmingham to host such a thing, and perhaps I could convince them. But what happens when I retire if they don’t replace me with someone equally invested? Institutions sound great for giving these things some permanence, but at the end of the day institutions are people, and with the best will in the world it’s very difficult to maintain such things if there isn’t on the ground individual commitment.
All of which is not to say that couldn’t work, but just to be careful around that issue. A targeted and funded research project (a la Flucoma) with clear aims and a limited timeline could work better at making some big steps forward, though it can be hard to sell the kind of maintenance, reworking, fixing work that FLOSS projects often need to funders looking for exciting projects. But properly pitched this could be very successful, and a much easier lift than a permanent foundation. I’d be very happy to work with people on an application of this sort!
4 Likes
Finally, as it keeps coming up, just some clarification about the mailing lists for those who may not know:
I kept them going for as long as I could, as I know many people preferred them, but in the end institutional decisions made it impractical to continue. As I said at the time, people were naturally welcome to start a new list elsewhere if they wanted, but GDPR meant we could not simply move the archive to a new host.
Someone still can start a list of course (after more than a decade moderating, I thought it would perhaps be better if it was someone else) but I think the forum is a good compromise and I hope it makes most people mostly happy. It too may have longevity and/or ownership issues at some point, but I think the SC community is established and large enough now that it can support multiple fora, and shouldn’t be too dependent on any one’s survival. I admit I’m not as active here as I was on the lists, but that would probably have happened for other reasons anyway, and I’m always encouraged by the health of the discussion I see here.
3 Likes
I now remember that there was this topic about crowdfunding or making a foundation for SC.
I suggest that we keep the discussion about financial resources and support there as much as possible and the topics regarding the language and technical aspects here.
I also remember a long thread in the list about Csound vs SuperCollider from 2011:
https://listarc.cal.bham.ac.uk/lists/sc-users-2011/msg02581.html
Reading it again made me happy with how much SC has evolved (IDE, windows compatibility, NRT, bug fixes, midi and serial support, etc etc). But the topic about fund raising was still a problem there and no proper solution came out of it…
So true !
Totally agree with that. Flucoma is one example, Christof Ressi’s vst plugins are another one – e.g. see [vstplugin~] – A Pd external for hosting VST plugins | Revista Vórtex for the history.
1 Like
Another important consideration:
Should SC 4 retire SCIDE?
1 Like
I use SCNvim and love it but for now the IDE is necessary for new non-coder users. I could imagine the LSP work that @scztt is working on (building on the parser that @lnihlen wrote) eventually making the IDE unnecessary but I expect that’s a while off (if ever!)
1 Like
I don’t think that SCIDE is an amazing IDE, but I do think that it is great and do its job pretty well. Is it costly to maintain? I can’t say.
But based on this:
I assume that removing the IDE will block several artists from accessing SC. I’ve attended to the previous International Live Coding Conference (ICLC) and I was impressed with how big the scene is, also impressed that around 10% of the people were using sclang, scide and scsynth together as their main live coding platform (which is easy to understand).
If SCIDE could also ship tidal natively I think that the SC community would grow more faster, but I understand the amount of work necessary plus the coordination with tidal…
Moreover, adopting some general IDE as the main substitute for SCIDE, I assume it is also problematic. Several projects relied on Atom as their base IDE (including Tidal) and suddenly Atom was over… + the problem of installation: SCIDE is also great because it is super easy to install, a great entry point. + the difficulties of customizing a general IDE for having a docked help, server meter, run all the shortcuts, etc…
IMO, having a personal IDE is not waste of resources. If this was not the case, big environments like Matlab, Python, Processing, Latex, would never have done so…
Scide should not be understood as an “IDE” (those things do all sorts of things in the backgrounds, it’s scary sometimes), but as an efficient lightweight text editor. It does its job. It was worse before it.
If someone wants to improve SC in emacs and vscode, it’s not a problema, it would be good too.
Why not just work on the emacs or vscode plugins and make it so good everyone will forget this lightweight text editor?
1 Like
Exactly this.
Think of Racket, J, APL (the first 3 that came to mind) etc… without the IDE’s that comes with them i would never even bothered to try them out. Coming from a background in textile arts rather than computer science, I would never ever tried it. Getting a decent workflow with vim or emacs would have been too much work. Maybe I am not alone in this.
(Then again my first encounters with supercollider was on MacOS 9)
I find it important to be able to try stuff out right away, no matter the language, without having to invest hours of setting it up in order to just run “Hello world!”.postln; or a play{SinOsc.ar}; …
FWIW, if a better, one-click-just-working-out-of-the-box-for_everyone_solution would ship with sc i would be happy to jump ship.
i will let myself out now.
lukiss.
1 Like
Take the following message as a personal opinion about SCIDE and not as a blunt criticism of it. I like SCIDE.
I taught SC for undergrads in France last year. I recognize the value or SCIDE to the point that I were expecting students to dive into the embedded documentation head first as a source of knowledge for assignments.
To put it bluntly, it was probably the biggest mistake I made teaching that class. If you are not already a dev and not a fluent english speaker, teaching SCIDE is already two hours of work if students are really fully commited to the exercise (which is rarely the case). It adds complexity and expects users to already partly know what they are supposed to learn. How to find information about classes (they don’t know what a class or a method is), how the library is structured, what a server is, etc…
Teaching Python is usually made using whatever editor imposed by univ staff and bespoke class material. This is also a valid strategy to Iower the entry cost into an ecosystem. If the tool is good, people will not fly away seeking something else.
It’s very low cost to maintain now, but this is effectively a “frozen” state - it’s not getting new features, and is built on top of more or less deprecated Qt technology that will go away in the future. For the IDE to be actively maintained / for it to not be facing extinction, it would require ~4-6 months for probably 2 developers to rebuild it in QML, or another using another UI framework like Flutter or Electron. This would also mean adding another language (QML/Flutter/Java/Typescript) to the codebase and some potentially heavyweight dependencies (Java VM, Electron) - increased maintenance means fewer features go into SC as a whole. All of this is an extraordinarily large cost - it’s worth balancing this against what else we could do with that time.
it would require ~4-6 months for probably 2 developers to rebuild it in QML
Personally, I don’t think that Qt Widgets will go away anytime soon. But if you’re really concerned about Qt Widgets, what about sclang? Porting the whole sclang GUI from Qt Widgets to QML (or something else) would require even more effort…