SuperCollider 4: First Thoughts

Yeah it’s the obvious candidate. Putting a bit of work into better support there would be welcome in any case, and give some security even if it wasn’t adopted as the ‘main’ editor.

Yes, I know. It didn’t run the last time I tried to download it. But IAC the main attraction was major development muscle behind it with GitHub. Which evaporated very fast in this case.

Is Qt not being updated? I’ve not looked at this at all tbf, but in general I would have thought they’d be minimising breaking changes. I know there have been some exceptions in Qt, but has anyone here actually determined that Qt6 is going to cause major work?

SC definitely has governance questions to be considered. After more than 20 years of watching decisions made, I don’t think the issue is how to get consensus. It’s how to move forward with any lack of complete consensus. At the moment, we have a lot of input from the community, but a variety of preferences. We sometimes see the phenomenon of a few louder voices putting forward strong objections. While that’s not exactly a veto, and shouldn’t be, it can lead to inaction.

There are solutions to that, and ways to evolve SC as a project and community. We’d need to decide if we want to take those, though. At the moment I’m more interested in community building, and building some more stability into the way things are going than big changes.

Is Qt not being updated?

QT5 won’t be once they end of life it. QT6 is obviously being maintained, but that’s only relevant if SCIDE has migrated to it. I have no idea if it will take major work, or what is happening to it. I’m just pointing out that if the work doesn’t happen then the IDE will gradually die.

I think the problem is more that for a successful language you need a fairly coherent and singular vision. I don’t think that exists in the community for what SCLang4 would look like, so I don’t see how you get consensus.

And also, as I said, I think most of the discussions about new/evolved languages underestimate how much work is involved. It would dwarf any work on the synth engine.

Is Qt not being updated? I’ve not looked at this at all tbf, but in general I would have thought they’d be minimising breaking changes. I know there have been some exceptions in Qt, but has anyone here actually determined that Qt6 is going to cause major work?

Qt is fine, it’s not going anywhere.

Qt 5 → 6 migration is in progress for SC jrsurge/supercollider at topic/qt6 (github.com), we were waiting for linux package managers to catch up, and I ran out of spoons trying to convince people to drop support for 5 to minimise technical debt. It’s not complete. I can get back to it if people are interested.

For reference, it’s a bit of work, has some breaking changes (see some of the commits). I’m more than happy to do the migration, and have done it before

7 Likes

Awesome, @jrsurge! For myself, yes, by all means proceed. If you need some help let me know. I’m out of practice, but found Qt to be very coder friendly in general.

1 Like

On a more general note, could we please stop being so determinedly negative?

I’m really burned out on ‘impossible’, ‘highly unlikely’, ‘die’, and other similar terms. I don’t wish to squash anyone’s expression, but this language accomplishes nothing beside discouraging people from contributing, and sapping people of the enthusiasm it takes to actually do stuff.

Again, after all these years I can tell you that the large majority of the time, these pessimistic statements aren’t even true! If you want, I can point you to the time when I fixed some ‘impossible to find’ bugs in about three hours. It turned out everyone was so sure it was so hard that nobody had really tried!

Usually these things just take that sort of digging in a little to get them done, like @jrsurge with Qt6. I suggest we focus on encouraging and doing. That’s the way to make things better.

(And just to be clear @cian, this is not directed specifically at you or anyone in particular. SuperCollider pessimism has a long history. I get where it’s coming from, I just think there’s a better way and thought I should say so.)

18 Likes

Very appreciative of this work, @jrsurge! With all its privacy issues I would never, ever use VSCode for SC. Glad I won’t be pushed in this direction anytime soon.

1 Like

It will always be a danger with any javascript/nodejs/electron based application, especially with private investment behind it. (Strangely, many people don’t care anymore today)

It’s a post-Assange world.

EDIT: Also, when I tried to use vscode on Linux, I notice that the system gives it so much priority, that it can interfere with my tuned low-latency Linux system like any other app can.

Yes to QT6. @jsurge - Yes we can!

Yes to less negativity. It has really been bumming me out. I use this language because it is the most musically expressive language for me. Show me a more musically expressive language and I am glad to use it. The key word is musically. This is where James hit such a home run. He encapsulated so many kinds of expression into one language. Nothing else I have tried comes close.

Sam

7 Likes

I tried to say this clumsily, awkwardly; you said it clearly. It’s perfectly possible to maintain SC3.

What I tried to say about talks on “sc4” stuff, was that one needs a “vision”, or, in your words, a new “more musically expressive language”.

We, deep down, agree much more than on the surface.

Does it really “kill” an application? I think one can find some Qt3 and Qt4 applications in the repositories of Linux distributions today. Maybe there are reasons related to the context of the project, of course. But is it not just that?

For some reason, I have qt3 tooling on my system (Fedora 39)

EDIT: I’ve just seen people are doing this work already anyway.

It’s more that they decay. Most things work, but maybe not brilliantly, there are weird bugs and maybe it will crash mysteriously once in a while. Though I tend to find on any system when there’s a major architectural change, a whole bunch of old apps stop working entirely.

Obviously it’s not a problem if things are updated (which thankfully is happening).

1 Like

Sometimes the best applications for some things have not been updated in more than a decade. One example is baudline for real-time spectrograms. It works like a charm here. While new ones, written in python with modern libs, are so bad. They try to look too nice and end up being a toy.

1 Like

Writing the following opinion here would be inappropriate, but I will leave it:

I’ve been thinking about the development of SC4 and it seems like a challenging task that would require a highly motivated C++ programmer to bring it to life.

There are indeed over 800 issues that need attention, and over 100 PRs that need to be reviewed.
It’s inspiring to see the experts here and on GitHub innovating with their own ideas, but combining these efforts would be more productive. For example, there are at least two SC-IDEs being developed individually, while the official IDE development seems to be on hold with many wish lists. I have a lot of respect for those who are working hard on the official IDE as well as their own IDEs. However, there seems to be a consensus against further development of the official IDE, and that makes me sad…

I was thinking of proposing to invite some C++ programmers who also have a background in acoustics and music (experimental, classical and commercial) to develop SC4 based on the IDE wishlist and the ideas in this thread. I refrained from doing so, however, as it seemed to go against the open-source philosophy. However, it may be worth exploring if we want to continue to use SC3 in this rapidly changing environment and develop SC4.

I don’t have a regular job and earn less than 440 USD per month. I don’t know if I will be able to teach a class using SC next semester or next year, or if my future project proposal using SC will be accepted by any foundation. However, I’m considering setting aside some money each month to support those who dedicate their time and energy to SC. I believe in the potential of this project and want to contribute in any way I can.

Thank you for reading my thoughts.

1 Like

I deeply admire your dedication and passion for the SuperCollider project.

The suggestions you mentioned have been considered before but were dismissed due to the high cost of living in technology hubs in the U.S. and Europe. Audio developers working in the private sector in the West are not enjoying the best careers in programming, which may explain why many others didn’t choose this path. Which just makes the first problem worse.

I propose hosting a SuperCollider Symposium in South Korea, bringing in talented developers from across Asia (and even Russia, depending on logistics), a region that is leading the way in technology and computing today. That would shake things up, maybe. And you have experience doing that!

For example, Shenzhen (China) is 70% less expensive than New York and hosts a university (at least the informatics department is there) that is ranked above Cambridge, Oxford, and Yale in several scientific fields. That’s just a random example.

Such an initiative could inspire greater (truly international) community engagement, potentially drawing contributions from a significant portion of the global developer community.

Just a thought… to supplement your post…

EDIT: One thing that caught my attention is how China is now interested in cultural exchange, at least with my country in 16 agreements recently signed. I don’t think the relations with other Asian countries are any less friendly, I think it’s even more.

I apologise for repeating the opinion already discussed, as I had not followed the discussion in this thread closely.

If this is a comment to encourage me to host a future SuperCollider Symposium in Seoul. I should reiterate that I stopped all this work in 2020, as I mentioned to you in a personal conversation. From 2011 to 2017, I hosted KEAMSAC (Korean Electro-Acoustic Music Society’s Annual Conference. Strangely, they call themselves the Korea Electro-Acoustic Music Society) and its journal. Due to organisational conflicts, I left this society and then hosted the Symposium on Spatial Sound Arts in Seoul twice (2019, 2020). I had hoped to continue hosting it, but due to the pandemic and the sudden change in policy of the foundation that had been supporting me financially, I had to stop at the end of the project. I was also asked to participate in ICMC 2018 and FARM 2021, but I declined.

The 2010 symposium in Berlin was a fantastic time in my life, and it was certainly one of my dreams to host it in Seoul. However, as an individual without a regular job and earning less than 440 USD per month, it is impossible (now and in the future):

In order to get financial support, I would have to spend 10% of the total budget out of my own pocket, which I don’t have the money to do; it is very difficult to include remuneration for my own work, which is calculated on the basis of time, effort and professional skills, in the project budget; and the company helping with such an event is investing in its crew for future interest, but this kind of event is not in the interest of such companies; the young people under 40 are helping with such an event for future jobs and current part-time work. Nobody wants to spend their own time and energy on such an event without being paid.

I did this before because of the fantastic experiences I had had at such events, e.g: SuperCollider Symposium in Berlin, Symposium on Ambisonics and Spherical Acoustics at IRCAM, etc (especially the European Conference and Symposium).
Every time I saw and heard the results of the participants from all over the world whom I supported, I was extremely happy and forgot all the pain and stress of the year. However, the time and effort and all the paperwork required by the foundations and especially the conflict with the other crew was really bad. In the reality of my life, the accumulated stress and loss of financial and physical status were greater than my happiness during the event.

So I cannot do it again. I am sorry to turn down your encouragement, but I hope you can understand my position.

1 Like

Of course. It was not clear that you had stopped for good. I thought it was something else.

Anyway, it was just a thought. Maybe it serves as an inspiration for others.

Love,
smoge

1 Like

I believe in modularizing and the attempts to focus on the core, which has already started. Where are the pitfalls of sclang? Is that really in coding sound? Where can it be improved? I think the book and tutorials by Eli Fieldsteel and some helpful articles by Nathan Ho are really helpful here to find your way with sclang.

Then use a different language for the other parts as much as possible. Make it easier to run sclang from the command line, to build crossplatform packages for SC, to build and install customized versions of SC. I like the experiments with imGui (other then the fact that I would avoid c++ and use c instead to be more future proof). New plugin / quarks system in python, javascript? IDE, plugin for a popular code editor?

Sure and in meantime people will try to replace sclang, if it succeeds and it’s better, then people will start to use it. But you need someone who is really dedicated to do it, I’m not sure if design by committee by some people who might want to help here and there will give you a better sclang replacement anytime soon.

2 Likes

There are several clients for scsynth/supernova out there already.

I don’t think sclang will ever “disappear”. It will exist forever.

And I like your idea of making sclang as flexible as possible from the terminal

2 Likes

My 2cents:
I spent a lot of time on sc by writing uGens, making music, and writing sc code. While I personally disagree that it’s a niche language and would like to see it survive and improve, an integration within python (as someone suggested) - in my opinion - should point more on shared memory rather than (as currently) osc control or total change of language paradigm (python as somebody proposed). Secondly, what I would ~really really~ like to have is the possibility of not having to compile ugens against the whole source code, an approach similar to gen~. Maybe a mechanic like synthdef, where the ugendef is written (preferably in c++) and sent to the server. That would make it easier in academic contexts both for teaching (a “soft” approach for students to c++ and low level dsp) and also for research and testing/importing libraries - secondary to this, (maybe a non popular opinion with “the creator”) a full on modern c++ refactoring of the source code would be amazing.

1 Like