virtual environment for developing Ableton Live Midi Remote scripts in PyCharm


I'm an experienced Java/Groovy developer, employed as such even.  But I'm brand new to Python.  My sole motivation for diving in now is customizing midi controller scripts for Ableton Live. 

I'm trying to set up a "virtual environment" in PyCharm to support my Ableton Live Midi Remote Script scripting project(s), but I've hit a wall and need help.  I'm not sure which section of my vast supply of ignorance is responsible.

The only instructions I have are in a file buried deep in the Ableton Live folder structure.  Of course, the instructions make project setup seem easy as 1, 2, 3.

* Working on abl.webconnector

 - create and activate a virtualenv (e.g. with virtualenvmanager)
 - install in the virtualenv the Python site-packages that we ship with Live:

#+begin_src bash
$ find $LIVE_REPO_ROOT/modules/python/site-packages/ -type d -name *.egg -not -name setuptools* -exec easy_install {} \;

 - install requirements for development:

#+begin_src bash
$ pip install -r dev_requirements.txt

 - run nosetests:

#+begin_src bash
$ cd $LIVE_REPO_ROOT/products/live/Live/AppWebConnector/Python/abl.webconnector/
$ nosetests -s  --with-progressive --logging-clear-handlers tests

Unfortunately, I suspect these are instructions for programmers with access to the full git repo at Ableton for the Live product, rather than instructions for users like me.  For example, the path to site-packages is different in my installation.  I probably could have scripted something to mimic the 'find' command. But I ended up creating Run/Debug configurations to run that "easy_install" for each of the "*.egg" folders not named "setuptools*" in that directory.  After that I ran the 'pip install dev_requirements.txt' command in my PyCharm console (git-bash).  After that I ran the nosetests in my PyCharm console.  I made several minor changes before all tests passed.  The changes were:

# * removed --with-progressive arg (didn't exist)
# * installed a module named 'mock'
# * edited line 33/34 to the correct (local) path
# * added file to tests/data/  (copy of and compiled it to foo_py25_mac.pyc
# * -- error was at line 115 because foo_py25_mac.pyc wasn't in tests/data/ like and

However, even though all 124 tests are passing in the console, it seems something is still not right in the project environment.  I can see the "eggs" listed in the "virtual environment" but sys.path in the python console doesn't also show any of those "egg resources"; and, when I open code files, import statements that reference any of those specific "Ableton Live" components are flagged as errors. (things like import Live, or import MidiRemoteScript)

It feels like I am so close yet so far away.  My question here is, can anyone tell from this description whether or not my problem at this point is my ignorance of Pycharm and Python in general, or if its ignorance of the Ableton python API and how it works?  If it's a Python/PyCharm issue, what is the issue and how do I fix them? lol



Hi everyone,

You're proposing very interesting stuff ! It's nice to be able to brainstorm some ideas as remote scripting is such a closed world !

I'm definitely lost when you're talking about c++ as I know close to nothing about it ^^

Regarding your xml rpc idea Johannes I need to say I don't really get it neither haha. What would be the point of setting this up ? Is it to be able to execute external processes ? That would be great indeed. Regarding this specific matter I guess a very raw solution would be to write in a file shell commands with an external process polling the file every x ms. Probably not very efficient but .. another one would be to be to make http requests to a local server. But that might not be compatible with Live 11 python build. Seems simpler for me to keep to Live 10 for now. 

Regarding the debugger I agree it would be great but I'm using different techniques to mitigate the testing / logging problem. It's in my doc. Also I'm not so used to use a debugger. Sometimes I use one when doing PHP web dev but not often.

So regarding what I said about wrapping the LOM I should clarify a bit what I meant and what I did :

- First, I'm quite sure it's not standard and from what I see big scripts like Clyphx or Push2 don't use it often. I mean there is obviously a lot of python classes but not much wrapping the LOM. It's very fine to not do it, especially with the live stub adding autocompletion !

why I really wanted to do it :

- First, I didn't think about the using the stub at first ^^. Only when johannes showed me did I start using it haha. So I didn't have autocompletion and I thought ok let's have it by wrapping the stuff I use.

- More importantly I'm using inheritance to create different king of objects (in particular different types of track objects). This would be boring without first wrapping objects.

- Also I just like working like this and I think OOP is much more clearer than a procedural code. Plus it's not hard to do.

You can use it ! it's here in my github repo. There is even a readme :p. But it's not something that would be interesting to export I think, it's interesting for me because I added my own logic in the classes but it's very linked to my script :)




rpc = remote procedure call

the idea is that you externalize all the logic (and maybe even the midi stuff) to another program and only tell live what to do via this connection (we'd basicly move the lom to a "place" where you are not bound by the python interpreter in live, not even to python itself anymore). its builded on top of a local server so to say. you could even move the logic to another computer.
this is probably overkill, but most of my solutions are ^^

creating a file that you "share" between programms sounds really bad! dont do this, there are whole classes teaching you better ways that are not prone to deadlocks 




Haha you're right it sounds like shit ^^ It's just that everything seems so limited in their python environement ! 

I see for rpc ! I guess to use this you would need access to network ? We should first check this then right ? If it's possible to make requests over the network that would open up lots of possibilities !


"For all the listener stuff I would use the decorators like @subject_slot in _Framework that are much cleaner that the old add_***_listener syntax"
Is there anything out there on how to best approach this? Do you have any examples?
Jon and I made tremendous progress on the Mackie C4 script and in fact can use the script with both Live 10 and 11 productively.
Having said that, there are still a few bugs. But we have those properly documented in the github repository


Hello Markus !

Yea I've written a little doc about this here : 

I'm not using ableton/v2 but they define new decorators for events in particular listen and listenable_property that seem to replace framework decorators with a slightly different syntax.

For the _framework decorators you should check out my code (and the doc!). It's mostly a wrapper around the add_***_listener stuff

For the ableton/v2 you should check the push2 code !

Great for the mackie c4 script !

See you :)