I’ve never seen that
what is f ?
The Tidal community seems to dwarf the SuperCollider one these days, though they still seem to use sclang for synthdefs/server config. I did have a conversation a while back with someone in that community and they were looking at being 100% Haskell.
SonicPi still seems to be pretty popular (and its great for newcomers - far better than SCLang).
There’s also Lua/Monome, again very popular, which uses Lua for scheduling and SuperCollider for synth definitions.
1 Like
I’ve heard this conversation about turning Tidal 100% Haskell too. It would be a good experience. I think it’s no problem today,
I will not rewrite scsynth in Rust or Haskell or whatever. scsynth is already written.
But on my Haskell side, I’ll experiment freely and see how it goes.
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
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.
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
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
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.
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
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
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.
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.
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…)
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
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
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
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
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
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.