SuperCollider 4: First Thoughts

Where did you hear that? This doesn’t make much sense to me. Even if that was true, there is no reason why he couldn’t add more objects/features after that concert…

Miller explains in one of his older papers that he envisioned the original Max as a minimal runtime environment and expected users to write their own abstractions/externals. He carried this philosophy over to Pd, while Max/MSP went for the “batteries-included” road (Pd’s minimalism wouldn’t work very well as a commercial product).

I think the real reason why Pd is so minimal is that Miller is the sole maintainer (besides a handful of contributors) and he wants to make sure that he is able to understand and maintain all of it. (I don’t think there is a single person on this world who understands all of SuperCollider :slight_smile: )

BTW, Miller just recently managed to get Pd (without GUI) running on the ESP32 WiFi board with only 512 kB of RAM!

2 Likes

He says in a podcast that he had been working on data structures, but with a deadline approaching, he ended up putting in Max style objects because he knew it would work. I guess I’m incorrectly extrapolating from this.

I wasn’t aware of the older paper and I appreciate the correction. (If I’m wrong and subsequently corrected, then my knowledge improves, which is a good thing.)

FWIW I suppose the ideal balance is somewhere in between Pd and SC. That Pd lacks a built-in bandlimited sawtooth generator strikes me as excessively dogmatic about minimal core. OTOH, when I find for instance that SC’s Integrator accepts only control rate for the coefficient (???) then I think SC might be better off by removing convenience UGens like this and using FOS (First Order Section) instead, reducing the surface area required to test (Integrator = FOS.ar(in, DC.ar(1), DC.ar(0), coefficient_ar)).

hjh

I guess a rich text editor could store to markdown, but I’m not sure the Qt one will do that.

It does!

I think QTextEdit is what QCollider and ScIde currently use for text editing, and:

QTextEdit is an advanced WYSIWYG viewer/editor supporting rich text formatting using HTML-style tags, or Markdown format.

I guess the interesting question would be delimiting the scope of the syntax highlighter.

Perhaps the outer parentheses did this in the old SC?

I opened the below as a placeholder in case anyone else is interested in this.

Also, if the editor has structural elements (ie. as in Html or Markdown) then syntax highlighting would be very easy! It’d just be applied in “code” blocks, however they’re delimited. Plus maybe a command for highlighting “in paragraph” codes.

https://github.com/supercollider/supercollider/issues/5556

Cleaning up the docs won’t require another major version, but we want to get it done before we get there.

The expansiveness of the core library is a great virtue… with the side effect of making itself a particular challenge to navigate, in certain cases.

Before stepping aside for a moment, a more in-depth report of SC’s user survey:


Greatest difficulties:

Top result: tutorials & documentation

Requested development efforts:

Top result: tutorials & documentation

The preceding question appears to be a summary of category groupings for responses to a free form version of the all the questions that comprised the greater majority of the entire survey… user interest regarding areas of potential future development.

The result ratings for these questions can be shown in their entirety by using only a single image or inforgraphic, serving as the grand takeaway concentrated gem of information, from over 11,000 questions & answers.

Here are the results for score ranked features answered by every user in the survey:

…while being dead last on the list, the support for Ableton Link (see LinkClock) is still a victory none the less.

While nearly all of the features could be reliably implemented without a major version update, the outstanding exceptions seems to be support for VST plugins as well as standalone applications.

If both of these implementations were included as cleanly polished & functional interfaces… this in itself would be mark a huge distinction from SC as it is at present.

Not to draw relevance from the evolution of how the community currently feels about this; I find these two features to be the highest demand overall, and while apart from being distinctive in nature, VST & Standalone have captivated my interest rather naturally, since I first began using SC.

Standalones were once possible on OS X, and as @jamshark70 mentioned, the critical issue with these involves licensing… and a similar issue exists for VST that also involves licensing related complications.

The necessity of popular demand may work as a catalyst for the next prefixed version release of SC… this in itself would require the licensing updates to reflect only the identifying and applicable versions of future releases.

1 Like

I don’t see why these features would need a major version update…

Regarding VST plugins: I’m not sure if your’re talking about scsynth hosting VST plugins or scsynth as a VST plugin.

The former has been possible for a couple of years now (VSTPlugin v0.5.1 - bug fix release!). I’m pretty sure it is better kept as an extension.

For the latter we only need to add a generic “plugin” audio driver (similar to the existing AU driver, but not restricted to a specific audio plugin API) and then people can build VST plugin frameworks with libscsynth, just like people already do with libpd (Pure Data). Actually, scsynth already works as an AU plugin, so there is no reason it couldn’t work as a VST plugin as well.

and a similar issue exists for VST that also involves licensing related complications.

The VST3 SDK and SuperCollider both are licensed under GPLv3, so there wouldn’t be any issue.

2 Likes

The issues with licensing are 1/ the wish to release a closed-source standalone based on SC – in practice the GPL prohibits this – there is no issue with GPL-licensed standalones; and 2/ the wish to link SC tightly with non-GPL frameworks.

There’s no blanket prohibition against standalones as such.

As for reading the survey: The number of users requesting a feature is only one factor affecting the likelihood of it being implemented quickly. Others are urgency/severity (e.g. crashes are severe, while the lack of code folding is annoying but won’t kill anyone) and complexity (Ableton Link was less often requested but relatively easy, while step debugging is commonly requested but requires deep understanding of interpreter internals, which I’m not sure anyone has – a difficult feature may not be done quickly even though popular).

Basically in a volunteer team, someone has to take it on. So individual developer interest is another factor.

hjh

2 Likes

Out of curiosity (noob in this field), would it make sense to use other widget toolkit than Qt ? Is there something more modern or more cross platform available ?

Would it be possible to expose the users to a GUI making processes that allow some per-defined standards (color pallets, default and auto placing, fancy and varied graphical objects styles, etc) ?

I’d be thrilled if it was possible to be run SC on microcontrollers, e.g. Teensy, Daisy, or some
custom STM board. My use case would be to build standalone instruments without needing the overhead of running an entire OS. Could that be within the scope of a future SC version? Would it require a major rewrite or is it perhaps even possible to do this with SC3 with a few changes?

Some learnings from a LOT of investigation of cross-platform application gui’s in the last years (on projects other than SC)

  • There are basically two well-supported stacks for building open-source-compatible UI frameworks: web technology (e.g chromium/electron/skia) and QT/QML.
  • Web tech:
    • Generally has better documentation/tooling/resources available, and better overall design patterns.
    • Building web tech UI’s introduces heavy dependencies on supporting libraries like React, which are very fast moving and tend to have poor backwards compatibility. This would have the effect of pushing a lot of burden on SC developers to maintain complex webs of dependencies and frameworks, and potentially fragment the SC ecosystem (e.g. you can’t get help from the community with your React UI if everyone else is using Angular).
    • Web tech may not always be ideal for (a) high-framerate animation of e.g. level meters and visualizations, and (b) low-end embedded platforms. This is likely to get much better in the next few years, because the web tech development ecosystem is so large.
  • Qt/QML
    • Fewer online resources, training, etc. - knowledge is very specialized, whereas MOST people that have written code have at least done a little bit of web dev.
    • Qt tends to have good backwards compatibility: SC can use QT UI code from 7 years ago and should basically work and look roughly the same. This is helped by the fact that you can build sophisticated UI’s with no external dependencies (vs web tech).
    • Qt as a business heavily prioritizes embedded/mobile platforms, so better chance of good support in these cases.
    • QML provides decent design patterns for UI building - at the very least, they are consistent and straightforward for building small projects, which is positive for the SC user base and makes it easy to ask questions and share knowledge.
    • QML stack is more performant for audio use-cases (e.g. high-frequency animated updates) vs web tech.
    • sclang is current bound to the C++ Qt widgets rather than QML. These are supported but basically frozen, and many of the benefits mentioned above to not apply to the C++ widgets. So, the primary benefits here would entail moving to QML for UI in the long term.
3 Likes

Moving to QML would be very interesting, because we wouldn’t be restricted to only a subset of Qt anymore and instead can write arbitrary GUI code, right?

Yes - maybe to state it a little differently: you can do almost everything you want with QML controls using JUST the properties/signals/methods that are exposed the QT’s metaobject system. These come mostly-for-free to sclang, so the cost of porting is quite low in that sense, and we get a lot more. QML is performant and fast to write - I’ve written a mock DAW entirely in QML in a week - so the possibilities for UI building are radically expanded.

But: if you’re building a QML UI, you will probably do it mostly in QML rather than writing lots of logic and assembly things in sclang. Probably the right path forward here is to:

  1. Provide no built-in backwards compatibility with old sclang UI classes (if someone wants to quark this, people might find it useful, but maintaining this in the core is too labor-intensive).
  2. Provide a solid design pattern for how to build and connect QML UI’s to sclang code. It is REALLY easy to build a confusing rats nest here without some design patterns, and the resulting developer experience will be really bad.

I’ve got proof-of-concept code that exposes QML to sclang, it’s really #2 above that’s the major issue.

1 Like

AFAIK the first (?) Gui system for SuperCollider was FLTK, which is crossplatform. It’s not fancy, but minimal and that’s maybe a thing I do miss a bit in this discussion. I’m not sure if huge rewrites brings it further. A KISS approach might safe both work and headaches. Simple stupid, could mean, just keeping QT in this case I guess… :slight_smile: A other toolkit that comes to mind is Juce. (Cabbage for Csound is Juce IIRC).

It sounds like you’re referring to using an outside program, maybe controllable through SC-IDE, that’s not packaged with SC-IDE to create GUIs, right?

If so, could something like this be a few/bunch of convenience methods that format sending and receiving OSC, or other relevant serial protocol, to interconnect with external GUI software? Maybe this is what you mean already…

Some sort of simple parameter mapping possibilities, on the SC side, linking buses, or similar, to keys which represent GUI elements would be pretty cool.

This could also be extended to also for easier interconnectivity with things other than just GUI objects.

I almost passed this by… this however looks fantastic.

Thank you for your work.

As far as the licensing-related complications… expertise in this field proves to be an extremely valuable asset to the community.

There’s a headless standalone SC environment for rpi made by @redFrik, if you’re interested.

Is there anything else in this direction that we know of?

This would definitely be something built-in to sclang. Running the UI as a separate application adds a lot of complexity and potential for instability, and I’m not sure if there’s really much benefit for most users by running out of process.

Looking a little into rich text editing in Sc/Qt recently I saw:

https://doc.qt.io/qt-5/qtquickcontrols-texteditor-example.html
Qt Quick Controls - Text Editor

which led to this longish thread from 2012:

http://www.listarc.cal.bham.ac.uk/lists/sc-dev-2012/msg46777.html
[sc-dev] QuickCollider - a possible future for GUI in SuperCollider

and this archive (last edit 2015):

https://github.com/jleben/quickcollider
QuickCollider, an OSC interface between QML and SuperCollider code.

and this issue (from 2016):

https://github.com/supercollider/supercollider/issues/2559
Re-designing the supercollider UI using qtquick in qml

It seems like you’ve perhaps done the thing Tim suggests in the issue above?

Do you think this would allow adding a rich text editor view to Sc from within Sc language?

(I.e. starting from the Qt example code above?)

Interesting. A lot depends on how easy it is to bind the osc sending and receiving messages probably.

Of possible interest from the CSound world: Clang Opcodes

The Clang opcodes embed the Clang/LLVM just-in-time C++ compiler into Csound. This enables a Csound orchestra to include, compile, and run C++ code as part of a Csound performance.

| scztt
September 3 |

  • | - |

But: if you’re building a QML UI, you will probably do it mostly in QML rather than writing lots of logic and assembly things in sclang. Probably the right path forward here is to:

  1. Provide no built-in backwards compatibility with old sclang UI classes (if someone wants to quark this, people might find it useful, but maintaining this in the core is too labor-intensive).
  2. Provide a solid design pattern for how to build and connect QML UI’s to sclang code. It is REALLY easy to build a confusing rats nest here without some design patterns, and the resulting developer experience will be really bad.

I’ve got proof-of-concept code that exposes QML to sclang, it’s really #2 above that’s the major issue.

Also 9 years ago, Jakob Leben, after doing all the work on the qt widgets including rewriting it all in a few months, proposed a sort of qt gui server based on QML and everybody, including me, jumped to his jugular (I’m being a bit dramatic but I’m sorry that did happen). He left the code here:

https://github.com/jleben/quickcollider