Implement Asynchronous MIDI Processing for Improved Scalability

[pushpitkamboj]

Fix : #4626

Core Idea

The primary goal is to modify the transcribeMidi function to prevent browser unresponsiveness with large MIDI files by implementing asynchronous chunking and memory optimizations.

Async Processing

The core refactoring lies in processing the MIDI data in smaller chunks asynchronously to prevent the browser from freezing. The processChunk function, processes notes in small chunks and yield back to the main thread using setTimeout or async/await, which prevents locking up the browser during long operations.

Environment:

Operating System: Windows
Browser: Chrome

Checklist

• I have read and followed the project's code of conduct.
• I have searched for similar issues before creating this one.
• I have provided all the necessary information to understand and reproduce the issue.
• I am willing to contribute to the resolution of this issue.

[github-actions]

❌ Some Jest tests failed. Please check the logs and fix the issues before merging.

Failed Tests:

ToneBlocks.test.js
midi.test.js

[omsuneri]

@pushpitkamboj please provide a video of importing midi blocks more than 800 does that problem solved or not ???
I m afk better if you upload a video for reference

[github-actions]

✅ All Jest tests passed! This PR is ready to merge.

[pushpitkamboj]

Screen.Recording.2025-04-25.215933.mp4

I tried my best to optimize but don't know if we can optimize it more with the existing processing on browser. Need to think of another alternatives to reduce the buffer for better UX.

[walterbender]

Your changes broke the unit test.
Even with your changes it seems slow and unresponsive. Maybe it is worthwhile adding a warning message: "WARNING: Loading large MIDI files will be slow on some browsers."

[omsuneri]

@walterbender it's a good idea to give a text msg instead of refactoring midi importer
I ll close that issue

[pushpitkamboj]

I get it, maybe adding a warning message is better idea.