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.
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.
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.
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:
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).
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.
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… 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.
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.
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.
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:
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).
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:
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.
That’s very interesting, thanks for sharing. I met Gogins once when he came to Argentina, he works endlessly creating new things, and is also a fan of pianoteq
I knew about this other one below which seems similar in the abstraction level, but still c++ is a bit too tricky for musicians/students.
I’m familiar with the project. It still builds and runs with some minor changes. I’ve used a few of those components to test embedding QML directly in sclang, with some success.
But also many good ideas in this thread, one very useful feature to have (again) will be
– Exporting instruments/effects as plugins.
SuperColliderAU for making standalone plugins used to be a much more straightforward process. Probably taking the inspiration or continuing G.Roma’s effort and great work, an improved version of it could make it in a future version of supercollider.
Talking about compilers (and dreams) … somebody already mentioned it (maybe in another thread) the possibility to compile supercollider for a larger variety of hardware (DSP chips, teensy, daisy, STM32s, scharc, …)
// INTERFACE to sclang
bool show_demo_window = true;
bool show_another_window = false;
ImVec4 clear_color = ImVec4(0.45f, 0.55f, 0.60f, 1.00f);
float f = 0.0f;
int counter = 0;
ImGui::Begin("Hello, world!"); // Create a window called "Hello, world!" and append into it.
ImGui::Text("This is some useful text."); // Display some text (you can use a format strings too)
ImGui::Checkbox("Demo Window", &show_demo_window); // Edit bools storing our window open/close state
ImGui::Checkbox("Another Window", &show_another_window);
ImGui::SliderFloat("float", &f, 0.0f, 1.0f); // Edit 1 float using a slider from 0.0f to 1.0f
ImGui::ColorEdit3("clear color", (float*)&clear_color); // Edit 3 floats representing a color
if (ImGui::Button("Button")) // Buttons return true when clicked (most widgets return true when edited/activated)
counter++;
ImGui::SameLine();
ImGui::Text("counter = %d", counter);
ImGui::Text("Application average %.3f ms/frame (%.1f FPS)", 1000.0f / ImGui::GetIO().Framerate, ImGui::GetIO().Framerate);
ImGui::End();
I’m not so familiar with imgui, but this seems straightforward-ish. Here’s SOMETHING like the equivalent in QML:
Window {
// INTERFACE
// Accessing these properties from sc might look like:
// ~qml = QmlComponent("foo.qml").create();
// ~qml.show_demo_window.postln;
// ~qml.slider_value = 0.45;
property alias show_demo_window: demo_window.checked
property alias show_another_window: another_window.checked
property alias slider_value slider.value
property alias color: color_edit.color
property int counter: 0
property real framerate: 0.0
title: "Hello, world!"
ColumnLayout {
anchors.parent: fill
Text {
text: "This is some useful text."
}
CheckBox {
id: demo_window
text: "Demo Window"
}
CheckBox {
id: another_window
text: "Another Window"
}
Slider {
id: float
from: 0.0; to: 1.0
}
ColorEdit {
id: color_edit
}
RowLayout {
Button {
text: "Button"
onClicked: counter++
}
Text {
text: "counter = " + counter
}
}
Text {
"Application average %1f ms/frame (%2f FPS)"
.arg(1000 / framerate)
.arg(framerate)
}
}
}
The programming paradigms are quite different. QML is a declarative language: you describe your UI, but QML itself does the work to build and manage the widgets and their state. For example, when you set your text via: text: "counter = " + counter, QML knows that it needs to update this text whenever counter changes, you don’t need to perform this update yourself.
imgui is imperative and immediate - this means a very what-you-see-is-what-you-get view. This kind of UI code is much easier to debug, and likely feels more comfortable to programmers used to writing imperative code.
As a point of comparison, sclang in general is imperative, but SynthDef’s and the pattern system are closer to declarative programming.
The “immediate mode” term generally refers to UI that does not own any state by itself, and is completely rebuilt every time you need to update the display (basically: every frame). QML is definitely not immediate mode, but it’s still possible to design things in the same paradigm if you choose to - the best QML projects I’ve seen have been very close to immediate mode.
In general, QML is a full, feature-rich language for building full application UI’s, so there’s likely some power for larger projects that imgui doesn’t have. This may not matter to casual SC users.
imgui would be super appealing for a project like SuperCollider if we weren’t already fully integrated with Qt. Since we have QML basically for free, and QML is on par or better than imgui in terms of ease-of-use and power, I think it would be hard to justify switching. However, building imgui bindings for SuperCollider would be an interesting project, and I’m sure it would get some use if someone wanted to tackle it.
A other toolkit that comes to mind is Juce. (Cabbage for Csound is Juce IIRC).
| 
| 
lucas:
