pymonome - python applications made easy

  • this project was born as an offshoot from [[http://post.monome.org/comments.php?DiscussionID=12095|griddle]].

    pymonome is a tiny serialosc-friendly module for developing monome applications in python. while python itself is hardly suitable for realtime audio processing, it's a great language for prototyping, scripting external applications, midi stuff, etc.

    get pymonome here: https://github.com/artfwo/pymonome

    currently the only example is monome-test.py. various examples/hacks will be added in the future. i would especially love to see proxy apps for various linux applications, that expose a midi/osc interface (sooperlooper, din, seq24, mixxx, etc. come to mind).

    word of warning: pymonome can and will change as we start developing stuff, so the api should not be considered stable. also it doesn't support arc yet and will probably have separate classes for threaded/blocking io.

    have fun!

  • bump.

    I'll be giving this a go tonight.

  • Are there plans to make pymonome compatible with Python 3?

  • When pybonjour and pyosc will support py3k (they currently don't), pymonome will move to py3k syntax as well.

  • pymonome is now on PyPI.

    http://pypi.python.org/pypi/pymonome

    :)

  • Really nice.

    It'll be interesting to look at your rendering model and compare it to what I've done in shado:

    https://github.com/cassiel/net.loadbang.shado/blob/master/README.MANUAL.md

    I've done the core in Java so it's more language-agnostic; mostly I've implemented apps in Jython but am now doing more in Clojure.

    How reliable's your Bonjour browsing? I've got a Clojure wrapper to JmDNS here:

    https://github.com/cassiel/clojure-zeroconf

    but it doesn't always pick up all my monome devices. (First-World Problem.) I don't know yet whether it's JmDNS to blame, or something inside serialosc; or just a timeout when picking up the client messages.

  • pyBonjour is pretty reliable, but it may require workarounds for IPv6, because the services are often discovered twice on many systems.

  • first, thanks! second, is there a good way to find the width/height of a connected device?

  • thanks, artfwo. forgive me for the basic question: to get information, i (think) i say

    m.send('/sys/info')

    how can i receive the /sys/size reply? been combing through monome.py and OSC.py but can't quite get it.

  • oops, looks like pymonome already does the /sys/info stuff on initialization and stores the size in Monome.xsize/Monome.ysize. sorry for the wrong reply above - haven't touched the code in a while and forgot most of it.

  • ah, aha! no worries, thank you!

    kinda weird: i need to add a little time delay when getting the x/ysize on startup:

    host, port = monome.find_any_monome()
    m = desert((host, port))
    m.start()

    print('monome started on ' + host + ':' + str(port))
    m.led_all(0)
    time.sleep(.01)
    print m.xsize, m.ysize

    without time.sleep, that print gives me instance has no attribute 'xsize'

  • that's right, because communication with serialosc is asynchronous and the value may not be available immediately after you create the Monome instance. perhaps we need some kind of "have_size" callback here?

  • ah, right, right. that would be beautiful!, if you have time. i'd be happy to help, but i'm just starting out so it's beyond my powers...for now...

  • I read above that Python is a bad choice for realtime audio. Is that because of slow processing, or slow transmission (latency)? I want to ask it to do very lightweight arithmetic -- nothing compared to audio -- but it has to respond to the monome and the computer keyboard fast. How much latency does Python have? What about Tkinter? (I don't need a GUI but Tkinter's the only easy way I've found to capture key presses in Python.)

  • your choice of GUI won't noticeably affect the performance. and yes, for the lightweight kind of tasks (midi, osc, numerology, etc.) python is of course very fast - you shouldn't see any latency at all.

  • I've started working on asyncio-based OSC implementation which might be of interest to whoever is using pymonome:

    https://github.com/artfwo/aiosc

    pymonome port to aiosc is also in progress, and I will likely switch this thing to serialosc built-in discovery as well (sadly, dropping support for griddle-like servers). It's not very clear how asyncio mainloop will work with any GUI toolkits, but it looks promising otherwise. Stay tuned for updates!

  • Thanks for the effort :)
    Looks to be a minimal, straightforward, and correct.
    I will be bookmarking this for whenever I need to quickly send an osc message from python.

  • A major pymonome update has been pushed today. Nasty things can happen if you use it, but everybody's welcome to try. For now, get it from github: https://github.com/artfwo/pymonome. PyPi package will be updated after extra testing and polishing.

    Important changes:

    * pymonome now requires Python 3.4 and aiosc. Get it from https://github.com/artfwo/aiosc or install using pip.
    * All networking relies on asyncio. Timing too, unless you use external clock.
    * serialosc internal OSC-based discovery is supported and it's possible to autoconnect apps to devices.
    * Row and map data in Monome.led_* methods is now expected to be lists of binary values, e.g. [0,0,0,1,1,1,1,1] or 2d lists with row-major order.
    * No need to wait for receiving /sys/info. Put your initialization code in ready() method, which is called automatically when width/height/rotation data is available.
    * There is built-in support for pages and even nested pages (yeah, really).
    * Standalone apps can be converted to pages using multiple inheritance with very little boilerplate code.
    * It will work with GUI libs which support asyncio, e.g. urwid.

    There is no support for arcs or varibrightness in pages yet and this version has not been tested against any other device than a 40h arduinome. All current users of pymonome, please try porting your apps and send suggestions! API may change, but probably not much, so using current version is encouraged.

  • I read above that there was once a monome-test.py for pymonome 0.2.2. (I would love to use your recent update but I have to stay compatible with simplecoremidi, which only supports Pyrhon 2.7.)

    Does it exist? Can I have it? :)

  • For testing I suggest using any of examples (e.g. hello.py, which replaces monome-test.py).

    And no Python 2.x support, sorry. A backport might work if both aiosc and pymonome are backported to tulip, but I'm not sure I'll have time to do that in any foreseeable future. Of course, the code is open, feel free to port it back to 2.x :)

  • In a separate thread I posted a question about concurrency with pymonome: http://monome.org/community/discussion/18067/python-pymonome-asyncio-and-concurrency

  • git version is now updated for varibrightness support with backwards compatibility for monobright devices. there are a few minor api changes and fixes as well.

  • this is great! the code looks really good, very understandable.

    i'm trying to make a new library for processing-- hopefully i can live up to this level of quality.

  • @tehn, thanks! tried to make it self-documenting and convenient to work with.

    i've pushed a couple of in-progress apps today as well:
    https://github.com/artfwo/pymonome-apps

    these are basically python ports of flin and parc (always wanted to run both on linux). they can work standalone or clocked from external midi clock. there is no midi output yet, but it's possible to drive renoise (or any other synth with osc support) using the supplied synths.Renoise object.

    there is no midi input either, so to enable midi clock synchronization:

    1. run scripts/midi2fclk.py -- a midi->osc adapter script which requires python2, python-liblo and mididings (yeah, i know).
    2. connect midi sync out to midi2fclk input port.
    3. uncomment FooClock initialization code in the app.

    (midi2fclk.py converts midi clock messages to /bang osc messages on port 9000. on the app side, use clocks.FooClock to synchronise to those, or just use clocks.InaccurateTempoClock for running the apps with internal clock).

    suggestions, comments, patches, etc. welcome as usual.

  • pymonome is now in beta and the recent version in installable using pip.

    the above apps repository just got an actual midi clock (requires rtmidi2). should be cross-platform too. midi out support underway.

  • wow, it's on pip now? that's spectacular.

    i'm going to check this out right away.