SuperCollider 4: First Thoughts

I now remember that there was this topic about crowdfunding or making a foundation for SC.

I suggest that we keep the discussion about financial resources and support there as much as possible and the topics regarding the language and technical aspects here.

I also remember a long thread in the list about Csound vs SuperCollider from 2011:

Reading it again made me happy with how much SC has evolved (IDE, windows compatibility, NRT, bug fixes, midi and serial support, etc etc). But the topic about fund raising was still a problem there and no proper solution came out of it…

So true !

Totally agree with that. Flucoma is one example, Christof Ressi’s vst plugins are another one – e.g. see [vstplugin~] – A Pd external for hosting VST plugins | Revista Vórtex for the history.

1 Like

Another important consideration:

Should SC 4 retire SCIDE?

1 Like

I use SCNvim and love it but for now the IDE is necessary for new non-coder users. I could imagine the LSP work that @scztt is working on (building on the parser that @lnihlen wrote) eventually making the IDE unnecessary but I expect that’s a while off (if ever!)

1 Like

I don’t think that SCIDE is an amazing IDE, but I do think that it is great and do its job pretty well. Is it costly to maintain? I can’t say.

But based on this:

I assume that removing the IDE will block several artists from accessing SC. I’ve attended to the previous International Live Coding Conference (ICLC) and I was impressed with how big the scene is, also impressed that around 10% of the people were using sclang, scide and scsynth together as their main live coding platform (which is easy to understand).

If SCIDE could also ship tidal natively I think that the SC community would grow more faster, but I understand the amount of work necessary plus the coordination with tidal…

Moreover, adopting some general IDE as the main substitute for SCIDE, I assume it is also problematic. Several projects relied on Atom as their base IDE (including Tidal) and suddenly Atom was over… + the problem of installation: SCIDE is also great because it is super easy to install, a great entry point. + the difficulties of customizing a general IDE for having a docked help, server meter, run all the shortcuts, etc…

IMO, having a personal IDE is not waste of resources. If this was not the case, big environments like Matlab, Python, Processing, Latex, would never have done so…

Scide should not be understood as an “IDE” (those things do all sorts of things in the backgrounds, it’s scary sometimes), but as an efficient lightweight text editor. It does its job. It was worse before it.

If someone wants to improve SC in emacs and vscode, it’s not a problema, it would be good too.

Why not just work on the emacs or vscode plugins and make it so good everyone will forget this lightweight text editor?

1 Like

Exactly this.

Think of Racket, J, APL (the first 3 that came to mind) etc… without the IDE’s that comes with them i would never even bothered to try them out. Coming from a background in textile arts rather than computer science, I would never ever tried it. Getting a decent workflow with vim or emacs would have been too much work. Maybe I am not alone in this.

(Then again my first encounters with supercollider was on MacOS 9)

I find it important to be able to try stuff out right away, no matter the language, without having to invest hours of setting it up in order to just run “Hello world!”.postln; or a play{}; …

FWIW, if a better, one-click-just-working-out-of-the-box-for_everyone_solution would ship with sc i would be happy to jump ship.

i will let myself out now.

1 Like

Take the following message as a personal opinion about SCIDE and not as a blunt criticism of it. I like SCIDE.

I taught SC for undergrads in France last year. I recognize the value or SCIDE to the point that I were expecting students to dive into the embedded documentation head first as a source of knowledge for assignments.

To put it bluntly, it was probably the biggest mistake I made teaching that class. If you are not already a dev and not a fluent english speaker, teaching SCIDE is already two hours of work if students are really fully commited to the exercise (which is rarely the case). It adds complexity and expects users to already partly know what they are supposed to learn. How to find information about classes (they don’t know what a class or a method is), how the library is structured, what a server is, etc…

Teaching Python is usually made using whatever editor imposed by univ staff and bespoke class material. This is also a valid strategy to Iower the entry cost into an ecosystem. If the tool is good, people will not fly away seeking something else.

It’s very low cost to maintain now, but this is effectively a “frozen” state - it’s not getting new features, and is built on top of more or less deprecated Qt technology that will go away in the future. For the IDE to be actively maintained / for it to not be facing extinction, it would require ~4-6 months for probably 2 developers to rebuild it in QML, or another using another UI framework like Flutter or Electron. This would also mean adding another language (QML/Flutter/Java/Typescript) to the codebase and some potentially heavyweight dependencies (Java VM, Electron) - increased maintenance means fewer features go into SC as a whole. All of this is an extraordinarily large cost - it’s worth balancing this against what else we could do with that time.

it would require ~4-6 months for probably 2 developers to rebuild it in QML

Personally, I don’t think that Qt Widgets will go away anytime soon. But if you’re really concerned about Qt Widgets, what about sclang? Porting the whole sclang GUI from Qt Widgets to QML (or something else) would require even more effort…

I was filled with apprehension when the qt6 packages arrived on Fedora. I thought ‘Yikes’ )))) but there are many things still in qt4 as well, they work! Should we be so dramatic? Many things can change until then.

Do we have any way of measuring SC usage/popularity?

This I see often. The misconception is that (API) documentation is a tutorial. It is not.

Regarding IDE’s, SC’s language has it quirks and I don’t need the quirks of vim, emac and vscode on top of that. One struggle is enough. The fact that these tools are there for them who prefer those is excellent.

I agree. But nonetheless, SCIDE doesn’t really make it clear what is API documentation and what is a user tutorial or software information. As much as I don’t like Max/MSP, they split between Help files and Reference articles, which is a valuable distinction since it forces people to think about the difference between shallow usage (I need to do X, I’ll use Y) and deep dive into principles, etc… They also have what could be considered as an API documentation with all the bells and whistles they added to object management. Again, still my opinion but I think that SCIDE could do a better job of presenting documentation to users without enforcing a model that is valuable only to people that are deeply accustomed to OOP and API browsing.

As critical as I may seem, I still value the work that has been done on SCIDE. I would probably never have learned SC in the first place if someone told me that the architecture was so complex behind the curtains as I wouldn’t have been able back then to handle such complexity. The interface layout is well done, and clearly makes the distinction between language and server, probably the most important concept that there is to know for SC users.

Still, relying on third party editors make it so that you can basically make everyone happy and you also have less work to focus on for maintenance. The work not done on editor can be redistributed to writing better documentation, shipping new features or fixing bugs. Given the popularity of SCNvim and third party tools for SC, I think that this practice of not using SCIDE is already there. SCIDE can also hinder some long acquired programming habits for the most tech savvy people out there.

1 Like

I am being slightly alarmist about this, they MAY let these widgets creep along for many more years :slight_smile:. But the Qt company has significantly reduced their support commitment for legacy stuff in recent years (for OS customers), so we need to be aware of the fact that we are a bit at the mercy of a financial situation of a company that has already recently said “we don’t have the money to keep up the maintenance work we’re doing now”.

Adding QML support to sclang is very straightforward since we already have the entire QT object model exposed - I can share a branch where this is working if you want to play with it. The only heavy engineering work here would be to design an API through which you can interact with QML UI’s from sclang - this is mostly a design problem, and it’s likely that all of this code would be largely sclang code and not C++. I haven’t pushed for adding this QML support thus far because I think adding it WITHOUT some solid design patterns would just be confusing for people and lead to bad code.

1 Like

FWIW I’d love it if someone wanted to take up the work of integrating QML with sclang. It would greatly reduce the surface area of our QT dependency (the required QML interfaces are very small, and mostly already exist), and there would be enormous user benefit. It’s a very tricky and fun C++ project, and an interesting API design challenge.

I disagree that having a more difficult install process or having to use a normal text editor would be a problem. The tidal community is massive and very active and to install tidal is considerably more annoying than getting started with SC. If the install/getting started process is well documented I don’t see this being a major obstacle.

Check [n].assets[n].downloadCount - this is the only metric I know of at the moment. Usage would be nice - I wish there was a service that open source products could use for gathering analytics in an ethical way. This kind of information is SO valuable for steering a software project, validating features, fixing bugs, etc.