macOS can't run this project [ bitpack , win32api ]

My test computer details: macOS 12.5 (21G72) intel Core i9

After I followed the ’ Manual Installation ( For Developers ) ’ to install this project, I found it can’t run. At first, it shows ’ can’t import name bitpack ’

File "/Users/chocovanilazuki/Downloads/ultimatevocalremovergui-5.3.0/diffq/base.py", line 21, in <module> from . import bitpack ImportError: cannot import name 'bitpack' from partially initialized module 'diffq' (most likely due to a circular import) (/Users/chocovanilazuki/Downloads/ultimatevocalremovergui-5.3.0/diffq/__init__.py)

Then I found this project is relied on the ’ win32api '. Only runs on Windows.

[RigoLigoRLC]

After fiddling with it for an entire night, I got it running on my M1 Mac. I have to say, this project has more issues than assuming Win32 API is present.

• It’s referencing GUI-icon.png which isn’t the correct case - (case sensitivity, Windows developers! Get it right!) and assumes a backslash path delimiter (Windows developers - Can you feel my hatred on backslashes?) so the program don’t find the ICON and crashes (funny thing that it crashes for something ever so slightly wrong)
• Doesn’t ship a uvr_patch_version.txt that is read at startup (for checking updates) and crashes (same thing as above, duh)
• Ships an x86_64 libtkdnd which isn’t processed by Rosetta, and compiling tkdnd on M1 is really difficult since nobody did support on that. In my knowledge Tkdnd just adds drag and drop to Tcl/tk and so the developer of UVR5 SHOULD DROP THIS DEPENDENCY for compatibility
• Ships a Windows AMD64 binpack in diffq so it’s not gonna load at all, you’ll have to replace that with a proper version
• Assumes you’re on Windows and calls sox**.exe** so if you put a macOS SoX into the respective folder it still fails to use it

And when I was configuring all this in a venv, Python dependencies are very messy. If you just do the pip install -r requirements.txt as README instructed you’ll face tons of errors, mostly because the dependency is messy and something magically depends on an older SciPy & NumPy which isn’t delivered in wheels. And if you try to compile Scipy/Numpy on M1, good luck fiddling with that. I ended up ignoring these weird versioning issues and just went with the latest wheels. No issues so far.

Many many small issues adds up. It’s painful to debug through all this. It couldn’t utilize M1 hardware (pure CPU) but ANE doesn’t support a very large neural network either so I think this is the best case.

[Anjok07]

After fiddling with it for an entire night, I got it running on my M1 Mac. I have to say, this project has more issues than assuming Win32 API is present.

• It’s referencing GUI-icon.png which isn’t the correct case - (case sensitivity, Windows developers! Get it right!) and assumes a backslash path delimiter (Windows developers - Can you feel my hatred on backslashes?) so the program don’t find the ICON and crashes (funny thing that it crashes for something ever so slightly wrong)
• Doesn’t ship a uvr_patch_version.txt that is read at startup (for checking updates) and crashes (same thing as above, duh)
• Ships an x86_64 libtkdnd which isn’t processed by Rosetta, and compiling tkdnd on M1 is really difficult since nobody did support on that. In my knowledge Tkdnd just adds drag and drop to Tcl/tk and so the developer of UVR5 SHOULD DROP THIS DEPENDENCY for compatibility
• Ships a Windows AMD64 binpack in diffq so it’s not gonna load at all, you’ll have to replace that with a proper version
• Assumes you’re on Windows and calls sox**.exe** so if you put a macOS SoX into the respective folder it still fails to use it

And when I was configuring all this in a venv, Python dependencies are very messy. If you just do the pip install -r requirements.txt as README instructed you’ll face tons of errors, mostly because the dependency is messy and something magically depends on an older SciPy & NumPy which isn’t delivered in wheels. And if you try to compile Scipy/Numpy on M1, good luck fiddling with that. I ended up ignoring these weird versioning issues and just went with the latest wheels. No issues so far.

Many many small issues adds up. It’s painful to debug through all this. It couldn’t utilize M1 hardware (pure CPU) but ANE doesn’t support a very large neural network either so I think this is the best case.

Thank you for this! I didn’t have a personal MacBook to test on, so this is incredibly helpful. Most of the issues you’re having now are a result of me focusing on the all in one installer for Windows after UVR v5.1. I need to create separate branches for Mac and Linux and update the README.md. I just haven’t had much time. So far I’ve managed to get UVR v5.4 close to working fully on Ubuntu 22.04 but there are still a few things I need to work out (the SoX issue obviously being one since UVR is coded to rely on an executable for Noise Reduction.

If you manage to debug through most of this, create a pull request for a Mac-specific install, and I’ll test and then merge it.