creek VS strop

Another option is to read the file in another thread, buffer it so there's a window of samples, and sync that back to the audio thread. This is tricky, but thankfulky theres the creek crate that does this for you and has a player demo: https://github.com/MeadowlarkDAW/creek

If you're also interested in real-time disk streaming of audio then there's this crate (which uses symphonia for decoding): https://github.com/MeadowlarkDAW/creek.

Rodio is high level and likely not really suited to what you're trying to do. Rodio is nice if you just want to play sound files and don't care about the details. If you want to manipulate audio in realtime, Creek is likely a better fit. You can take a look how I am combining Creek and Rubato for realtime tempo changes in the DJ application I am writing.

I'm using this creek library from RustyDAW for realtime safe decoding of audio files. It can also record to WAV. It would likely be useful for project as well.

I am completely rewriting strop, (the code sucks, and I know Rust a lot better than when I started, so I wanted to make it a bit better structured and more idiomatic). And I like to have static analysis make sure my code has certain qualities, so I stick this:

Do you think it's an architecture for strop then? It has a focus on code-generation on platforms not well supported by mainstream compilers

Here is a project for generating code for CPUs that do not have much support from mainstream compilers. Currently supported are the 6502 and the STM8 (I'll possibly be adding others in the future, feature requests welcome).

I could use some help on my project strop. Feel free to take a look and see if it's the kind of thing you feel you could contribute to! but be aware that the quality of the codebase is poor. There's a pull request to address this though.

It is my first time of making a Rust library. Actually, my project strop has been a binary crate and only recently have I started trying to use it from a different crate. This is happening on the breakapart branch.

Still working on a big rewrite of strop.

If you're offering free help, then I could use some help with my project strop. (TL;DR: instead of compiling code, it's evolving code. And it has a focus on architectures that don't have good support from mainstream compilers, but I'm open to adding other architectures as well).

My frustration with this kind of situation (and PICs are not unique here, the 6502, CP1600 and other very low end chips have similarly problematic toolchaining) led me to invent strop, for evolving code sequences. It has some basic PIC support.

Hadn't thought of this. I even encountered it recently too.

I am still working on strop. (TL;DR alternative to compiled code, it's evolved code. Tell it which function you want and which registers to use, and it'll randomly generate an assembly language program that does what you wanted)