SuperCollider 4: First Thoughts

[muellmusik]

@cian

• Proxy Ugens - some concept of UGens that can change dynamically, so that their inputs/outputs can change. This would allow UGens to more flexibly support things like VSTs, JIT code, etc.

IIRC Nick Collins did a proof of concept for this years ago.

[cian]

Interesting. Any pointers on where/when to help me try and track it down?

[muellmusik]

@clicksonnil can you help?

[clicksonnil]

experimental Clang UGen code, precompiled for OS X 10.6, SC 3.5 only (though the source should be portable); a draft of putting an LLVM jit compiler inside a SuperCollider UGen. Uses Clang in the background to create LLVM intermediate code for compilation.

Kling Clang

[smoge]

@dscheiba

If one could dream, I think something like egui could make a nice basis for an IDE 2.0 (see demo egui – An immediate mode GUI written in Rust ) or replacing QtGUI.
This would allow to really think of an IDE more as a desk where multiple snippets and windows can be arranged next to each other, multiple people can work on the same desk, integrating visual representations, sources and feedback - video playback in IDE within a document? No problem.

I have a tiny thing working using Dear ImGui and written in Haskell, using very basic DSP code. One can feel what you tried to describe, but to make it a full system would be a huge amount of work rs))))))

But it’s true, those new immediate GUIs are really what you described. (Those GUIs are made for game debug/dev, not for making regular apps, maybe that’s why it fits audio/live coding, even this sort of smalltalk playfulness).

[flower]

@dscheiba

This would allow to really think of an IDE more as a desk where multiple snippets and windows can be arranged next to each other, multiple people can work on the same desk

Interesting, those floating widgets on a ‘desk’ makes me think of the Bespoke Synth graphical interface. But what is the ‘desk’ exactly in your story, is that provided by egui by default (for native /desktop applications)? Are there similar GUI libraries for C/C++ ?

[smoge]

@flower

Are there similar GUI libraries for C/C++ ?

Dear ImGui is C++, with bindings to some other languages. I don’ t know about egui, I think that’s Rust only. egui is prettier, dear imgui more used behind the scenes by game devs, but they are equivalent in features I think

check the galleries and demos https://www.youtube.com/watch?v=Du--cH01ZWI

[cian]

Immediate mode GUIs aren’t really a good fit for stuff like IDEs, or more complicated layouts.

They’re pretty good for throw away User Interfaces, and I think would probably be a good way to replace the existing GUI toolkit in SuperColliders.

egui is prettier, dear imgui more used behind the scenes by game devs, but they are equivalent in features I think

I’m pretty sure you can make imgui prettier. It’s just the defaults for EGui are a little better (neither are awesome in my opinion). Similar libraries are Nuklear and RayGui (both of which are super simple C libraries - and great for integrating into other languages). Nuklear is I believe a little more advanced that RayGui, though I haven’t used it.

[smoge]

Sure, not IDE, of course. But, for example, in my case on Linux, vscode interrupts the sound. It’s pretty weird. I would not use it in a performance.

This is a positive point to imgui, it’s well supported by the industry and well tested: Funding · ocornut/imgui Wiki · GitHub

[cian]

ImGui is fine if someone has developed good bindings for your environment. It’s kind of a pain to use if they haven’t (due to being a C++ library, ABI, etc).

Obviously if you’re using C++ then it’s great - but as someone who loathes the language I’d prefer not to

[smoge]

So far so good in Haskell, but I’m sure it would fit c++ better… of course…

[smoge]

@flower

a ‘desk’ makes me think of the Bespoke Synth graphical interface.

Ia it good or bed?

I see an interesting interaction with still a text-based programming, but nothing is forbidden in terms of annotation, GUI, connected graphs, etc All in the same " desk" or workspace.

[flower]

@smoge

is it good or bad?

Good. A more visual max msp?

@cian

They’re pretty good for throw away User Interfaces, and I think would probably be a good way to replace the existing GUI toolkit in SuperColliders.

Similar libraries are Nuklear and RayGui (both of which are super simple C libraries - and great for integrating into other languages).

It’s nice when you’re not tight to a language indeed I think.

[smoge]

@flower

@smoge

is it good or bad?

Good. A more visual max msp?

Another positive aspect of Imgui is that it’s not only free software, but it doesn’t depend on anything. There is no drama about what will happen with qt, for example. And many people just write their own widgets, which others can also use.

Dear Imgui and egui both have text/code editors as widgets (even with syntax colorizing) , but, of course, it’s not comparable to popular IDEs. They also have graph editors, which would be idiomatic to node connections, for example.

[flower]

This falls also in that domain more or less:
https://git.open-music-kontrollers.ch/~hp/synthpod

[smoge]

I don’t see myself programming with anything similar to PD. But the integration with graphics is something I would really much want. I think something like how APL plots their arrays, or jupyter notebooks plot graphs, or even musical scores if you import abjad. Something that doesn’t require one to waste time coding a custom GUI, but something that is part of the workflow.

The server node tree visualization in SC, for example, is very raw. It could provide more, and incorporate annotation by default, for example.

Even for debugging and optimization of short code blocks, it would be useful. For example:

https://dennis.felsing.org/ghc-vis/

[flower]

Those Nuklear / egui widgets could as well be small TUI applications in a tmux session maybe. Functioning as a from SC decoupled GUI which communicates with sclang using OSC.

[smoge]

Yes, I thought about creating a small application with its GUI. What did you think, a multi-client setup or just OSC communication with sclang?

multi-client setups need a bit more care, because the state of the server, and possibly other things, needs to be accessible both ways always.

(sorry, maybe this conversation is off-topic and should be moved already )

[flower]

One client (sclang), one server (scsynth), multiple GUI widgets talking to sclang.

[smoge]

That’s quite possible, and I believe there won’t be any relevant penalty regarding latency.