I think right around the time when I watched his video, I got my risc-v CPU inside an FPGA working, including interrupts. I was very hyped about building such a mouse with it, just to prove to myself that my CPU can actually do something "real". It don't need to be the fastest, lightest, smallest, but a small robot that can solve a maze would be cool.
Then I tried to lay things out and realized how much more work that'd be, so I dropped the project (for now).
One day I'll build one though! It's only a matter of years, I think.
Wow, these mice were a lot faster than I expected. In the last part of the video, they talk about fans in the mouse that suck the mouse to the ground to prevent slipping.
The first time the video shows a mouse, I was annoyed by them showing a very clearly sped up recording, which made it difficult to follow. Only later it dawned on me that it's real time, not sped up.
[1] It'd be great if I could annotate part of the tab as a riff, phrase, or other section, give it a name, and then loop, repeat, jump around amongst riffs in a song (or even multiple songs).
[2] I've always wanted the ability to play a section of the tab as clicks (not notes), just to be able to hear and feel the intended rhythm of a section.
Rust is the language I am the most proficient at this point, so it was a natural choice for me.
Tuxguitar is written in Java and works perfectly fine TBH, even if Rust has clear advantages for high performance software it does not matter that much in this context.
Everything is a tradeoff. Iced is blazing fast, with a low memory footprint (~30MB binary), cross platform, extensible and pretty elegant if a bit challenging to learn.
Your job is to make your users happy. If you spend 2x the amount of time to build a blazing fast UI compared to a normal speed UI, then the question is if you maybe had better spent the time on things your users wanted, like features. Features are not everything, but code that is faster than necessary (or has lower memory footprint) just doesn't bring much to the table from the user's perspective, especially for UI programs. If you were writing an OS kernel or a browser, then maybe (probably even) Rust is a better choice.
For audio software like this, using a GC-free language translates into reliable, stutter-free, low-latency playback, particularly on lower-power devices. A lot of JavaScript-based audio things I've tried, even really simple ones, become miserable experiences once GC pauses start consuming a lot of CPU. I think it's no surprise that GC'd languages are unpopular for audio applications!
No, why would you? Normal OSes are pretty good at doing reliable audio playback and recording, musicians wouldn't use them otherwise. They don't guarantee five-nines but who cares. They are unlikely to ruin your audio experience.
Awesome work! It would be super cool if this could somehow run as a WASM module. Was thinking I would then try to include it in Freetar [0], for example so it can be used to play the tablatures on a page like this: https://freetar.de/tab/joni-mitchell/a-case-of-you-chords-95...
