Welcome to aumhaa.

•October 31, 2013 • 6 Comments

You’ve found yourself at amounra’s Monomodular blog, 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, amounra, then read on (at your own risk, of course).


•August 12, 2014 • 9 Comments

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.



•July 29, 2014 • 3 Comments

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!



•July 3, 2014 • 7 Comments

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 😉



•June 9, 2014 • 8 Comments

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 😉



•May 18, 2014 • 8 Comments

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

•April 23, 2014 • 7 Comments

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 ….

•March 6, 2014 • 14 Comments

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 🙂



•November 19, 2013 • 16 Comments

Most important: I’ve made some changes to the modlink patch which should fix some problems with newer applications. Please let me know if you find any bugs. Also, make sure you’ve downloaded the zeroconf compatible serialosc.maxpat file or connections won’t work correctly.

I spent a lot of time working with the Live 9.1 Push scripts over the weekend. It was a selfish pursuit, mostly to integrate some features in AumPush that I want to use. I’ve been toting around an iPad with the Shove template on it, and although I like things I can do with it, I miss all those knobs and faders from my CNTRLR. So I implemented a new layer over the Master fader on the Push, and it does neat things like allow device selection, access to sends and returns, and channel selection. It’s not ready for public consumption yet, but I think its a step in the right direction in several ways (for instance, access to Returns on Push is tedious for me….there’s no quick way to get there!).

The upside to all this: a much better understanding of some of the new elements included with the Live9 _Framework and Push scripts. Its taking me a long time, but I’m finally getting the hang of this stuff. Now to put it to some good use….


What the heck is taking so long!?

•October 31, 2013 • 3 Comments

Ummm. Yeah. So…. sorry.

As it happens, I’ve been rather busy. b996 was almost “in the bag”, so to speak, and then Live91beta came along and spanked my little ass. Anyway, we’re getting there. Anyone that’s looked at the GitHub repository lately will have noticed some activity, and quite a few patches in the b996 folder….nevermind that they don’t really work, it’s enough for you that they’re in there, right?

I’d like to ask that anyone having suggestions about features, changes, etc. leave them here.

I’d like to ask that anyone having REAL ISSUES with the codebase please create a GitHub account (if you don’t already have them) and log issues there….it is really helpful in assisting me to keep track of things. It also encourages others to chime in, I think. Or am I talking to my self here? (not surprised….I have been kinda quiet for a while)

Anyway, cheers to all of you out there supporting this stuff I make, just be patient a little longer please. Some big things are coming, I just have to get out of the mire of making the old stuff play nice first. Things will start to move quickly soon, there’s a release candidate out for Live 9.1 so hopefully they’ll finally start changing crucial things and make my life a little easier.

Happy Halloween!!!!