Audio Programming in Rust?

General
21

I’m pretty sure Rust doesn’t allow this, but I’m not 100% sure.

22

Always a good starting point: rust.audio and Ian Hobson - An introduction to Rust for audio developers

3 Likes
23

Just discovered someone wrote up pure data bindings for rust: https://github.com/x37v/puredata-rust and they created some macros and build scripts for making externals. Unfortunately something’s up with the packaging and I wasn’t able to get it fully working last night (building worked but doesn’t output a useable .pd_linux), hopefully better luck today!

6 Likes
24

figured out the build step, it was entirely naming.

  • name of binary has to match name of external ([package] name and [lib] name in Cargo.toml also affect this, and I haven’t found a pattern to how underscores and hyphens are treated.)
  • on my machine anyway, pd builds end up with .l_amd64 extension which needs to be changed to .pd_linux.
  • for the future I’ll be modifying the provided cargo-make Makefile.toml per-case
2 Likes
25

No, Rust doesn’t permit this in the way I think you’re thinking of. However, Rust does have the capability to load shared libraries, so if you put the dynamically-reloaded code in another crate, you could compile that crate as a shared library and reload it periodically. You’d have to use the C ABI though, and some unsafe code to glue it together.

(Oops, necromancy, sorry - but a search brought me here so I figure it’s a useful answer for others.)

1 Like
26

Still somewhat of a current concern of mine (yes, my hobby projects run at glacial slowness).

Could be quite interesting to experiment with safe rust ‘modules’ which plug into an unsafe (but tested) core runtime (already) written in C. Faust is another language which is ideal for this, but obv rust would be a lot more general purpose. I guess this is pretty similar to the use case of rust in Linux device drivers…

Thanks for the necrobump, good to think about rust again - I need to keep up to speed with new developments…

1 Like
27

This is a really fascinating idea - similar to how VCVRack works, for instance. I would love to see a comprehensive runtime for audio work that has bindings in, say, C, Rust, and Zig. It would really open up the newer systems programming languages to the world of audio.

That said, the fundamental considerations of these languages are quite different. What is trivial in Rust (polymorphism, for instance) can be quite difficult in Zig or C, and vice versa (arbitrary graph structures, for instance, or memory mapped IO, are not so simple to use in Rust) so these bindings would have to be quite low level.

I’m glad it’s a helpful bump, ha. Not to shill, but if the latest developments are what you’re after, may I recommend Programming Rust, 2nd Edition [Book] ?

Holy heck, thanks for bringing this to my attention! What a fascinating idea. I wonder if we could get together a Lines study group for Faust?

2 Likes
28

Please shill. Super cool that you’re one of the authors of the second edition! Curious about how you got involved and what the writing process was like. What’s new in the second edition?

3 Likes
29

As with many of the best things in life, it came down to a bit of a coincidence. The last conference I attended before the world went on pause was Rust Belt Rust, where I met a few people from O’Reilly. Once they’d decided to do a second edition on the Rust manual, they offered me the opportunity to work on it. It’s been a lot of work, not less because Rust releases on a schedule that’s rather incompatible with publishing - very fast, that is - but it’s been really fun. Jim Blandy, who also worked on the first edition, is absolutely brilliant and it’s been great working with a Mozilla-ian on the (formerly) Mozilla language.

There are tons of new features in the language, from NLL (i.e., the compiler is less wrong about how long references have to last) to union types and many new standard library features, but probably the biggest update is the asynchronous programming chapter! It’s another concept, come to think of it, that’s likely to be pretty useful in audio programming.

In languages like Python and Go, the compiler provides a runtime that handles memory management, so that runtime can also be extended to handle task management. Async is a fundamental part of the language. This has some advantages, but also some significant downsides. In Rust, the “async” feature in the language is essentially just:

  • a new memory management primitive, Pin, added to the compiler and exposed in the standard library, which permits self-referential types to be described safely
  • a new pair of keywords, async (as part of a function signature or block prefix) and .await (as an r-value suffix), which make concurrent programs look linear
  • a standardized Future type (and some associated utilities) which facilitates communication between libraries that have async interfaces

All the rest - exactly how tasks are managed and executed, scheduling, waking, etc., as well as actual async interfaces to I/O and OS functions, are outsourced to libraries. This means there are tons of fascinating approaches which are all equally viable and can even be mixed and matched to some extent.

I would love to see, rather than the currently-common throughput-focused approach (which is great for servers), a more latency-focused async ecosystem for audio and video synthesis in Rust. There are some experiments in this direction, but it’s still in the opening stages of development.

9 Likes