header image

Welcome to aumhaa.

You’ve found yourself at amounra’s blog about Monomodular (a.k.a Mod), a place to discuss the progress of a set of musical programming and performance tools written to be used in conjunction with Ableton Live, MaxMSP, and various different types of hardware controllers.

If you’d like to know what it’s all about, please visit the wiki page for more information.

If you’d like access to these tools, please download them from our GitHub repository (there’s a link to the right).

If you’d like to check on the status of the current build, or just read some of the meanderings and ravings of their creator, James Westfall, then read on (at your own risk, of course).

If you’re interested in getting some custom work done for your controller, please drop me a message!


What was Old is New


Apologies if I’ve neglected a reply to anyone over the last several weeks. I’ve been a busy bee, making a serious effort to use the downtime provided by this crazy global situation to finish a lot of the personal coding projects I’ve started over the last several years. I’m making good progress, but there’s still a lot to do!

For instance, I’ve had these Novation Launchpads sitting around for ages. When I adopted Ableton’s v2 framework back with Live 9, I made an assumption that they would eventually move their other controllers over to using the new framework as well, or at least start using it to write the newer scripts that they released. How naive of me. Moving mod over to v2 was necessary at the time, since the core needs to be referencing the same base classes as the controller’s main script, and I knew that things at Livid would be slowing down.  I wanted the Livid scripts to have as long a life as possible. 

This didn’t play out well for a lot of the older scripts that I wrote. The Launchpad, for one, got shelved. APC40. Block. (I miss block 🙁 ). The real problem I saw when I made the decisions about the v2 rewrite for all my scripts (and they weren’t made lightly) was that the scripts that were out of my control, the ones I’d merely patched, would need to either be rewritten in v2 (and I wasn’t about to do that) or I’d need to wait for Abes to release the v2 versions of those scripts so I could hack into them.

At some point a couple years ago, I decided to stop waiting. It had been long enough. I got my hands on a couple of the newer Novation Launchpads and started checking out the scripts to see how easy it would be to rewrite them. It was also an excuse to get my hands dirty on some Python, since I’d not spent very much time working with it for a while. I managed to get the Launchpad_MK2 and Launchpad_Pro working with a bit of effort. Then “other stuff” happened. I never got around to testing the scripts.

Cut to two years later, when someone recently asked me about them. I pulled the scripts out of the deep, black box they’ve been hiding in, checked out the scripts…..quite broken now. Because of progress. Because the v2 framework is constantly changing, and I’m constantly having to keep up with it by updating all my scripts that use it. Why did I make that decision towards progress, again? Well, to be honest, I’m glad I did….lots of good stuff in there to work with.  There’s got to be a way to use the original scripts and just hack them a bit, I told myself. Talked myself into.

I spent an evening with the LPMk2 first, and turns out I was able to do just that. In fact, I don’t even need to hack the scripts, I can just override from the Aum256 script, add some goodies to Launchpad_Mk2, and be really careful about how I disconnect when the relationship between the two is over. No need for v2 scripts, no need for constantly fixing broken scripts (probably….hopefully), and its moving in the direction I’ve already been considering (using Aum256 as a hub/server script with it’s own iOS app).

Another evening with the LPPro had good results. I was also able to get the original Launchpad script to work with this scheme. So now I just need a couple of the newer Launchpads to work with and I can get the whole Novation family going 😉

There’s still a need for some renewed documentation of all this stuff.  Most of the older docs on the wiki site are hopelessly out of date.  

So I’ve added the new overrides to the m4m8 repository, if any of you out there are still around that remember how to use the monomodular stuff, it works basically the same way it already has.  The only difference is that now, instead of needing custom Novation scripts from aumhaa, it’s only necessary to load the official Ableton script and an instance of Aum256.  This will override one of the User pages on the Launchpad (or utilize an extra mode on the Notes page of the Launchpad Pro).  You can have multiple controllers hooked up all with different instances of modHandler in the connected controllers, and it only requires a single instance of Aum256.  The plan is to have Aum256 host an iPad app which will provide additional controls, visualization, and configuration mechanisms for its conjoined controllers and the mods they are connected to.  

I’ve also reintroduced some of the earliest mods I wrote or ported, including the Aumboids and Aumlife patches.  Documentation will follow, but in the meantime if anyone is interested in trying things out just drop me a note and I can get you started with the basic info.

Enjoy the apocalypse, and don’t forget to wash your hands!



User-space during the apocalypse

I made this blog to talk about the work I was doing with MaxMSP, Ableton Live, and music. I’m still doing all of that stuff, but at some point I stopped talking about it. This seems like an ideal time to reinvigorate myself and start publishing some of the work I’ve been busy with over the past several years. Some of my devices have remained unfinished because I lacked the time I needed to hone them for public consumption. Other projects (the larger, more current ones) have remained hidden because I perceived a need to monetize them.

Back when Max 8 was released, I moved most of the original content of Monomodular (a.k.a. Mod) into a private repository so that I could methodically go through all of the individual patches, update each to the newest version of the aumhaa framework, and release them all into m4m8 as public material, a little bit at a time. Some things prevented that reality. This meant that the majority of material that I’ve created over the years isn’t really accessible or supported at the moment. In an interest to remedy, I pushed a working copy of hex back to m4m8 today. As I continue to work on new patches and update the ones that I have future plans for, I’ll attempt to add more of the old ones back into the fold.

In other news, Ableton released a new update to Live 10 last week (10.1.13), and it nearly slipped by me unnoticed. While it offers mostly minor changes, one thing is worth mentioning: the Abe’s have finally added the ability to place custom, non-factory MIDI Remote Scripts in the User Library. In addition, after decompiling the most recent Python script changes, I noticed that the majority of adjustments that they made were to correct misspelled docstrings. Hmm, very interesting. Are we, at long last, about to see them embrace the idea of a public Python API?

I leave you then, for now, to ponder these great mysteries…


Just a quick note to mention that I’ve updated the m4m7 repository to work with the most current release of Live 9.7.5.

Oh, and that I’m resurrecting this blog page in preparation for an upcoming release of new material for Mod. As it turns out, I’ve been working quietly this whole time….and I’m getting close to publishing some new work 😉



So, I made a bunch of changes last week and broke a bunch of stuff…..I’m working on soooo much stuff all at once, it’s bound to happen every now and then. I’m slowly going through each of the scripts now to reconcile differences with some of the more radical changes I had to make to my _Framework, but it might be a couple of days more before I get it all sorted out. Sorry for the inconvenience of anyone that’s trying to get this stuff working.

Base and CNTRLR should be working correctly…..everything else is questionable. I’ll drop a new post when I get everything ship-shape.



Yeah, that’s me, believe it or not.

If you’ve been watching the monomodular_git repo, you probably don’t believe that anything is going on over here…..but that’s because I moved everything for b996 over to:


Reason being that the internal structure has changed for the upcoming release and I didn’t want to further fubar any of you that are still using the old stuff from b994/b995.

I was on the last script (Base) two weeks ago, and decided that instead of spending a week trying to figure out what I did in the original and work around its deficiencies, I’d spend a week recoding so that I could subclass its Instrument functionality and include it in the other scripts. ANNNNDDDD, two weeks LATER….its done. Putting the finishing touches on it now.

I need to go back to some of the other scripts and add the new Instrument functionality, and I’m currently working with Darren @ Isotonik and Lee @ sigabort to get some implementation details covered for their support on Livid’s UserModes, but you’ll be seeing a release very soon.

If you have time to do some testing, please let me know….I can use all the help I can get!



Ableton released a new version of Live today, version 9.13. Some of you unwittingly already have it due to the wonderful “autoupdate” feature of Live 9. Many of you that use non-Ableton-endorsed remote scripts (like mine) are wishing right now that you had known that it was possible to turn this wonderful autoupdate functionality off in Live’s preferences…..

I found out last week, just as I was finishing up work on the hex mod for Codec, that there were some problems with our scripts in the new beta build of Live, which was the release candidate that would become their official release today. My first reaction was, hrmphhh. Whatever. Then I looked a little deeper. And then I started to get uncontrollably depressed. They’d done it again….screwed everything up. Before I’d even properly recovered from the last major release. C’mon, guys, really???

Besides changing a bunch of arbitrary things that really didn’t need to be touched (which are easily fixed, but irritating all the same, and basically makes it impossible to have cohesive scripts that work in more than a single subrelease of Live), they “fixed” a bug that had been present since the introduction of Live 9, even back in the prelease betas.

That bug, which caused Live’s Python engine to completely disconnect and reload all it’s Python scripts every time one was inserted or removed, had actually been the cause of much elation on my part when Live 9 was first released. Why? Why am I so excited about a bug? Well, basically, because it fixed another problem that Ableton or Cycling had never taken the time to address: there is no implementation for a way to be notified in m4l that a Python script has been added or removed from Live’s preferences. It’s kind of a big deal: if I load an m4l patch in Live, and that patch is expected to connect to a particular control surface script, but the script isn’t currently loaded in Live’s prefs, then it can’t connect. But since there’s no way for us to bump the patch when a change has been made to Live’s prefs, the only way we can ever connect is to have the patch sit there and poll the LOM over and over until one finally appears. This is very undesirable, epecially considering it would be VERY doable to implement something on their end to deal with this. ControlSurface.connect_script_instances() is called every time Live’s preferences change, so there’s already hook in place….it’s just never been implemented.

Another irritating coincidence of the “bugfix” was that my Debugger was no longer capable of invoking a complete reload() of all the Python modules in a running instance of Live, which means that every time I edit a script I have to completely restart Live in order to check the change. This, of course, means development time is greatly increased (as well as my blood pressure, I’m afraid).

Bottom line: instead of finishing up all the mods for the ALREADY COMPLETED 9.12 scripts this week, I had to back up and completely rewrite my connection routines for mods, make a bunch of bugfixes for general Python incompatibilities, and rewrite my Debug script from scratch. Happily, I’m pretty much done with that at this point….but I thought I’d mention it…since…its….taking….so….freaking….long.

Back on track, maybe we’ll git’r’dun this weekend. Thanks for your support 😉



I’ve finished initial versions of all the Python scripts for b996, and updated the repository with them. For those of you that want to check this out, you’ll want to download the github repository and place the folders from within the “Python Scripts” directory inside your copy of Live 9.12’s MIDI Remote Scripts folder. Some of the mod patches work with some of the scripts, but I’ve not had a chance to update everything yet…..that will be the next part of the process. In the meantime, I’d probably stay away from b996 unless you’ve spoken to me personally and I’ve given you the low-down. It will probably be another week before I get the rest of this stuff done.

I had some problems come up when porting the mappings for the Base script, just because the script is so convoluted at this point. In the interest of general forward progress with all the scripts, I’ve gotten side-tracked with rebaking that code…the plan is to have a Scale/DrumPad w/Sequencer available in modMode when a mod isn’t the selected device on the track. It might make it into b996, or it might be b997 before I get this done. Either way, that’s the hold-up right now.

Just a little longer now, it will all be worth it though 😉



Not enough of it. I swear….

Making progress…..I’ve gotten MonOhm working more or less, and I’m banging out BlockMod right now. I had to reconfigure some things to accomodate the new methods for setup in the scripts, which means the stuff I finished earlier need to be revisited before release. Life has been getting in the way of coding lately, so things are progressing (as always) slower than I’d like, but its getting there (and you’ll like it!). Expect some finished scripts soon, don’t count me out…..but feel free to bitch and moan in the meantime, I won’t take offense 😉


In the Corner

Just stopping by to make a little progress report.

I was really hoping I could roll b996 out with the Live 9.12 release, but it simply didn’t happen. I’ve been having some fundamental problems working out the logistics of how to integrate the new functionality of b996 with the legacy behavior of Monomodular. It didn’t really become apparent until I was forced to work with the new methods on the many different controllers that Monomodular supports…sometimes you just don’t know until you get there. I found quickly that I’d painted myself into a corner with the new methods, and often the only good solution for these types of problems comes at the price of patient and steady gnawing at the issue. At least I’m not wearing a silly hat this time…

I’ve been having some even more fundamental problems with time management and willpower. You see, there exists an inverse ratio here: Willingness to contribute time versus the need to accomplish the task for my personal use (since this is freeware, my real motivation here is for personal use…although, in the end, the stakes are much larger for this release). I only use 2 of these control surfaces, for which the codebase is more or less stable at this point (as well as the mods that I use with them). I’d been remiss to spend a huge amount of time on the rest of the pack until I was sure the methods I’d been using are going to work universally; that’s the whole point, actually. Add to that the demands of my actual “profession(s)”, and what you get is a very cranky coder. Perhaps slightly lazy, as well 😉

Last night while incorporating b996 methods for MonOhm, I finally made the breakthrough, both in design and implementation, that has been holding me back from finishing things up. I won’t go into the details, but you’ll see the new MonOhm script available on github this week.

I had already pushed several of the new scripts to github since my last post. Currently, there are b996 versions available for Base, CNTRLR, Code, LaunchPad, and (shortly) Ohm. The earlier releases were mostly finished, but now they’ll need to be reworked a bit since I’ve concreted the new methods. I’ll also need to do extensive work to all the mods in order to accomodate the new addressing system. Finally, there’s the wonderous joy of documentation. Don’t waste time trying this stuff out unless you really have some time to waste. For more than any other reason, it’s completely disorganized and I won’t have time to document it until it’s finished. However, if you’re interested in testing the final release before it comes out, please drop me a note; I will definitely need some guinea pigs for the installer and scripts, and any volunteers to help document things are more(…more…MORE!) than welcome.

Cheers, happy blinking 🙂


ECHO ECho echo ….

In case anyone is still tuning in out there, I thought I’d drop a (long overdue) post to let you know where things are at.

My absence from this blog has been necessitated by an ongoing project with Livid and Bitwig to get controller integration working between the two. I learned a lot of things and met cool people, and you’ll be able to check it out very soon indeed! But, alas, it’s taken a large toll on my productivity in Live.

I’ve been working fairly constantly on many aspects of Monomodular over the past several months, you can see the progress on Github. I can’t thank you enough for your participation in this ongoing process; bug reports and feature requests are always welcome and needed. There’s still a lot of work to do (it’s endless), but I’ve made some major breakthroughs lately, and a tentative version of b996 has made its way to my production machine and I’ve been testing things for the past several weeks. It’s looking good so far 🙂

This monster I’ve created has, quite frankly, become far too large for me to manage by myself. This is a large part of the reason it’s taken so long for me to get Live9 integration working. Constant updates to Live’s _Framework have caused uncountable delays, as every time I get things working, they change vital elements that I then have to track down. This is compounded by the fact that my own personal setup relies on Push, which is the most frequently (and drastically) changed component of their Python library. It’s more than a little frustrating.

I’ve basically rewritten the entire project from scratch, and this is the other primary factor for the delay. I’ve endeavored to remove the “tweakiness” from the fundamental design, so there isn’t a need to enter “modMode” or assign individual modAddresses, instead things “just work”. I have started writing mods that don’t require m4l, but live in Python and just do their thing alongside the m4l mods.

There was a huge need for some universality with the internal structure of my code. I found myself spending far too much time over the last year making the exact same revisions to countless versions of similar scripts with only minor variations, and addressing for “weird” controller configurations (like Base or CNTRLR) were a constant impediment. I’ve removed the need for all this, thus opening up a pathway for improved ease of integration for almost any arrangement of buttons or knobs (or whatever) into Monomodular’s framework.

For what it’s worth, I’ve had this mostly finished for six months, but couldn’t work on it due to other commitments. With some of that behind me now, it’s time to git’r’dun.

What you may already know (because I’ve said it before) is that some very fundamental things are changing about how Monomodular works with your controllers. There will not be a dedicated “modMode” in b996, nor will it be necessary (or possible) to assign mods to “modSlots”. Some of you have been concerned about how this will affect your workflow, and you’re not alone. I’m using this stuff as well, after all 😉 I’ve been testing a few different methods of dealing with this, and the results are encouraging. With the b996 release, there will be a new DeviceSelectorComponent which allows selecting any device in your set (no matter how deep it’s buried in a rack, etc) based on the name you give the device. The device chooser screen gives a visual indication of what type of device is assigned to which button in the selector if you have an RGB capable controller, as well as whether or not a device is linked to the selector slot and whether the slot is selected. In addition, there will be a “modLock” mode, so that a mod can be selected and then “locked” to prevent the controller from wandering to different devices as they are selected in Live’s view. These new features will definitely need some tweaking (both technically and ergonomically), but it’s a good start and I’m so far enjoying the workflow.

What you probably don’t know unless you’ve been peeking at the newest files on Github is that I’ve been working on some NEW material. Well, not actually new. Well, actually, I’ve been working on it for years. Okay, so it’s not new at all. BUT: its new”ER”. What the heck am I talking about? Good question.

Plinko2. My favoritest patch ever, but I’ve ran into far too many limitations when needing to make additions or changes to it because I’d long ago converted the main engine over to Java. Soooo, I decided to rewrite it a bit. And then I decided to rewrite it a lot. Like, completely. Now everything is native Max and javascript, mostly done in [poly]. It works extremely well, and is head and shoulders above the original. It’s not quite complete yet, but it’s as functional as the original and much faster, more robust even in its current state. There are more new features than I can list (or remember right now), but my own favorite is “trigger mode”, in which you can play the plinko board like an instrument in real time. It was always my original intention for this patch to be an instrument as well as a sequencer, but it was very difficult to implement with the way things were in the old version. Now it works beautifully 🙂

Jove. This is a working title for my audio TapeLooper patch, which I’ve been working on for years and have finally gotten into a really functional state. Not many of you have tried this one out, and for good reason: it required a bunch of third party Max Externals that were really picky about what they would run on, and documentation was scarce due to the patch’s ever evolving state. I’ve been wracking (probably wrecking is more like it, or wretching) my brain on this one for a long time. It is, for me at least, the “squaring of the circle” I’ve been talking about all along, and although it is far from finished, it is finally perfectly functional and very cool.

Root. This is some hardware that I’ve been designing over the last several of years, and it has taken up a good bit of my time over the last couple of months. It’s an evolution of the looper pedal that I’ve been using for the last couple of years to control Jove, but I’ve compartmentalized it, added 4 RGB LED’s and a Livid Brain Jr. to control it all. I’ve written a control surface script for it that automatically connects to 4 instances of Jove or Live’s Looper; it’s capable of displaying their states and controlling their functionality. Additionally, it does some nifty things like device control and scene banking/launching. It’s still a work in progress, but at some point it will probably be available for purchase. I still need to integrate the 7-segment LED display that hasn’t arrived yet, but I’ll be posting some pictures as soon as I get around to taking some.

Hex. It’s coming along nicely. I don’t know how much more I will get done before b996 release, but you’ll see a bunch of cool things for it in the near future, including clip exporting, new modes, and up to 128-step sequences for each of its parts.

Skin. This is a hand-percussion patch for assigning zones to Push or Base and playing the entire surface as a single drum with different voices. I designed this specifically for using these controllers as “Electronic Tabla”, but the patch is useful for lots of stuff.

Base. Base support has been ready for a long time (it was actually the first surface I prepared for b996). It’s pretty cool.

Livid Device Support. That’s right, no more “this works with this script but not that script, but that doesn’t work with this script”. You’ll see synthsteppr, drumsteppr, and accent support in Monomodular. However, you’ll probably want to use hex anyway, since it does what they do in a single patch plus a whole lot more.

Codec. I’ve completely redesigned this script yet again (it seems to have become an annual task), since it has become the main Livid controller I’ve been using in conjunction with Push. It’s pretty darned cool. Most of the functionality has been retained from the original, but no more double-press weirdness, and the ergonomics are generally much better now.

New mod.js. I’ve completely rewritten the mod.js object, which will mean very little to most of you. But if you get an inkling to make something with Monomodular, it will be much easier with the new version.

That’s about it. As I mentioned, I’ve got working versions of Base, AumPush, and Codec, and will be fleshing out the rest of the scripts over the next several weeks as I work out little bugs I’ve found in the current test versions. I’m anxious to get this done, and I’d love to hear your input.

Oh, and one more thing: I’ll be cleaning up b995 for a “re-release” (or, a proper release, as it was never actually officially released in the first place) for all of you that don’t wish to move forward with the b996 stuff right away.

Happy blinking 🙂