Write patches in Rust!

Hi,
I’ve been putting together some framework code to allow writing patches in Rust, and I think it’s just about ready for other people to try using it:
https://github.com/orukusaki/owl_patch
All the basic features are implemented, and the examples patches work on my Lich using Owl2 and Owl3 modules. There are still some more advanced features to add in future - see the README for details.
I’ve not included a DSP library - users are free to find or create their own. One of the examples uses the FunDSP crate, which works ok, despite not being the most highly optimised for the Arm MCUs.

Anyway I’m not sure how many people this will interest, but if you are interested in trying to write patches in Rust, please give it a go and let me know how you get on.

1 Like

Now that is an unexpected surprise. I tried doing exactly that a few years ago, got stuck on maybe 40% mark due to running too deep into certain Rust topics I didn’t understand well at that time. Anyway, congratulations on making something that actually works.

If you’re interested in feedback, I would suggest exposing fast exp/log functions in some way, they are defined here - https://github.com/RebelTechnology/OwlProgram/blob/develop/LibSource/basicmaths.h

They use LUTs stored in firmware and accessed with service calls which you expose, so it shouldn’t be too hard to use it from pure Rust code.

Also, there’s FFT/IFFT code that uses LUTs from firmware in a similar fashion. It looks like this is a clone of relevant functions from CMSIS that you might be able to use with those tables, so no need to reinvent the wheel here or link with C library.

Unfortunately OWL itself has been in hibernation for over a year and there’s no signs that we should expect any changes in this regards. If this ever changes, I’m sure that Rust support could be added to the library.

Thanks for your response and feedback :slight_smile: I have those LUT things on my todo list. I think the big thing will be working out how they can co-exist with / enhance existing maths crates: micromath, and libm, plus cmsis_dsp as you suggest.

I’m aiming to keep my code fairly bare-bones so I’d prefer not to port over all all the maths stuff from the C repo - but perhaps compiling and linking to it will be the way forward.

One more thing to keep in mind is that those tables are considered optional, so fallback code is needed if they’re not present. In practice, LOG/EXP tables are shipped with firmware for all devices, FFT is also everywhere except Xibeca board (used for AC/DC only at the moment).

Another thing that’s worth porting from C++ OWL library is V/Oct conversion. The math itself is fairly simple, but it relies on reading calibration settings using a service call