Bitwig: Interface Performance

[carlca]

Personally, as a developer, I would love to see the codebase start to move towards Rust, but that's purely selfish as I'm excited about Rust. Short of that, it's a beta. There will be bugs. They will get fixed. The number of bets they've had to make that didn't quite pan out is very small compared to players who have been out in the world for much longer. Java and Cairo, I'm sure, can be made to work smoothly before the 4.0 GA release

Are there any Rust UI libraries which would be suitable. I suspect that Rust, like Go, is far more suited to being a back-end language. Unless you want the Bitwig team to learn Web-Assembly and have Bitwig run in the browser, I don't think any garbage-collected language is going to fit the bill.

Interestingly, the one language choice which no-one ever speaks about is FL Studio, which as far as I know is still written in Delphi, which combines being blisteringly fast, comes with advanced UI building capabilities, and does not use garbage collection (you create it, you bloody well destroy it!). I was a Delphi programmer for 20 years in a former life

[dehuszar]

I actually think going a WebAssembly route would be really great for portability, particularly given the web-midi and audio APIs available to the V8 engine. But there are also lots of projects for using QT bindings and other such strategies.

It's always a balance of being on the cutting edge but having aspects of the toolchain (or one's understanding of it --and I say this of myself; no aspersions cast) to not be mature enough vs having a fully mature toolchain that is well understood to the point where its flaws are more visible, and many bets and assumptions which were made early in the process become hard to remediate or improve.

Again not a critique of anyone's choices. My desire to see Rust have a bigger footprint in the audio world is purely selfish. But there is a rust-audio community emerging that I've been keeping an eye on.

[lokanchung]

You don't need Rust for WASM, and it's currently possible to compile C++ code into wasm. (If Bitwig is compiled with Clang, emscripten can be a option)
I'm developing VST3 plugin from scratch with Rust and there isn't any significant advantages converting existing codebase to Rust. Rust has different approaches to solving problems. Migrating wil be more difficult than rewriting things.

Rust isn't bad at building GUI, actually it's awesome along with powerful procedural macro.
(example of powerful macro: https://github.com/bodil/vgtk, it's just like jsx)
Real problems are, all the libraries out there isn't mature.And there isn't any good toolchain (language server is clunky and debugging is just nightmare)

GC isn't bad either. If it were that bad, major game engines like Unity or Unreal Engine wouldn't use it.
Everybody hate Java (including myself) but whole different Big Data frameworks are written in Java. Which proves it's performant enough for non realtime part of program.

Current bottleneck seems to be draw bound, and devs said they wrote critical parts in C++. Ableton uses Qt(C++), HW accelerated but slow as hell. FL Studio is HW accelerated and had best performing GUI. It's not matter of laungauge, but it's rather about what's being done to draw things on screen.

[docbot]

I don't really care what they use, but if switching to delphi means Bitwig is as fluid as FL, I'm all for it

[animed]

I'm developing VST3 plugin from scratch with Rust and there isn't any significant advantages converting existing codebase to Rust.

Hey that sounds great. Is your project open source at all?

In any case, what I really want to ask you is if you could briefly take a look at this.

https://github.com/makepad/makepad

Live demo

https://makepad.dev/

I think it would make the perfect gui engine either for desktop, VST's or in a web page.

But I don't know Rust or its ecosystem. I'm a C++ person, although I do know WebAssembly and JS/Typescript.

I'd be up for a collaboration.

Either way I'd be interested in hearing your thoughts and how easy it looks to pull out the rendering engine.

[lokanchung]

I'm developing VST3 plugin from scratch with Rust and there isn't any significant advantages converting existing codebase to Rust.

Hey that sounds great. Is your project open source at all?

Thanks for sharing. I took a quick look and demos look great. Renderer itself doesn't seem very hard to take out and use.

Real problem with plugin GUI is that it depends on the host. There are hardly any library that has this feature. GUI can't have own event loop and shouldn't pollute host's loop with redraw messages. Animation requires loop that means gui should be threaded. But it's not that simple that some methods should be called on host's ui thread. I'm currently experimenting with different approaches and probably make it public once I figure things out.

[coroknight]

Are there any Rust UI libraries which would be suitable. I suspect that Rust, like Go, is far more suited to being a back-end language. Unless you want the Bitwig team to learn Web-Assembly and have Bitwig run in the browser, I don't think any garbage-collected language is going to fit the bill.

FYI, rust is no more "suited to being a back-end language" than c++.

[animed]

Renderer itself doesn't seem very hard to take out and use.

TBH, if I knew how to use the code as is on a web page, but make it draw what I wanted that would be a start.

I'd like to use a web browser as a VST or DAW GUI that can be used remotely but with a rich accelerated UI instead of HTML.

Then we can ditch these massive ungodly frameworks and not have to worry about platform compatibility woes for accelerated rendering.

I know a bit how that renderer works intrrnally and it is incredibly efficient. I just don't know how to do a hello world, because I can't Rust. :/

Then I would talk to the underlying VST/DAW via WebSockets.

Animation requires loop that means gui should be threaded. But it's not that simple that some methods should be called on host's ui thread.

Yeah you have to do it via message passing.

I guess Bitwig takes that to the limit with how they implement their out of process sandboxing and also make use of shared memory regions, but I wouldn't need that.

I already put together a VST as a PoC that can run a WebSocket server on another thread for me to talk to it. That is in C++ though. So I can have a webpage as the user interface, but currently that comprises of just some crap just to test it worked.

But I like the idea of using a lightweight VST 'shell' and then separating the actual functionality outside of that. I'm not saying the sound processing should run over sockets ofc, just to be clear.

[alanpower1971]

I've already posted I have the same problems.
My (only) project is 44 channels / 700 rows big, with lot of audio/midi clips in there, tempo automation, scenes jumps and so on.
Only 10 tracks have external plugins (VSTs), which I play realtime.
I use a 8th gen i7 32GB 1TBnvme PC, very fast in everything, dedicated to this work, with no antivirus or any other sleeping tool/app not specifically needed.

I get constant UI lacks, even if - it must be said - the audio processes are quite stable and play good.
My card is a Motu 828ES with T3 interface, which is pretty fast (5ms latency), with no trips or glitches while playing.

However, the UI is NOT responsive enough but I guess the root cause is my big project...
Hope to see some improvements on v4.

[carlca]

Are there any Rust UI libraries which would be suitable. I suspect that Rust, like Go, is far more suited to being a back-end language. Unless you want the Bitwig team to learn Web-Assembly and have Bitwig run in the browser, I don't think any garbage-collected language is going to fit the bill.

FYI, rust is no more "suited to being a back-end language" than c++.

Care to back up that assertion?

Where I *did* go wrong in my previous message was implying that Rust is a garbage-collected language. It is not.

[coroknight]

Are there any Rust UI libraries which would be suitable. I suspect that Rust, like Go, is far more suited to being a back-end language. Unless you want the Bitwig team to learn Web-Assembly and have Bitwig run in the browser, I don't think any garbage-collected language is going to fit the bill.

FYI, rust is no more "suited to being a back-end language" than c++.

Care to back up that assertion?

Where I *did* go wrong in my previous message was implying that Rust is a garbage-collected language. It is not.

Rust has the same capabilities as C++. It's just as fast, uses just as much memory, doesn't have a garbage collector, and is compiled (not interpreted). You can use Rust for all the same use-cases as C++.

[carlca]

Rust has the same capabilities as C++. It's just as fast, uses just as much memory, doesn't have a garbage collector, and is compiled (not interpreted). You can use Rust for all the same use-cases as C++.

In theory, yes. I would argue, though, that in the brief few years that Rust has been around, it has tended to be used in a "back-end' context. The provision of suitable libraries, whether UI or not, will also tend to have a "self-fulfilling prophesy" effect, as well.

Are you a "Rustacean"? by any chance?

[coroknight]

In theory, yes. I would argue, though, that in the brief few years that Rust has been around, it has tended to be used in a "back-end' context. The provision of suitable libraries, whether UI or not, will also tend to have a "self-fulfilling prophesy" effect, as well.

Are you a "Rustacean"? by any chance?

I don't see what you hope to accomplish by categorizing rust as a back-end language. It's not true and non-programmers pick up on stuff like that and end up confused. Then they repeat it and confuse other people.

[carlca]

In theory, yes. I would argue, though, that in the brief few years that Rust has been around, it has tended to be used in a "back-end' context. The provision of suitable libraries, whether UI or not, will also tend to have a "self-fulfilling prophesy" effect, as well.

Are you a "Rustacean"? by any chance?

I don't see what you hope to accomplish by categorizing rust as a back-end language. It's not true and non-programmers pick up on stuff like that and end up confused. Then they repeat it and confuse other people.

Did you even read what I said? Tell you what, why don't we stick each other in our respective Ignore lists and get on with the rest of our lives...

[coroknight]

In theory, yes. I would argue, though, that in the brief few years that Rust has been around, it has tended to be used in a "back-end' context. The provision of suitable libraries, whether UI or not, will also tend to have a "self-fulfilling prophesy" effect, as well.

Are you a "Rustacean"? by any chance?

I don't see what you hope to accomplish by categorizing rust as a back-end language. It's not true and non-programmers pick up on stuff like that and end up confused. Then they repeat it and confuse other people.

Did you even read what I said? Tell you what, why don't we stick each other in our respective Ignore lists and get on with the rest of our lives...

Did you read what you said?
"in the brief few years that Rust has been around, it has tended to be used in a "back-end' context"

What did I say that was incorrect? You know what, I don't want to know.