SuperCollider 4: First Thoughts

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).

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++ ?

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

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.

3 Likes

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

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 :slightly_smiling_face:

2 Likes

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

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.

Good. A more visual max msp?

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

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.

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

1 Like

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/

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.

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 :slight_smile: )

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

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

1 Like

First tests with classical digital filters and Dear ImGui interface, all pure haskell, works fine and dandy.

The sound doesn’t use supercollider, because it’s simple enough. But integration with supernova will have to happen of course.

Eventually, that will surpass SuperCollider 4 (that’s actually SC5) with the power of lambda calculus and God, of better yet, Alonzo Church!! :joy: :joy: :joy: :joy: :joy:

1 Like

Shenzhen (China) is 70% less expensive than New York and is doing more advanced engineering work today than anywhere else. New York is pure decadence (I consider myself a bit New Yorker so don’t be offended there). Would be interesting to know more about how free software happens there. I’ve been told that among companies, they share a lot (and probably use another term, of course). Let’s expand our community, which is international already.

This is true, we will never just “replace” sclang. We might create new things, borrow sclang ideas, etc. Changing syntax is not the end of the world. It’s life.

I just disagree with comparing it to Lua, which is a very poor language. The author himself is very humble about what the language is (he is from Brazil. I’ve seen a few interviews/talks), and he is always talking about Haskell, he wanted to write a research and feature-rich instead, deep down.

Lua is a very simple language, but I wouldn’t call it poor. I find it rather elegant. The C API in particular is ingenious.

1 Like