Regarding the idea of a foundation, I think it’s great in principle, but I wonder about the reach of SC. Python can do this because it has a huge user base and wealthy stakeholders.
Without that, I think longevity remains a concern. I would love for the University of Birmingham to host such a thing, and perhaps I could convince them. But what happens when I retire if they don’t replace me with someone equally invested? Institutions sound great for giving these things some permanence, but at the end of the day institutions are people, and with the best will in the world it’s very difficult to maintain such things if there isn’t on the ground individual commitment.
All of which is not to say that couldn’t work, but just to be careful around that issue. A targeted and funded research project (a la Flucoma) with clear aims and a limited timeline could work better at making some big steps forward, though it can be hard to sell the kind of maintenance, reworking, fixing work that FLOSS projects often need to funders looking for exciting projects. But properly pitched this could be very successful, and a much easier lift than a permanent foundation. I’d be very happy to work with people on an application of this sort!
Finally, as it keeps coming up, just some clarification about the mailing lists for those who may not know:
I kept them going for as long as I could, as I know many people preferred them, but in the end institutional decisions made it impractical to continue. As I said at the time, people were naturally welcome to start a new list elsewhere if they wanted, but GDPR meant we could not simply move the archive to a new host.
Someone still can start a list of course (after more than a decade moderating, I thought it would perhaps be better if it was someone else) but I think the forum is a good compromise and I hope it makes most people mostly happy. It too may have longevity and/or ownership issues at some point, but I think the SC community is established and large enough now that it can support multiple fora, and shouldn’t be too dependent on any one’s survival. I admit I’m not as active here as I was on the lists, but that would probably have happened for other reasons anyway, and I’m always encouraged by the health of the discussion I see here.
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.
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…
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!)
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.
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{SinOsc.ar}; …
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.
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.
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.
I am being slightly alarmist about this, they MAY let these widgets creep along for many more years . 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.
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.
. 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”.