SuperCollider 4: First Thoughts

Development
81

An experienced software developer (someone that could reliably dig into an “SC4” scale project and not crash and burn) in a major city that isn’t SF/NYC/Seattle is something like ~70k in Europe / ~90k in USD (this is probably a little low as it doesn’t include e.g. health insurance, if you’re in a place where you have to pay for that). If you take that as rough baseline for “fair” pay (meaning full time developers aren’t implicitly “donating” money by working another job or living off of savings), then you could imagine 5000€/mo could basically pay for 2 half-time developers - or a 40k fundraiser might be able to get 2 full time developers for 4 months. This scale is not unrealistic for an open source project - Ardour, the open source DAW, has $13k/month in subscribers.

These numbers get easier if you think about the reach that SuperCollider has. For example, SC is a standard tool for teaching electronic music, synthesis, creative coding - the usage for this is VERY broad if you also take into account e.g. Tidal, SonicPi etc as well. These are classrooms full of students whose are likely paying >1k a semester for the course (either via government funding or private tuition), and learning with a tool that’s completely free. This is of course utopian and would never happen, but if you imagine universities agreed to donate $10/student/semester for SC classroom use, this would IMMEDIATELY pay for a few 1/2 time or maybe even full time developers more or less permanently. As far as I know, grants in the low tens-of-thousands for art+technology projects in wealthier European countries are absolutely available, and SC would be an easy case to make given that it’s open source, and enables thousands of artists and educators. You can imagine that one or two grants at this scale would “pay for” one or two large-scale SC enhancements (maybe not “SC4”, but some major steps along the way).

I think being successful with this requires some work - it took Ardour MANY years to get to the funding situation they have now. And, “one smart developer” is a very high-risk way to develop software - I would consider it almost a no-go - so finding a way to properly support a “team” of some kind, while still compensating them fairly is an interesting challenge.

3 Likes
82

Thank you so much for your work and your input.

I have a question… would it be possible, to keep all language/client interfaces, have them all organized in a central location, have them all updated, and along with having the ability to compile for multiple platform architectures, similar to the Faust setup.

Something that would make SC attractive to everyone, by centralizing all of the different efforts, to port it to x y z, compile it to x y z… making SC more universally interoperable as a whole.

83

I think something like a “SuperCollider foundation” that bridged efforts across multiple clients etc. would be beneficial in a lot of ways. But, the honest truth is - it is VERY hard to make this kind of project succeed in the open source world.

There are very concrete things that can be done in this direction right now, though - for example, there’s lots of community bridging that can be done with other SuperCollider sibling projects. Spending time on other forums, and encouraging other communities to spend time / establish a presence on scsynth.org is a great start. Reaching out to include other communities in SuperCollider development and testing efforts is another easy win.

1 Like
84

I feel like SC4 should be something as having more of a DAW look & feel, and functionality, should run as smoothly as any one of the modern day production packages… Ableton etc… with click to install plugins, extensions, interfaces, modules, drag & drop, click to create tracks, busses, buffers, fx racks, synthdef / instrs, presets, templates, graphical envelopes, LFO’s, sidechain compression, a master track, rendering options, server options implemented as a graphical interface, pattern objects used as sequencers… and so on… and with multiple client interfaces, existing either as extensions, or included in the main installation package… sclang being the main/default scripting language.

85

It’s fine to brainstorm, but: I think would be a mistake to try to turn SC into a DAW.

DAWs are big and complicated. “… should run as smoothly as any one of the modern day production packages…” :laughing: Well, I guess the cynical view is that none of them runs very smoothly (as I see when my students come in for a lesson and it takes 3-4 minutes to open a project – or, search for “<name of DAW> crash”). But more to the point – it’s easy to say “it would be nice if…” but to make SC look and act like a DAW would be a massive amount of work. If the community is going to invest in this massive amount of work, then the return on the investment had better match up.

But… The DAW market is already saturated: Ableton, Logic, Pro Tools, Cubase/Nuendo, Fruity Loops, Reaper, Ardour, Waveform (formerly Tracktion), Bitwig, Digital Performer, Reason, Renoise, Studio One.

SC has a unique position in the audio-programming landscape. Joining the DAW market would sacrifice a chunk of SC’s distinctive identity – and, let’s not kid ourselves, SC DAW 1.0 would inevitably be full of bugs (due to the complexity), which would alienate potential users. SC has not much to gain and a lot to lose that way.

If you want to see a large graphical system implemented in SC language, check out TX Modular. There are absolutely brilliant ideas in here. But, the interface is clumsy in some places and often sluggish to respond (due to limitations in SC GUI widgets and the general slowness of the language), and I’ve also seen it crash for reasons I could never identify. That’s kinda where we are with sclang big-systems. Reality check.

For the intersection between DAWs and programming, IMO it would be better to integrate programming features into an existing DAW. Ableton is ahead of the pack by integrating Max (even though Max is… erm… flawed conceptually). Reaper allows the EEL2 language to be JIT-compiled into plug-ins, which is perhaps even better. (It’s unfortunate that Reaper seems to be a niche DAW; it probably shouldn’t be.)

The other aspect of the question is: Could some elements of DAW design be implemented as SC objects to use in code? The answer is yes. The ddwMixerChannel quark has been around for 15 years – but one of the problems is that there’s no way for incoming users to know about it. So it’s underused, and everybody struggles with designing their own mixer when they could have mixers, inserts and pre/post-sends for free, right now.

hjh

6 Likes
86

I totally agree.
I like SC precisely because it isn’t a technicolor slotmachine DAW, with deeply embedded workflows which inevitably steer the user to make generic four on the floor techno bangers.

Also, the gui stuff is there in SC, so when folks feel they need it, that is available to them. Also Ndef style “throwaway guis” are nice for that kind of stuff I think.

Enough of this negative style rebuttal tho!
I also want to say that I am totally about increasing all kinds of creative freedoms of expression to the absolute maximum!

I did a course for SKH a while back called SC4Reaper. In that material I walk through setting up SC and Reaper to be BFFs and to work together in different ways, the hawtest of which I feel is OSC control. For me that is the ticket. Controlling Reaper from SuperCollider using OSC. This way I feel like I am getting the best of two worlds.

5 Likes
87

As a side-note: an interesting intersection of DAW meets programming seems to be the radium tracker (https://users.notam02.no/~kjetism/radium/). I’ve just started looking at it, but it seems very powerful, with built-in live faust for synthesis (in addition to loading sound fonts and supporting midi), and scriptability in scheme and python 2 (the programming part), as well as user interface for entering notes and automation curves (the DAW part). Independent of how cool it all looks and how flexible it probably is, I don’t see something like this as a desirable future for supercollider since it imposes certain preconceptions of how music is supposed to be organized (it’d be cool if they could also include supercollider in addition to faust of course :)).

3 Likes
88

Part of the reason for creating Mellite in the first place was to be able to programme like in SC, and also be able to arrange materials like in an electroacoustic composition, resulting thus in a DAW/programming cross-over (timeline editor), even though it is not (and doesn’t aim to be) as comfortable and complete as a native DAW. So you can place audio file snippets and sound objects on a timeline, but still open them to code the actual DSP.

1 Like
89

Reaper’s scripting is not limited to DSP, it also allows for full-fledged DAW scripting with EEL2, Lua and Python: https://www.reaper.fm/sdk/reascript/reascript.php

You can also add new functionality with C/C++ extensions: REAPER | Extensions SDK

REAPER also offers custom extensions for VST plugins.

For an extreme example, have a look at the “Playtime” plugin, which turns Reaper into something like Ableton Live: Playtime - Home

90

I totally agree with that. DAWs are fine for doing some standard tasks smoothly (I didn’t want to be forced to do mastering in SC) – but they are structured in a way that tends to exclude many things and strongly suggest others (e.g. the preference of sequential fx processing in most of them), not at least with aesthetical implications (bar preference in many cases). In others words, they tend to narrow musical thinking – in contrast to the super abstract and versatile concepts of a programming language like SC.

Very likely!

I’m a bit surprised by that observation, polls partially confirm, partially contradict it ( https://sleepfreaks-dtm.com/en/dtm-materials/2020-daw-ranking/, GitHub - smadgerano/DAW-Usage-2020: Results of Reddit polls for how people are using their Digital Audio Workstations). To my impression, at universities and electronic studios it has become a quasi standard at many places, especially for people working with 3D audio as it’s very supporting in this regard.

3 Likes
91

Side note while we’re here - NRT one area where SC falls short of DAW users expectations. in DAW-land the ability to render or freeze tracks compositions or items and pre-processing of FFT or other info in the background are standards. Recording in SC is not so bad (interface still a little clunky) but NRT requires a different syntax and is opaque - Ctk and ScoreClock are both possible ideas to make this friendlier - it should be a low friction operation.

and FWIW REAPER is gaining ground in the audio post world (where I earn the odd dollar). I drive it via osc from SC for scoring.

@Rainer check out Lnx Studio LNX studio poll results or
GitHub - Sciss/Mellite: An environment for creating experimental computer-based music and sound art.

2 Likes
92

Perspective from a relative neophyte here… I’ve used SC for maybe four years, and I’m not a particularly heavy user nor by any stretch a power user. I am not a programmer by training, though I have done some programming in various engineering contexts. Some things that I have liked about SC3 that I would miss if they went away…

  1. The integrated IDE is immediately intuitive and useful. Adding new steps for non-programmers to get a different IDE up and running seems like an unnecessary deterrent. I probably wouldn’t have screwed around with it.
  2. There is a huge wealth of existing material, tutorials, and guides to the language. The Patterns guide alone saved me countless hours of grief and opened up tons of new ideas for me. Anything that is not backwards-compatible both wipes out existing work people have done and eradicates the value of an enormous amount of existing knowledge to get new users educated.
  3. The idea of DAWifying SC is horrifying to me. A big part of the reason I like using it is specifically because it’s not a DAW–it’s not graphical, you don’t have to click around in a bunch of stuff, etc. It allows me to work in music without a strong visual component, so I can hear with my ears instead of my eyes, as they say, and I vastly prefer sequencing and arranging by typing than by clicking and dragging stuff.

The biggest thing I’d like to see changed is simply, like @jamshark70 said, better syncing capabilities between SC and other software. Right now I get SC output into my DAW by either MIDI or audio loopback software. MIDI timing is often horrible, because it runs language-side (as I have recently been educated), and audio cannot be synced to anything. Or at least I haven’t figured out how. So a lot of the time I record a bunch of stuff into my DAW and then use tempo detection to match the DAW tempo to the audio and whatnot, and while that is a workaround that gets the job done, it’s a pain in the ass and must be repeated every time I change the arrangement or whatever.

Since I’m not a programmer by trade or by training, and my SC projects are not very large, I can’t speak to the value of changing the language; but I sure appreciate the existing language and I would miss it if it were retired.

9 Likes
93

I also agree. Keep SC slender and code oriented. Code is less comfortable for those with little time in their hands but more than recompenses with its immense exensibility and clarity. A main advantage of SC is its power as a language to model many very different approaches to composition and performance. We should keep that at all costs.

Iannis Zannos

5 Likes
94

My 2 cents on new features I would like to see:

having non-realtime (NRT) mode fully working like the realtime (RT) mode.

Of course the NRT is working properly, but its language implementation is too verbose when compared with the RT (e.g. there is no SCTweet made using NRT nor we have an {}.render when compared with {}.play) and some crucial features are missing (e.g. it is not strictly possible to interchange data back and forth between the server and the client). Moreover, although it support patterns, IMO its general usage is too much CSound oriented.

IMO, having more, flexible, easy and well documented possibilities of blurring the boundaries between NRT and RT (e.g. doing soft RT analysis of an instrumentalist’s buffered execution or playing samples from a big audio dataset while it is being analysed) would make SuperCollider the perfect playground!

1 Like
95

this is noted here: a new NRT mode with full OSC socket · Issue #279 · supercollider/supercollider · GitHub and closed for unknown reasons (I guess since it was stale - I think it should still be an active issue)

1 Like
96

It needs someone to take the lead on implementing it. About 9 years and no one has stepped forward.

hjh

97

Well, I think there needs to be a distinction between “closed - solved / won’t solve” and “closed - for future exploration”. the comment suggests it’s on a future project, but the project page of GH doesn’t have long term tickets, either. :woman_shrugging:

1 Like
98

Perfect argument… a lot of excellent points have been made here.

99

Members

&

Authors

100

There are (monthly?) developer meetings noticed here - Developer meeting polls - and minutes show up around here somewhere as well - seems like 3-5 folks, not always the same, attend. I’d encourage any of you in this thread with chops and time to jump in.