From: Karl S. <kd...@pr...> - 2021-01-11 14:55:49
|
Hello Faust friends, I am considering using Faust with Rust in an embedded system in a musical instrument. I've been using Faust for a few months and have found the learning curve shallow (I had some prior FP experience). Rust is even newer to me and has a much steeper learning curve. I am also new to developing complex designs with microcontrollers, although I do have previous experience programming them. It is challenging for me to evaluate the feasibility of the project, given that I may be guided by misconceptions. I expect to learn a lot. The application is a digital sampler combined with an analog synthesis/processing engine. I wrote a blog post detailing the story behind the idea: https://schultheisz.com/2021/01/08/recursyn-analog-resampling-synthesizer/ I've done lots of research for this project already, but let me know of any pertinent information resources. I am now integrating the compiled Faust code with the main Rust code. I chose not to use an architecture file, as the Rust build system already has a method of generating code at build time. In an embedded system, it is usually preferred to avoid unnecessary heap allocation. The FaustDsp trait assumed by the Faust compiler provides certain details at runtime which are known at compile time. Specifically, the numbers of input and output channels are returned by functions. Upon inspection, the functions (get_num_inputs and get_num_outputs) return constants. I suspect that for all Faust programs this is true. Faust itself also leverages compile-time checking, so I find this implementation curious. But given the low volume of Rust posts in the mailing lists, I guess that the Rust backend isn't used very much and isn't a big priority. If the Faust compiler could be modified to generate this information as constants, then the Rust compiler would know the input and output buffers sizes at compile time. That would allow it to check that the compiled Faust code agrees with the way it is integrated. For instance, the mapping of channels to I/O peripherals could be checked. I'm not sure what it would take to change this behavior, but depending on that, I might try to contribute such an enhancement if it would be welcome. Karl Schultheisz |