SuperCollider 4: First Thoughts

Development
392

I still think this is the best way forward, unlikely or not. (Said this for a few years now.)

If we’re not equipped to maintain sclang’s backend, then we’re certainly not equipped to design and implement a new bespoke language for audio.

Scsynth bindings over an existing language may not be perfect, but “letting the perfect be the enemy of the good” only has one outcome (code rot).

Would love to see a hypothetical illustration of how Elixir could interface with scsynth and be made approachable for SC users.

hjh

1 Like
393

I believe this will be just the end of SuperCollider Server / SuperCollider 3 as we know it. It will just create a small niche around another language.

The good side is that other languages (the ones with a real vision) will have space to grow.

A vision does not happen following “software good practices”, it’s something of the human spirit.

SmallTalk and JMC are from a time before this new military/corporate “computer science” model took place.

(Soon, some of them will say they know everything, not only about computer languages but the human spirit and absolute knowledge)

History is brutal, Marx noted: " . . .All that is solid melts into air."

I hope SuperCollider Server receives state-of-the-art archiving and will be available indefinitely, virtualization technology is excellent today.

394

Yes, but so would a new language based on sclang. (SC3 killed SC2.) I think it’s inevitable that SC3 will end. The question is whether it’s replaced by another language with expert design and a good support community behind it, or replaced with vaporware that we’re never going to write. The former may be problematic but workable; the latter would be quite a loss. I perhaps exaggerate a bit but I kinda think not by too much.

hjh

395

SuperCollider Server was the product (after many dead-ends (3d5) and mistakes) of the vision of a person obsessed with creating an outstanding system.

Do you see that around here? I see developers who want to follow “good practices” (in the sense of military/corporate software production).

The result will be probably boring. Who needs boring software?
I don’t know. Nobody will adopt boring software, guys.

I can’t see this level of obstination and creativity necessary for architects and visionaries.
But the world spirit is much larger than this, it will find a way and human creativity will happen somehow somewhere.

Inshallah

396

They speak the language (English), one or two Chinese languages, and some other language maybe.

You probably don’t know but (to cite just one example) China’s Sun Yat-sen (public research) University beats Oxford, Cambridge, and Yale in many scientific areas including computing.

397

How is this possible that none of the clients developed so far are not up to the job, but this new hypothetical one will be necessarily better than all that has been done?

What’s the rationale?

vivid, for example, tries to keep sclang in the loop. that would be a good kind of transition.

Ok, I’ll write my SynthDef in the old style, but this programming block I will use vivid etc

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.

7 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.