SuperCollider 4: First Thoughts

I don’t think they are necessarily poor imitations. Overtone (the Clojure client) is very different to SuperCollider, and offers a lot of interesting things that SuperCollider doesn’t.

The Common Lisp client leverages what Lisp does well, and so ends up being a more natural fit (e.g. it’s Pattern library is more consistent, livecoding is a better experience and macros make everything more efficient/nicer).

The Haskell client similarly has some nice features that are unique to the platform. And obviously there’s Tidal, which is it’s own thing.

SonicPi, while not a complete interface to SuperCollider, also is a very different (and honestly more ‘fun’) experience.

Most people know that, and I fear it will not move the discussion forward.

I do agree with @cian’s points about the benefits of Javascript / Node. The ecosystem there is very comprehensive, and already has good editor-integration and visualization support in ways that Python doesn’t. I love Python, but it’s very much a backend language. Node gets you to implementing UIs and visuals more quickly.

And yes, the potential for editor integration with Atom (or whatever has succeeded it) is very compelling too.

2 Likes

Yes, but at the same time, javascript/node/electron solutions are maybe what may displease most people who grew in supercollider for the last 20+ years. It would be a new thing for the kids. Imagine a person who is 20-30% emacs user, and imagine talking about javascript for them.

Maybe it has libraries, but people still have the impression that js is not well-designed. One would need to prove it. Besides, would need to guarantee none of the malicious things would happen to an sc user (if the ide is a kind of browser)

How would one get started with @crucialfelix library?

I’m really not that familiar with the JavaScript ecosystem, but I would like to try it.

I don’t think the discussion is exactly about a review of clients. There are more fundamental disagreements and deeper questions regarding how SC will develop. I have the impression that a drop-in-replacement of another client would be traumatic and is not what anyone is looking for, as far as I can interpret. Maybe the SuperCollider Server should exist with the same functionality for a while. And possibly a non-traumatic transition to a new system, possibly at the same time. Even then, some believe this new system should bring a breakthrough to justify itself. Others don’t think that necessarily.

The last two messages bt Julian and Scott capture this contradiction in the SC community.

Changing the title to embrace the complexity (and contradictions in the community) and try to give some direction to the discussion:

Like Josephine, I see a lot of value in the sheer person-hours put into “mainstream” programming languages. Not just engineering hours, but also time-spent-thinking hours.

However, a couple things I’d like to add:

  • There’s nothing wrong with Sclang staying Sclang (and there are many benefits!). We don’t actually need to change at all: people are happily writing music every day, and as CPUs get faster their code gets slightly zippier. We have a native language that works for many people (it’s extremely rare that I myself write Sclang, but who cares?). There’s a great value to local communities.

  • It’s true that switching to a mainstream language would be a huge energy infusion. You would get at least 1,000x developer hours if switching even to a teeny-tiny niche general-purpose language. I actually think choosing a massive language would run the risk of opening the floodgates too wide and wiping out some of what makes SC special.

  • People, imo, need to “vote with their feet.” I added a Haskell client to the world, for anybody who wanted to use. Most people preferred the default (sclang), which is great. The more the merrier. If there’s true fragmentation (like a 50-50 or even a 70-30 situation), maybe it’s time to talk about a top-down solution. But at the moment, people are choosing Sclang and Tidal and Sonic Pi as SC clients.

    • I actually think that SC4 – in the sense of “let’s design a new language to replace the old” – is actually the wrong solution at this point. There was a linear progression from SC2 to SC3, but there’s now a huge tree of possibilities branching out. Taking the SC4 moniker ahead of time seems wrong.
  • James McCartney’s incredible achievement with SC becomes even more impressive each year we try to improve upon his work. I recall him being treated somewhat shabbily a few years back, and I hope we can all be clear we value his work and ideas (past and present)!

6 Likes

I think the leadership now has more social skills and elegance and would be nice to approach JMC and hear his insights on all this in an online meeting.

There’s nothing wrong with Sclang staying Sclang (and there are many benefits!). We don’t actually need to change at all: people are happily writing music every day, and as CPUs get faster their code gets slightly zippier. We have a native language that works for many people (it’s extremely rare that I myself write Sclang, but who cares?). There’s a great value to local communities.

It’s not so much saying that sclang should die, but more accepting the reality that the language and the IDE are effectively stagnant at this point. Legacy products can continue for years, they just don’t get any improvements. If you like sclang as it is, keep using it. If you’re okay with the IDE, keep using it (and hope that QT doesn’t go away). But for people who want something, or something better, maybe it’s better to invest energies elsewhere.

In an ideal world someone would take SuperCollider, build consensus as to what the language needs to look like going forward, and then would have the time and skills to make that happen relatively quickly. In the real world, none of these seem remotely plausible

People, imo, need to “vote with their feet.” I added a Haskell client to the world, for anybody who wanted to use. Most people preferred the default (sclang), which is great. The more the merrier. If there’s true fragmentation (like a 50-50 or even a 70-30 situation), maybe it’s time to talk about a top-down solution. But at the moment, people are choosing Sclang and Tidal and Sonic Pi as SC clients.

Well that’s partly due to marketing/promotion. Alex Mclean is really good at promotion, and so this has helped Tidal enormously (there is a lot to learn from Alex. He’s a force of nature). Sonic Pi also had someone running it who was good at promotion, and he’s created a really engaging interface that sucks people in. Obviously both of them are good products. But seriously, a coding language in an obscure/difficult language, that allows you to do gabber/carnatic rhythms. Who would have bet on that being successful…

I only came across vivid (I assume that’s your client) because I was already using Haskell. There’s no reference to it on the SuperCollider site, and it’s official presence is in the (intimidating to non-haskell users) Hackage documentation. Given that Haskell is a relatively unpopular language, and SuperCollider is a relatively unpopular music environment, I don’t think lack of interest in what you did is that surprising. Interest was always going to be limited to the subset of people interested in SuperCollider and Haskell.

On the other hand if another language was picked as an official ‘successor’, and was promoted (preferably with a simple one click installation for newbies, and a platform appropriate install for experts with that language), it would do fine. Most people when confronted with a choice between a language that they’ve never heard of and JavaScript/Python - well they’re not going to choose the obscure one.

1 Like

It’s not just the language btw, but also the IDE. Realistically improving the IDE at this point would be a lot of work, whereas creating a nice livecoding environment for JavaScript is a lot easier. Most of the tools are already there (including multiple editors), and there are far more people knowledgable about HTML/CSS/JavaScript than there are C++/QT.

1 Like

I think ‘not remotely possible’ is overstating things a bit. Things have ebbed and flowed a lot over the years. I think they will flow again.

Similarly a lot has been said about things being ‘stagnant’. At this stage I don’t think what SC needs most is a bunch of new features. It’s a mature language and feature rich in its domain. It’s not a commercial product like Max that needs new features to sell the next version and stay alive. What it needs most is bug fixes and stability. I see some new energy in that area, which is great.

Starting a new music language (standalone or on top of a major one) is hard. Harder now in a saturated space. You need people and momentum. To get that, it needs to offer some real advantages. I think it’s interesting that Tidal and Sonic Pi have succeeded by targeting niches within the live coding space (in some ways sclang is a more ‘general’ language by comparison), while some of the less specialised clients haven’t had mass take up,

5 Likes

A JavaScript SC IDE would be cool. Though I wonder if better integration for a couple of the bigger general IDEs out there might be more effective.

I think ‘not remotely possible’ is overstating things a bit. Things have ebbed and flowed a lot over the years. I think they will flow again.

I’ve been using SuperCollider for nearly 15 years and in that time there’s been no changes to SCLang that I can remember. I think its fair to assume that the language is not going to evolve at this point. If people are happy with it as it is, as you seem to be, then that’s fine. But for people who are not satisfied, I think hoping that someone will come along and ‘fix’ SCLang in the ways you want it fixed is probably not realistic. Obviously people can disagree with that, and that’s fine.

For people who do want something else, the question is what would that look like. I think @josephine (Josephine - please get that handle changed admins) made a good suggestion, and I’m willing to work on a JavaScript environment if others are. I don’t think this needs to be an official project anymore than Tidal/Sonic Pi are, but obviously it could be. For such a project to succeed it would probably need a few more people - not just coders. And if there’s no interest, well that’s probably a sign that this is not such a good idea.

I think it’s interesting that Tidal and Sonic Pi have succeeded by targeting niches within the live coding space (in some ways sclang is a more ‘general’ language by comparison), while some of the less specialised clients haven’t had mass take up,

Well they both created their own niches. I think the reason that both of them succeeded is that their creators marketed them. The only other frontend that I can think of that was really promoted was the Clojure one (Overtone), and that was Sam Aaron also. And he promoted the hell out of that.

If I remember correctly the IDE was developed in QT4, which is seriously legacy at this point (QT is on version 6), so upgrading it would be serious work and it’s an open question how much longer it will continue to work. It was EOL 2015, and QT5 will EOL next year.

On the subject of ‘stagnation’ (I don’t love that term as it sounds pejorative, but I can’t think of a better word), I think it’s reasonable to note that QT5 is going to go EOL next year, so if noone is planning to migrate it to QT6, then at some point it may stop working.

There are definitely advantages to having a custom IDE, but given the ubiquity of VSCode at this point, maybe it’s not worth the effort.

What features/evolution would you like to see? (Sorry, not going to reread the last 422 posts at this point so this may be repetition.)

Promotion is important indeed, but not sufficient I suspect. Especially if you want a mass migration or major rework. People need a reason to switch. I think an SC4 could work, for similar reasons that C++ captured a lot of C developers, and that Python 3 eventually succeeded. A whole new language ‘replacing’ it in some sense would be a harder but not impossible sell. It has been sort of tried after all: ScalaCollider

JavaScript or any GUI lib will sooner or later have version incompatibilities and EOL issues. Tbh I’m less concerned about the IDE and QtGUI then I am about crashes and memory bugs. There have long been many SC editors, and I think if the IDE became unviable, another option would become the dominant one. (Atom was really popular for a while and had some nice features. Shame it was dropped!) Similarly with the GUI. It’s a big pain for sure, but wouldn’t be the first such transition, and there is also the option of various third party GUI servers.

Do you have a sense of the scale of incompatibilities between QT5 and 6?

What features/evolution would you like to see?

Well I was more making the point that for people who are dissatisfied with the current state of SCLang, they probably should not expect any changes. I’m not suggesting that anyone should be dissatisfied. I don’t think the language should be killed, I just think people should adjust their expectations appropriately. If someone does step up an enhance the language that would be great, but I think it’s highly unlikely at this point.

Promotion is important indeed, but not sufficient I suspect. Especially if you want a mass migration or major rework.

Sure, I was merely making the point that one can’t really draw any conclusions from previous failures because none of them have been very effectively promoted. The one that was promoted (Overtone) actually did pretty well until Sam abandoned it for SonicPi.

If people are happy with SCLang then I don’t think they should migrate. My expectation is that if a new language was done right, then some people would migrate (because they preferred that language, it had features they desired). But my suspicion is that it would probably mostly attract people who are not currently using SuperCollider. I think the potential pool of people who would be interested in using something like SuperCollider is far larger than the current pool of users. If there was an easy to use tool that used a language they are familiar with (and which has plenty of resources) they would be more likely to try it.

People need a reason to switch. I think an SC4 could work, for similar reasons that C++ captured a lot of C developers, and that Python 3 eventually succeeded.

As a hypothetical this is possible. Practically I don’t think the resources are there to make a SCLang4. Designing and making a new language is hard. I’ve followed the process for several languages (most of which failed), and the ones that succeeded took many developer man years, and had at least one full time person working on them. And these were languages that had a single person responsible for decision making - I have no idea how you would make that work in the current SuperCollider community, particularly given that there seems to be no particular consensus on what SC4 should even look like.

JavaScript or any GUI lib will sooner or later have version incompatibilities and EOL issues.

Anything will if you don’t constantly maintain it. I just think it would be easier to find people to maintain stuff written in JS using mainstream technologies, than QT. If the IDE is being actively maintained then it’s not a problem. Is it?

Tbh I’m less concerned about the IDE and QtGUI then I am about crashes and memory bugs.

Over time it will just work less well on at least one OS (probably OSX). That’s just the nature of a cross platform GUI toolkit that’s not updated.

There have long been many SC editors, and I think if the IDE became unviable, another option would become the dominant one. (Atom was really popular for a while and had some nice features. Shame it was dropped!)

Atom has been revived as PulsarEdit. It’s quite small atm, but it’s not bad. Quite a few Tidal users seem to be using it, and they seem happy with it. Don’t know if anything can stop the juggernaut of VSCode atm, but then Emacs/Vim were almost dead 15 years ago, and now they’re surprisingly lively.

Similarly with the GUI. It’s a big pain for sure, but wouldn’t be the first such transition, and there is also the option of various third party GUI servers.

Sure, it’s not that such a thing is impossible. It’s just that someone has to actually do the work, and the longer you leave it the harder it is.

Do you have a sense of the scale of incompatibilities between QT5 and 6?

No idea. Like I said if someone’s working on it then it may not be a problem, but the longer nothing happens the harder it will be to update the code.