Running a native Python in Max/MSP?

I’ve been writing a lot of Max in my spare time and I love it, but boy, do I wish I had unit tests, boy, do I have to use the mouse a lot, and boy, am I sick of zl! ;-)

I used to use Pyrite to do this long ago, but I’m writing a lot of Python these days and it’s such a pleasure to use. If I could use Python I’d never use zl again. (Not that zl isn’t a pleasure from what I had to do in the old days…)

I know that you can get Python to run as Jython with the Java plug-in but that has to be pretty slow and memory-consumptive, right?

Jython is just less than half the speed of CPython under Windows and Java seems somewhat slower on the Mac; plus there’s the dreadful startup time, how do you get around that?

Why was it easier to run Python as Jython than directly embed Python into a Max external? Well, I guess I can answer that question: it might have been trivial to do, drop the jar somewhere and go…

Let’s put the real question: what would be the possible issues involved in writing an external to run CPython from within Max/MSP?

I’m planning my development over the next year or so and I’m thinking of spending some time on this.

In particular, I’m going to be writing applications that I’ll package and give to other non-programmer musicians who don’t have Max, so I need to plan that step.

I’m perfectly willing to put restrictions on the sorts of programs I could write, giving up e.g. threads in Python.

Quote: tom@swirly.com wrote on Fri, 20 June 2008 11:42
—————————————————-

I have not used Python/Jython in Max, but I can answer some of your questions based on my experience embedding JRuby in Max…

> Why was it easier to run Python as Jython than directly embed Python into a Max external? Well, I guess I can answer that question: it might have been trivial to do, drop the jar somewhere and go…

So yes, one benefit is the cross-platform compatibility, but it’s not as simple as drop and go. See my response to your possible issues question below.

Another benefit, which was a big one IMO, is full access to all Java libraries. I had already dedicated a lot of time to extending Max via Java. Plus there’s an enormous amount of open source Java projects out there for pretty much any task imaginable. Being able to use Ruby+Java was a lot more powerful than Ruby alone. I like writing Ruby scripts that call Java libs, and Java programs that call Ruby libs. Lots of flexibility in the way to tackle problems. But if you don’t care about Java, this would obviously not be worth the performance hit.

There is lots of room for improvement in VM optimization, so we can expect JRuby and Jython performance to get better as time goes on. I’ve seen JRuby startup time improve an order of magnitude in the last year…

> Let’s put the real question: what would be the possible issues involved in writing an external to run CPython from within Max/MSP?

Most of the difficulty for me was building the bridge between Max’s type system and Ruby types, so that scripts could be used seamlessly within the Max environment and communicate with other objects. I had to make some choices about the way to convert types, and there are a few cases where there isn’t a single right way to do things. For example, I convert arrays to Max lists "1 2 3", but you could also convert it to a string "[1,2,3]". If this is not what the user wants they have to do extra work to get what they want. It sounds like pyext has already dealt with that for you. Hopefully you agree with the choices they have made.

Then there are a lot of functional and usability decisions to make. Like do you only support running scripts from disk, or can you pass in script fragments as Max messages and evaluate them on the fly? Do you support file autowatching to streamline development? Do you simulate support for ARGV, $0, and other special variables? If multiple script objects are created in Max, can they communicate with each other? Do they share variable definitions? There are lots of details to worry about, and it all really depends on how you want to do scripting in Max. Not every user will want the same things…

Anyway, just some food for thought. Good luck with whatever solution you end up using.

> Question: what does one generally use as a quick’n’dirty development environment for building Max externals (particularly if I don’t want to build rich binaries?)
>
> Can I just use gcc and emacs or must I download Apple’s massive development system?

You can use whatever you want. On OS X, I really like TextMate, which is a fantastic lightweight and powerful text editor that supports almost any programming/markup language out there. It costs money, but is relatively cheap.

> So yes, one benefit is the cross-platform compatibility, but it’s
> not as simple as drop and go.

Indeed, although cross-platform compatibility was, for me, a
motivational factor. The Groovy and Jython systems run identically on
Mac and Windows. (I’ve just finished preparing a gallery installation
using Max/Windows although I don’t run Windows here, so that was
important.) And the systems are compatible between Max 4.6 and Max 5.0
– no porting effort was involved.

It isn’t drop-and-go: there’s some coding effort to connect an
interpreter for any language into the MXJ framework, as Adam describes.

As Adam says, access to the Java API (and the Java interface to MXJ)
is important – I’ve used Jython to connect to databases via JDBC, and
am currently talking OSC to a monome using a Java OSC library and a
Java sprite/compositing system. I actually did the Groovy interpreter
first, since I wanted a lightweight dynamic language based on text
files in Max’s search path which could interact well with Java. Then I
started using Jython within Marc Downie’s (F)ield platform, and
realised that with a pile of refactoring I could provide Jython for
Max by refactoring and sharing a big chunk of the Groovy port. So,
net.loadbang.{jython,groovy} is something of a two-headed beast.

I could probably add JRuby if I wanted, and might do it as an exercise
at some stage, but my real target at the moment is Scala.

Having said all that, a native Python would be nice – it would be good
to get Python 2.5, since Jython is still at 2.2 – but it would really
have to work identically on Max 4.6 and Max 5.0 on both Mac and
Windows, and there’s a fair amount of work in guaranteeing that.

>> Question: what does one generally use as a quick’n’dirty
>> development environment for building Max externals (particularly if
>> I don’t want to build rich binaries?)
>>
>> Can I just use gcc and emacs or must I download Apple’s massive
>> development system?

You should have Xcode on any recent system DVD; I don’t know how easy
it is to build Max externals without it, using the basic components.

For what it’s worth, I use the Aqua EMACS (Aquamacs) as text editor on
the Mac, and really like it. But I’ve been using EMACS for two decades
– your mileage will probably vary.

Adam’s checklist of functionality that I might (or might not) want is particularly clear and revealing.

Cross-platform compatibility isn’t an issue – yet – with this project as everyone has Macs – but it’s always helpful to keep it in mind.

I like Java but right now I don’t need any Java libraries as I just want to write short little snippets of list processing. If I were running Java, I’d probably just do that, I’d get very nervous about having three languages running.

(And right now, Python is my new fave language :-D so I want to concentrate on that.)

Oh, and I should add that I wanted to avoid xcode primarily so I could keep using emacs: only one development system ever tempted me away from emacs and it was Eclipse (which I’d be using right now, or intelliJ, were I developing in Java).