Consider re-building Mechvibes using Rust like rustyvibes?

[I7T5]

Rustyvibes @KunalBagaria
to make the app less memory consuming

[insasquatchcountry]

Rustyvibes @KunalBagaria to make the app less memory consuming

For any other MacOS users that have been having issues with MechVibes. I've been getting no functionality on my 2016 MacBook Pro running Monterey for over a month. I had noticed that Mechvibes was a huge resource hog so I really appreciate you linking to this much snappier alternative. RustyVibes was super easy to install.

https://doc.rust-lang.org/cargo/getting-started/installation.html

^first install rust and then you can use the 'cargo install' instructions from the project's readme.md

You need to didicate an open terminal window and give terminal security permissions to monitor you input (this may be a security concern seeing as Mechvibes only requires you give them access to accessibility)

[hainguyents13]

thought of it before, I'm learning Rust and Tauri and there surely will be a Rust version of Mechvibes in the near future

[NotLazy]

@insasquatchcountry By the way, the issue with new versions of Mechvibes is that I'm the new macOS app signer, so you need to remove Mechvibes from your privacy settings and then add the version I've signed. It's a security thing in macOS because the app signer changed.

[martypenner]

I really wanted Mechvibes and rustyvibes to work, but I experienced the performance issues others have mentioned with Mechvibes, and had significant issues trying to install rustyvibes on the latest macOS. I did, however, rebuild the core functionality in go, and I'm happy to contribute that to the project. I do think the electron portion is what's causing a chunk of the resource usage, so a go port wouldn't necessarily improve much there, though I haven't done a deep dive on the architecture of this project.

Is there any appetite from the maintainers for me to do some surgery on this beloved app? :-)

[hainguyents13]

@martypenner Hey there! Thanks so much for offering to contribute to the project! We really appreciate your willingness to jump in and lend a hand.
Actually, rebuilding the core functionality in Go is exactly what I did 2 years ago: https://x.com/borinkeistudio/status/1515161085988401153

[martypenner]

Wait whaat?? How did I miss that?? Can you point me to the code?

[hainguyents13]

Wait whaat?? How did I miss that?? Can you point me to the code?

Sorry I didn't push the code, just the initial here https://github.com/hainguyents13/mechvibes-go

[martypenner]

Ha nice! Mine looks pretty similar.

Regardless, do the maintainers have any desire for others to explore some possible performance improvements here? I'd like to keep using the product, and open it up to others who might be interested.

[hainguyents13]

@martypenner yes please!

[martypenner]

Great! I'm on vacation for another week, but will start putting together some ideas and maybe some benchmarks when I get back.

[martypenner]

Been looking into setting up some performance profiling and benchmarking to identify where the excess usage is coming from before diving in. Having a lot of trouble running the project though. I can setup a Dockerfile with the right node and package managers, but I'm not sure what versions of those tools the project is intended to be run with. I also see both yarn and npm lockfiles.

@hainguyents13 which version of node and npm or yarn should the project be run locally with?

[hainguyents13]

sorry for the mess, I use latest node version and yarn

[martypenner]

No worries! As in Node 20 and Yarn 4.5?

[hainguyents13]

for node, yes, but I haven't tried yarn 2+ with Electron

[martypenner]

I managed to set up most of a Dockerfile, but had definite issues trying to get electron to run inside that containerized environment. Not much surprise there. So I jumped into my Linux environment inside of Windows to test further. I managed to write some benchmarks and finally get them to run after a bunch of finagling. I couldn't get the app to load successfully even in that environment but I was able to at least benchmark the play sound function. And look what I found:

TL;DL CPU usage is fantastic but memory usage is terrible on just that function alone. Nothing stood out to me as being a memory hog in the play sound function. But then I tested playing sound directly using Howler, bypassing the play sound function entirely, and I saw similar increases in memory.

[martypenner]

Out of curiosity I just ran some experiments using go to build GUIs. I'm sure that the ecosystem in rust is more complete but it seems that we can get away with a lot in go, especially for a generally straightforward UI like Mechvibes has.

Given the complexities of integrating a sound playing library built using a non-JS language into an existing electron app, I'd be worried about not only the complexity but the performance of communicating between processes at the rate of keypress events (lots of serialization, lots of IPC). So instead, I'm going to prototype a replacement GUI in go. I'm sure there will be lots of interesting learnings. I'm happy to contribute the results back here, depending on what I find. So far, a minimal app I tested uses around ~150 MB of memory, and I cannot get the sound player to spike above 0.0% in the activity monitor. Seems like a good start :).

Please don't take any of this as criticism or pressure to replace the existing app with what I'm building; I simply want to keep using this app in whatever way possible :). I really do enjoy it and I would like to open it up to more people, if you're open to that kind of re-architecting.