SuperCollider 4: First Thoughts

Development
398

Isn’t it apples and oranges? Clients developed so far have positioned themselves as alternatives to sclang (and as such, they’re pretty much always going to be poor imitations of the original). But the discussion of SC4 has been about new paradigms, enabling usage patterns that are more modern than sclang and also difficult to achieve cleanly in sclang. The former approach is likely to disappoint; the latter is an entirely different game.

I’d favor building a language if I believed we have the personnel to do it, but we don’t.

hjh

399

Oh, god, we do, they are the authors of those clients. They are the best we have: @amindfv @rdd @josephine ect etc

And not everything is imitation.

400

The problem with syntax is one of those “impossible” problems.

I think for some time there was a semi-random person per year in the Haskell project who had the last word on syntax because it can easily become a black hole/ insoluble.

401

I don’t particularly like Python, but I suspect Haskell won’t be accepted. Let’s schedule a meeting with Josiah to see his system in action, and talk about the future.

Why opt for an exotic language? Choose Python. Although it’s not my favorite, it is practical and widely understood.

Josiah is a highly competent software visionary, scientist, artist, and architect. He knows his craft well.

Integrating scientific and data libraries into the system and developing it step-by-step will make it align with our goals.

That sounds like a solid plan.

(I’m aiming for a rational approach here, not letting my personal preferences influence the decision…)

402

Hi, just seeing all this now, so I’ll give my 2c

(And apologies if this comes off as harsh - please understand that it’s coming from a place of love and deep respect for this project. I wouldn’t have spent 10 years writing a language client if I didn’t love SC.)

  • Unpopular opinion: in the current year, music programming is not boutique enough to deserve a boutique language solution. It’s self-congratulatory and self-defeating. I understand why sclang first arose, but times have changed - the original conditions IMHO no longer apply.

  • Stop designing languages. Language design is a rabbit hole, and the knock-on effects of writing a language from scratch are an endless burden: need to roll your own package manager, unit test framework, documentation system, etc.

  • Design libraries for existing language(s). Reap the benefits of all the other work that has already gone into making those languages (and their accompanying tool chains and package ecosystems) tick. If you need to, design clean generic language bindings and APIs so other languages can interact with your C-level code and/or synthesis server.

  • Please please pick a boring, widely adopted language (or languages) as your initial proving ground. I know Haskell / Scala / Elixir / Clojure are compelling, but they’re all also relatively boutique compared to Node or Python. I’ve been working in academia and industry for nearly 20 years and I rarely see these languages pop up except in boutique situations. They do not have the same extensive ecosystems as big name languages, and you will end up doing more work than you want to fill in the gaps.

While it’s true, I am a big fan of Python, for my money I would tell you to look into Node first. Massive adoption. Massive ecosystem. Good concurrency / async support. Can be pithier than Python (see Node’s lambda syntax). Tool chains support transpiling (as I doubt the SC community can fully give up language catnip). And it’s very often the first language people learn now.

Throwing your weight at Node or Python would be a huge blood transfusion given how many people know those languages.

Don’t put yourself onto an iceberg. Every new thing to learn is a cognitive burden on the student. Understanding scsynth’s core concepts is already a big task - we don’t need to make using them harder by requiring an entirely new language just to work with them.

Love, Joséphine (she/her)

PS: I’m transitioning, and trying to get my username changed here. Fingers crossed, one of the mods sees my email about it.

6 Likes
403

Also, yes, I’d be happy to jump on a call with any of you. Just send me a message and we can schedule.

1 Like
404

I think a call would be perfect to get into your point, they all sound reasonable, and the community is experiencing a phase of self-reflection now. Thank you, Joséphine. We will be in touch. Your experience will be very welcome. You’re at home here.

1 Like
405

@muellmusik @jamshark70 @jordan @scztt @Sam_Pluta @julian

406

Thank you for your opinion.

Luckily, SuperCollider has been existing for almost 30 years now and people grew up speaking this language. It comes with both advantages and disadvantages that “indigenous” languages share.

something else, about this topic:

I would like to rename this topic. It is like a Katamari Damacy for thoughts, which is good in itself.

But currently, as far as I know, no large next version is planned, and I think that it is not necessary. We can make incremental improvements to the existing thing, and of course if there is something that would be so amazing that it would be worth breaking compatibility, it would have the major version number 4. But for now, we are fine in keeping up a good spirit in maintaining and improving what we have.

Suggestion: SuperCollider: what else could it be?

Let me know if you disagree with the renaming.

5 Likes
407

The points about general languages are commonly made, and valid I think. The counterpoint I suppose is that domain specific languages can prioritise important bespoke features and designs choices, eg good real-time safety and performance. Many ‘general’ languages do not prioritise this at all.

As well, SC exists, and has for a long time as @Julian points out. It’s already been invented. Yes, maybe something better could be created, but the effort required to create it and convince a large number of users to adopt it is huge. (This is different from the old days when music languages were a very sparse field.) C++ is not the best language in so many, many ways (convince me I’m wrong), but gosh does it have momentum.

3 Likes
408

Maybe one thing is not to have expectations that a major breaking change in SuperCollider will have a fraction of the user’s SuperCollider Server has. History will not repeat itself. It’s better not to have this illusion.

Another point is that SuperCollider Server + scsynth must be able to run forever, using whatever technological means necessary at each point. Even if it means virtualization in some 20 years. FOr artistic, historic and archival reasons.

The transition does not need to be traumatic. Maybe we can start with this ideal, get together with some smart people like Josephine, and think this through.

409

Please please pick a boring, widely adopted language (or languages) as your initial proving ground. I know Haskell / Scala / Elixir / Clojure are compelling, but they’re all also relatively boutique compared to Node or Python.

I think this is a good argument, and part of the reason I think this is because I HATE it, but I still find it compelling. I don’t like either of these languages, but I’m also aware that SuperCollider is already niche so anything that makes it more niche is bad.

Both languages have SuperCollider clients that seem robust and well supported. So that’s another good argument. There is something proven to build upon.

On the left we have Python, written by Josephine, which looks pretty comprehensive:

Maybe Josephine can give some pointers on how to get started with it?

On the right we have JavaScript, written by @crucialfelix which I’ve heard good things about. Again, seems pretty comprehensive:

SCLang is not going anywhere, but for reasons James says it’s also not going to advance. Saying that SCLang is in maintenance, and no serious resources will be devoted to it or the IDE is a reasonable thing to do.

Then pick (preferably one that has lots of developers within the SuperCollider community), making sure it has solid support for livecoding (e.g. VSCode/Atom plugins) and providing documentation is perfectly fine.

One argument for JavaScript is that you could package up a JavaScript solution that includes an editor (using Electron, or whatever), helpfiles and integration with stuff like D3, Vecflow, visualization stuff. The fact that you can just download SuperCollider and it works is very powerful imho. It would be a shame to lose that.

410

The points about general languages are commonly made, and valid I think. The counterpoint I suppose is that domain specific languages can prioritise important bespoke features and designs choices, eg good real-time safety and performance. Many ‘general’ languages do not prioritise this at all.

They can (which is why I mentioned Elixir as an interesting niche language that prioritizes those things), but developing such a language is a huge endeavor that most people fail at.

SCLang was written at a time when there just weren’t good alternatives (Python, which was very slow, Java which was too, err, Java and Perl…). Times change.

411

Please, @cian. Be careful to not reinitiate all the old chaotic threads. Let’s try not to be all over in the new discussion. Use the techniques you learned in those places. There is a new one, let’s try to move forward and identify different perspectives. And hear new people, as well.

Don’t repeat old posts.

412

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.

413

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

414

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
415

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.

416

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)

417

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.