RustTokioBenchmark VS glicol

> If you ever pull up a debugger and step through an async Rust/tokio codebase, you'll get a good sense for what the overhead here we're talking about is.

So I didn't quite do that, but the overhead was interesting to me anyway, and as I was unable to find existing benchmarks (surely they exist?), I instructed computer to create one for me: https://github.com/eras/RustTokioBenchmark

On this wee laptop the numbers are 532 vs 6381 cpu cycles when sending a message (one way) from one async thread to another (tokio) or one kernel thread to another (std::mpsc), when limited to one CPU. (It's limited to one CPU as rdtscp numbers are not comparable between different CPUs; I suppose pinning both threads to their own CPUs and actually measuring end-to-end delay would solve that, but this is what I have now.)

So this was eye-opening to me, as I expected tokio to be even faster! But still, it's 10x as fast as the thread-based method.. Straight up callback would still be a lot faster, of course, but it will affect the way you structure your code.

Improvements to methodology accepted via pull requests :).

Nice to see new art work in browsers!

Some comments pointed out that there are latency issues, which are mainly caused by tonejs. I used tonejs a few years ago for my first live coding project: https://quaverseries.web.app/

Interestingly, I also used the same interactive rhythm prompts as op in the page title, but the timing was not accurate at all.

Later, in order to refine my idea, I used rust and made https://glicol.org/.

It basically solved the audio latency problem, and I also made js bindings: https://glicol.js.org/

If you want to try it, you can give me feedback.

My most recommended method for beginners has always been PD (https://puredata.info/) combined with The Theory and Technique of Electronic Music: (https://msp.ucsd.edu/techniques/latest/book.pdf) and this book (https://mitpress.mit.edu/9780262014410/designing-sound/).

Eli's tutorials on SuperCollider are also very helpful: https://www.youtube.com/@elifieldsteel

Of course, my project Glicol can also be helpful for people to get some intuition on live coding in browsers immediately: https://glicol.org/

I've worked on Ambient Engine and now on the Bevy engine. I totally agree with these points, very valuable. I only make some comments from my professional (audio) perspective:

We need the highlight author's affirmation of cli. Rust's tui (ratatui) is great. I used it to make Glicol-cli [1]. If you are a Linux user, you are welcome to test the music production of the code.

Speaking of game audio, I actually think rust is perfect for audio. I have also continued to develop Glicol recently, and my recent goal (starting tomorrow) is the bevy_glicol plug-in. I want to solve bevy's audio problem on the browser.

All in all, even though I've had my share of pain with ecs, I still think rust is very valuable for game and app development, maybe not multiplayer AAA, maybe practical apps.

[1] https://github.com/glicol/glicol-cli

[2] https://github.com/chaosprint/glicol

Nice! Great project website styling and demo.

I had a WebGPU scope demo using vanila JS here, but it's not connected to AudioContext at all.

https://stackblitz.com/edit/vitejs-vite-cuc9vs

Still, I had to use the old WebGL solution for https://glicol.org since the WebGPU support seems to be pretty slow at the moment.

Suno is great and I already shared its potential back in v2. I have always believed that the essence of digital music is "organized numbers". I think what needs to be thought about is how to use AI in this process. If you look at the results (numbers) generated, then we are indeed very close. But there is another future I believe: I hope AI can compose music with me, like copilot. This is why I keep working on

https://glicol.org/

and the destination is:

https://github.com/chaosprint/RaveForce

Also want to hear your feedback.

Interesting!

Similar note-based expression can be found on TidalCycles/Strudel. although it's not valid MIDI format anymore, you can use notation like c4, f3, and make them as "pattern". Samples are also supported in the same manner:

https://strudel.cc/

And in my project Glicol, I use only numbers in the seq node. So 60 means middle C. Underscore means rest.

https://glicol.org/

I also applied with Glicol (https://glicol.org/) and got rejected, which is totally understandable. I am basically working this project on my own with almost zero extra funding.

I am currently working on a new website. The old stack is Vite, Svelte and Windi CSS (discontinued unfortunately). So this time maybe Astro + Solid + Tailwind.

And I am also trying to rewrite the whole Rust backend if possible, so there is quite some work to be done.

Let me know on GH or Discord if you are interested.

It's a good chance to try Rust, WASM, DSP, etc.

This is a really informative and inspiring article.

It hasn’t been 6 months (not 6 years) since I quit my full-time job as a Rust developer to start my own business.

As time goes by, I can feel the pressure of mortgage and car loans, and I can also feel the care and pressure of my family.

My original plan was to make an interface for Glicol (https://glicol.org), and to develop relevant hardware with firmware written in rust for school education.

I sent some cold emails to VCs, but most of them got no reply.

I also sent an email to the Norwegian Museum of Science and Technology, offering to perform for children for free, but they didn’t reply for two months. I shamelessly sent it again, and someone finally replied with a rejection.

Only one VC talked to me and thought that I should convince and validate a partner first, and he suggested that I go to an incubator.

Very good advice.

Later I learned that even Norwegian education startups skipped Norway and focused directly on the US market.

People from the incubator also told me that it is impossible for Norwegian schools to accept new things independently.

This is very enlightening to me because most of Glicol's visitors are indeed from the US. And it took me so long to discover this fact.

But if I don’t start, I’ll never get past those six months.