• Audio

  • Realtime audio drivers in Rust

giuliomoro the only thing that relied on dynamically linking to Bela is Supercollider, which I also maintain and which didn't set that specific flag.

Rust links shared libraries by default AFAIK, but it should be possible to change this. The allocation functions for the settings struct aren't used yet though, but doing that shouldn't be to complicated either.

giuliomoro you mean which values are valid for stopButtonPin? Any value is "valid". -1 or any number >= 128 are considered "off", values between 0 and 127 are considered "on" and the value is the pin number that will get monitored.

Ok, but can any value in [0, 128) actually be used? What if something else is assigned to the pin as well?

giuliomoro currently you can do it only in a limited way by setting e.g: --board=Bela (or .board = BelaHw_CtagFace) to only use 4in/8out when a CTAG Beast is also connected... But as usual there are other higher-priority things going on

What happens if you set a board that isn't present / available (i.e., Bela when only a Beast/Face is used or BelaMini on a Bela)?

          l0calh05t What happens if you set a board that isn't present / available (i.e., Bela when only a Beast/Face is used or BelaMini on a Bela)?

          it will fail and not start. See https://github.com/BelaPlatform/Bela/blob/master/core/RTAudio.cpp#L452-L479

          l0calh05t Ok, but can any value in [0, 128) actually be used? What if something else is assigned to the pin as well?

          It will let you do that ... if you end up picking one of the pins that the Bela Digital channels are on and you set it to an output, this will affect the readings, but if it's used as an input, it will work. There are no checks to avoid any such clashes, we just make sure it doesn't crash. It's up to the user to select a pin that makes sense. Again, most likely this is just for those who want to spin their own board or something like that, not really for day-to-day usage ...

                Just a quick update: bela-sys now uses a BELA_SYSROOT environment variable instead of having to place subsets of files into a Cargo-internal folder. So just extract partition 1 (/) of the Bela image to a folder of your choice and point BELA_SYSROOT at it (in theory it should also build on the Bela itself, assuming cargo and rustc work on it). This should work much better when crates depend on bela-sys. Furthermore, static vs dynamic linking of bela is now switchable via a crate feature static and the hello-example is now a proper example (meaning its dependencies are now dev-dependencies!) and not the main.rs of a "hybrid" executable/library crate.

                If you want to try out my branches of bela-sys or bela-rs, add

                [patch.'https://github.com/andrewcsmith/bela-sys.git'.bela-sys]
git = "https://github.com/l0calh05t/bela-sys.git"
branch = "bela0.3.8b_rust1.52.0"

[patch.'https://github.com/andrewcsmith/bela-rs.git'.bela-rs]
git = "https://github.com/l0calh05t/bela-rs.git"
branch = "bela0.3.8b_rust1.52.0"

                to your Cargo.toml and add the original version to your dependencies. (I didn't change any of the URLs in case @andrewcsmith is interested in merging these patches)

                Would you mind doing a PR for this so we can get it merged upstream? I'm not sure Andrew is looking at this forum.

                I'm on other parts of my project (doing all the analog bits), so I didn't update the board and didn't recompile anything for quite some time now, so this went unnoticed.

                fwiw, cargo and rustc work well on bela, but it's horribly slow. I was doing it on the device initially, but since it's so easy to cross-compile with rust, I ended up compiling on my laptops and sending the binary.

                We can also figure out the dasp situation, surely there is a way to sort it out.

                  padenot Would you mind doing a PR for this so we can get it merged upstream? I'm not sure Andrew is looking at this forum.

                  Done 🙂

                  padenot fwiw, cargo and rustc work well on bela, but it's horribly slow. I was doing it on the device initially, but since it's so easy to cross-compile with rust, I ended up compiling on my laptops and sending the binary.

                  Yeah, I suspected as much and decided against trying it

                  padenot We can also figure out the dasp situation, surely there is a way to sort it out.

                  With the new min_const_generics feature, it should be possible to have a generic implementation where the proper compile-time channel counts is selected at run-time from a fixed set of known channel counts. Without such workarounds AFAICT not without changing dasp itself to support run-time variable channel counts.

                        16 days later
                        a month later
                        15 days later

                        l0calh05t Oh cool! This is great. I really look forward to your next post and reading about getting bela-sys and bela-rs working and happy.

                        I'd be happy to help make a tutorial for Mac and Unix users as well.

                            5 days later
                            12 days later

                            djensenius You're welcome! And thank you so much for the show of appreciation! Blogging and tweeting can feel a lot like talking to a wall when you only have a handful of followers, so thanks for the motivation to continue

                              12 days later