Switch to a pure-python OSC library

[ideoforms]

For cross-platform portability, it might be better to use python-osc/oscpy. Test both for performance and look at switching.

[tildebyte]

FWIW, just noticed https://github.com/artfwo/aiosc , but I don't have any idea if it fulfils the necessary requirements.

[ideoforms]

@tildebyte Thanks for sharing. This library looks great, but would require pylive to use the asyncio architecture, which is not compatible with standard sync code so can't be used here.

This switch is still on my list, apologies it's taking a little while to get around to!

[tom-f-oconnell]

I wanted to say a bit about the pull request I made.

I am working on Windows 10 with Python 3.8.2 and Ableton 10.
pip install <path/to/my-local-pylive-repo>/ finally worked using MSYS2 after installing the right dependencies (with pacman in the MSYS2 MINGW 64 terminal), and after first doing pip install cython in the same fresh virtual environment.

My LiveOSC version was effectively the most recent (fbc12c1) commit in your fork.

uname -a (to make sure you are using a similar shell):

MINGW64_NT-10.0-18362 DESKTOP-3QP6LGN 3.0.7-338.x86_64 2019-07-11 10:58 UTC x86_64 Msys

Output of pacman -Qe (should include everything I manually installed in MINGW): pacman_Qe_out.txt

pip --version:

pip 19.2.3 from /c/Users/tom/src/pylive/msys2_venv/lib/python3.8/site-packages/pip (python 3.8)

What I have installed in the virtual environment:

tom@DESKTOP-3QP6LGN:/c/Users/tom/src/pylive$ pip freeze
attrs==19.3.0
Cython==0.29.19
more-itertools==8.3.0
packaging==20.4
pluggy==0.13.1
py==1.8.1
pyliblo==0.10.0
pylive==0.2.1
pyparsing==2.4.7
pytest==5.4.2
pytest-runner==5.2
pytest-timeout==1.3.4
python-osc==1.7.4
six==1.15.0
wcwidth==0.1.9

I was not however able to (successfully) run your tests using either backend seemingly largely because some of the tests have hardcoded paths that only apply for Ableton Live installed on Mac systems. I can't promise I will have the time to update the tests to work on Windows, but all of your provided examples I've tried seemed to work with either backend (using a copy of the project that my Ableton 10 opened when I first installed it, which is reasonably complicated). I just wanted to offer you this pull request, in case it saves you work on supporting different backends, despite not having updated the tests for Windows yet.

Here is the full pytest output, in case that's useful to you: pytest_out.txt

If you want to test the code with the modified backend, all you have to do, after downloading my pull request, is:

pip install python-osc

...then just define PYLIVE_BACKEND='pythonosc' before running pytest or any other pylive script you want to test. I set it up so 'liblo' will be selected, by default, in the case where this environment variable is not set.

I also modified setup.py, so that:

cd <pylive>
python -m venv venv
source venv/<bin or Scripts, depending on your setup>/activate
cd ..
# In a fresh venv, the install_requires cython in setup.p y did not seem to setup cython for me.
pip install cython
pip install pylive/[pythonosc]

I'm not sure if future uploads to PyPi would automatically then be installable like:

pip install pylive[pythonosc]

...or not, though. Maybe that requires additional metadata somewhere.

There are a few TODO comments in the code I've modified, most highlighting things that I think are likely to be important in polishing up the pythonosc support. Some of the others explain my thinking behind certain choices.

I'm open to suggestions about how things could have been done differently, but again, can't guarantee I'll have time for anything past this pull request.

[tom-f-oconnell]

And one more important thing: I've noticed that, for example (not sure it's representative), the example examples/ex-live-scan.py seems a fair bit more likely to timeout / have a connection issue in some of the backend calls using pythonosc compared to when using liblo. I think it might not be caused by the socket not being closed correctly because recent failures using pythonosc don't seem to affect the chance of failure using the liblo backend. I originally thought that might explain it, because I think there was some other evidence that the pythonosc timeouts / connection failures became more likely after earlier failure of pythonosc attempts, or perhaps after changing the set in Ableton. pythonosc does still successfully run these examples at least some fraction of the time (and it seems running the same example multiple times without changing anything in Ableton only rarely fails, if ever).

One alternative explanation for these connections issues might be that my pythonosc calls are causing some crash on the Ableton side. I might try to check through my Ableton logs and upload parts from there, but last time I looked into it, I don't remember any particularly clear pattern.

It may not take much editing of my pull request to deal with this particular issue, but hopefully this pull request will be of some use either way.