The aumhaa Website has been transported, please go here instead:

We don't hang around here anymore.....

Search This Blog


Back On Track

I've gotten back to the Ohm64 over the last couple of days, and the script is very very very nearly finished.  A few finishing touches to be added, and then I can start reworking the control_surface integration with Monomodular. 

I've added extra functionality to the linked mixer mode, giving it its own zooming component.  In addtion, I've enabled the feature found on the iPad script of linking the volume fader to the first instance of a "Velocity" plugin's "OutHi" parameter when its available on a MIDI track with no audio output.  I don't expect anyone to have the slightest idea what I'm talking about, but the good news is that once this is finished I'll have a chance to do some video showing what this stuff really does.

I've added some other goodies that will make you feel like your driving a spaceship or'll just have to wait and see.  I'm truly hoping to get the Python script out by tomorrow.



It's been a tough week.  My VW bus caught on fire, one of my roommates attempted an ill-conceived mutiny, and my internet has been down for 5 days.  Consequently, I haven't gotten much work done on the programming side of things.  On the bright side, I've been recording some music.  Just a quick update to let you know what's going on.....

Hoping your week has been better than mine ;)


Python is FUN!!

I'm getting the hang of this now.  I've been all over the _Framework now, and at last I understand exactly what is going on in there (well, as much as possible, since true understanding requires two things that I don't have:  the current decompyled versions of the scripts, and the backend code that its connecting to).

I've managed to create the necessary overrides to the _Framework so that a standard control script can be modified to include the ability to completely control the functions of the script from within m4l.  This means that, for instance, you want to tell the script that a button is pushed on the controller attached to it from m4l, you simply send a message to the corresponding button element with the new value.  This wasn't possible before, nor was it easy to achieve ( was minor, but it took me a long time to understand how to do it).

I've also managed to create a new Module that overrides the functionality of the ModeSelectorComponent.  It allows the ability to assign listener functions to different elements of the Control_Surface, and forward their values directly to m4l when their values change.  Those of you that have investigated the C_S portion of the m4l implementation have probably noticed that there aren't very many things that you can actually observe in the C_S objects.  In fact, there are only two observable properties:  'value' of __controls__ (which are not even a defined property within any layer of the __control__ heirarchy) and 'mode_index' of the ModeSelectorComponent __component__ (which does have a property, '_mode_index', but the property has a preceding underscore).   After tinkering a great deal with all of this, I've come to the realization that there is no general way to get an observable property from modifying the scripts, as there is specific functionality built into the backend code that connects Live to the Python implementation; it must search for specific instances of these modules and connects to staticmethod functions to retrieve their values when they change. 

So, instead of giving up, I created an override of the ModeSelectorComponent that allows it to be used as a ValueListenerComponent, and thus transmit the values sent from MidiMap in Live to the m4l side of things simultaneously.  Certain value changes can be intercepted in the scripts (usually button values), but most Midi data (bound encoders) is never forwarded to the script before being sent from Live to the controller.  This caused me enormous grief, but ultimately gave me a much better understanding of how the scripts work.

Bottom line:  the most current version of my scripts allows both settable and listenable properties for every connected control in a script accessible directly from within m4l.  This is how things should have been from the is, I think, what we all expected regarding control_surface support when m4l was released. 

My motivation for doing this all this is to enable the use of Python for all control_surface purposes.  The _Framework is much faster processing things than m4l, so all I need from m4l is to be able to set and receive the values that would be sent to a Midi controller.  A new version of Monomodular will arrive shortly, which implements an iPad script with much less bloat, and much greater dexterity. 

I discovered some bugs with the Python bridge.  These bugs have to exist in m4l also, since it is basically just another Python script.  Its probable that Ableton knows about them, and has a way of avoiding them by not doing something that I'm unkowingly doing.  I will publish some more data about this when I get more information (I need to test the raw Ableton scripts to see if they are generating the same errors).  In the meantime, if anyone has questions please contact me directly.


Vacation :)

Vacation from the usual work, anyway.  I have a little respite from running sound as much as I have been I'll only be working 1 1/2 full time jobs for a little while.  More time for coding :)

I've been trying to tie up some loose ends over the last couple of days.  I've created a javascript that emulates a lot of the functionality of the [coll] object and acts a link between [coll] and [pattr].  There are still some things it doesn't do (mostly related to sorting and use of symbol links to coll registers), but I don't use those features and am not terribly inclined to add functionality for them.  Everything else appears to work, so I'm going to package this new object up with all of my patches for the next revision.  I'm curious to see how well the system should be faster and more efficient than using [matrixctl] linked to a parameter enabled [pattr].  This object should make future efforts of porting patches between raw Max and m4l a good deal easier. 

I'm almost finished with the Sooperlooper interface I've been working on, but haven't had any time to test it out.  I'm going to try to take care of that tomorrow.

I have a couple weeks to work without much interuption, and the weather here right now is perfect for staying inside and burning copious amounts of wood (and other burnables) to stay warm and dry.  Expect the next revision of Monomodular in short order, along with final versions of the Ohm64 control script.  It will see some pretty major additions if all goes well; if not, it will see some minor ones and a quick release.  Either way, there will be some note-modes available and Drum Rack support.

I will add a link to the raw files for the [coll_pattr] object.  It works by living in between [pattr] and [coll].  You can send it any command you would send a [coll] except for "delete", which is a reserved internal js function name (use "del" instead, it will forward the proper command to the [coll] it is connected to).   It updates the pattr with the new coll every time it receives one of the messages it understands.  There is a list of functions which it merely passes on to the coll, without making any changes in its internal structuring of the data.  It is also capable of retrieving the information directly from [coll] if the two are connected properly.  The first, second, and fourth outlets of the [coll] must be connected to the second, third and fourth inlets of [js coll_pattr.js] for [coll] to send its data to the [pattr].  The function "collect" will read the current data from the [coll] object.

If there is no need for collecting data from the [coll], then its only necessary to connect the output of the javascript to the input of the [coll] and send any message you would send to [coll] to the input of the javascript.  As long as a [pattr] is connected to the first inlet of the javascript, and has "parameter mode" enabled, it will function nearly identically to the [coll] downstream from it and will store nearly identical data in the [pattr].

"Nearly"...what does that mean?  I don't know yet.  Some ordering will probably get lost....time will tell.  Check it out.


Back to work.

It's been a while since I've had time to post here.  I've been extremely busy in real life running sound for shows that have been going on here in town.  It's been fun, but harvest is about over and the weather is getting grim, so its time to hole up in the studio and get some work done there whilst burning things to keep warm.

I won't even go into enumerating all of my plans for ammending my previous work and making things better.  I'll try to post on a more regular basis as I work on things.  I have some good ideas now that I've spent some time writing the Python scripts for the Ohm64 about how to better use Python to make m4l more powerful and productive.  The main goal is a complete rewrite of the TouchOSC interface using Python...but this is still probably a few weeks off.  And of course I need to publish the finished version of the Ohm64 script after I've made the necessary refinements to it (thanks to the beta-testers for their feedback on this).

I also want to spend some time documenting the Monomods abstract so that others can use it if they want, however I've given this relatively low priority since nobody has really complained about the missing info.  If anyone needs direction, let me know....otherwise I assume no one is using this stuff besides me for writing code.

On the other hand, someone is reading this stuff (and using it presumably)......anyway, people keep downloading it ;)



Ohm64 Beta is out to testers...

I've finished a preliminary version of the new Ohm64 remote script for Ableton Live.  Its accompanied with a new version of Monodular which integrates the Ohm64 with the other controllers that work as Monomod controllers.

It's out to the testers...time for a beer and some kick-back.  I'll try to get some videos out in the next coupla days.


7up appears to work with Monomodular....

I don't have a great deal of time to learn 7up right now, but it appears that everything works (I had a report to the contrary).  Seems kinda slow to me, but again, I've only spent five minutes with it and have no idea how its really supposed to work.  A project for another day....

Anybody with experience, please leave some feedback.

Cheers :)

Ohm64 script is done :)

My apologies to those of you to whom I've made promises and haven't delivered on yet....I know there are a few of you out there lately. 

Real life is extremely busy for me presently, and I've had little time to spend coding and doing computer related things.

I have, on the other hand, finished the Python script for the Ohm64.  There are a few errors I've been getting that need to be tracked down, but for the most part it is complete for now.  There is also a lot of room left for additions as people request them or I think of them myself.

I need to finish the m4l companion to the new script so that it can be released.  It will provide a HUD that works in the same fashion as the LCD patch I built, but will function for all the knobs/faders on the device.  I may add some feedback for button assignment, as well.  It is mostly finished already; the only thing left to do is to incorporate the pertinent parts of Monomod into the mix.

What this means for the rest of you: probably nothing, unless you own (or plan on buying) an Ohm64.  However, because of the investment in time I've already made working in Python these past few weeks, the iPad script will be getting rewritten next, and oh man its gonna be so much better (read: faster).  I've come to the conclusion that any API stuff that I need to do for now on will be taken care of in Python, as its easy to link the functions from m4l.  There's so much raw horsepower in there, its such a shame that the Abes won't give us clear docs and a debugger....I mean, they've already given us access with m4l, but its basically worthless without rewriting the _Framework functions to take advantage of this.


I'll have the Ohm64 script out to the public next week if I can find some beta testers (maybe the following week, if there are a lot of things to fix).  Then a rewrite of the iPad script, and finally back to Plinko:  I'm going to recode its engine in Java, so I have some more headroom.  Basically, I should be able to cut down the processing load for the main patches by 50% I think.  (I hear someone far away yelling "the proof is in the pudding!")


7 up with Monomod

I haven't tried this yet, but has anyone gotten 7up to work with Monomod?  I had an inquiry yesterday and simply don't have time to check it out right now.  Drop me some email if you have some details.  Cheers.




I received a wonderful package in the mail last Friday, and am just now getting around to playing with it.  Peter Nyboer and the guys from Livid have let me borrow an Ohm64 in order to port the Monomodular stuff over to it.  Its a very sexy piece of hardware, and I can't wait to be triggering stuff from it in the manner that I'm accustomed with the other controllers that  I've worked with previously.

My original intention was to just port over the pertinent sections of Monomod so that Ohm64 users would have access to my patches, but I realized very quickly that things weren't going to be that straightforward.  After all, Monomodular is centered around multicolor grid controllers, and the Ohm64 is just...well, "blue".  But that was kinda enticing in itself, since blue is my favorite color for leds, and none of the other c_s's that I use even have that color (why is it always all or nothing?!).

So my first task was to implement some kind of flashing state built in to the Python script for the controller.   Since I was having to use a lot of my own functions, it seemed simpler to just write a new Python script on top of what I've already done for Monomodular and use it for more general purposes.  I thought it was going to be a lot of work (and probably will be, by the time I'm done), but at least the initial work is already done:  I have flashing buttons (which can be set by sending a message between 1 and 126 to set the interval), a session controller, and some other basic functionality working quite well.

I built a new class on top of the _Framework for the button class that overides a few things and adds a few other things.  This, in conjunction with another call from the main class, is all it takes to get buttons with flashing feedback.  This is general, so you can use it with any other Python script that is based on the _Framework stuff.  I'll probably revise it a little when I have time to figure out how to add an internal timer instead of calling everything from _update_display, but its some good progress, and I think a few people will be really happy about it.

I have another evening to work on this before I have to go back to work, but there should be some new releases here in the next couple of weeks that support another piece of hardware and round out some of the things that I've already released.  I'm now trying to incorporate as much as I can into these Python scripts and move a lot of the heavy lifting from m4l over to them.  So far, so good.



I've not had much time for coding lately....aside from my day job, I've been running sound for a lot of events lately.  Its a good thing, as I've gotten to participate in some really good performances by the likes of Signal Path, Beats Antique, Blockhead, Lynx...just to name a few.   But on the downside, I haven't made any progress in my programming exploits.

Just a head's up to any of you following my m4l patches...I'll probably not be publishing anything new for a little bit.  I'm currently working on a couple of patches to round out my own Live rig: incorporating the Python scripts into the iPad script (with support for an 8 knob rotary controller, ala Nocturn), and rewriting a Sooperlooper controller in js.  I'll probably be publishing the Sooperlooper stuff first, since that's what I'm working on right now.


LCD that works

Someone finally bothered to tell me that LCD wasn't properly frozen, and was therefore unusable.  I updated the files, it should work now.



Hmmm.  I've been busy with things lately, I guess.  I've made some pretty good progress with the Python scripts, but I'm afraid a lot of things have gotten put on the backburner until I determine exactly how I want to do things.  Not to mention, (as usual) real life gets in the way.

I wanted to release this little utility, as I've promised it to several people and finally have a version that is complete enough to be usable.  It serves as a soft lcd for any generic device controller.  Its the same basic code behind a lot of other things that I've written, except that now it pipes all the data in directly from the Python scripts, meaning its faster and much more capable.  I've made some significant improvements to the main Python Class, so that we can get things like updates whenever a new bank or device is selected.  I've also enabled a means to send updates to the components directly from m4l, which simply isn't possible in any of the existing scripts.  There is a lot left to do in this regard, but I'm going to take it slow and explore a little as I go, since the iPad script is functional as it is and this will only be making things faster/ more efficient.

Anyway...this little piece of code is pretty simple.  But if you examine it closely, I think you'll find a few very valuable things in there, and this is the best place to see it from (before it gets really complicated, which I'm sure its about to).  The functions I built in the main Class are pretty easy to follow,  but I haven't added any commenting yet.  If anyone has any questions, as usual don't hesitate to comment or drop me some mail.

All you have to do to make it work is place the Python script in your MIDI Remote Scripts folder, and open up the LCD patcher somewhere in your project.  The necessary assignments for the controller you are using are simple (rotaries @ cc 0 - 7, buttons @ cc 8 - 15, xfader @ cc 16, all on channel 1).  The script was intended for a Novation Nocturn, but you could use it with whatever you like.

I'll have much more to say about all this later...the link is on the right, under "LCD".

It's also here :

Cheers :)


Nomeout b941

I changed some things to accomodate the new midiOut features of the clients, and broke Nomeout in the current versions.  In lieu of changing every one of the clients to fix this, I'm posting a quick fix for Nomeout that will clear up the problem.  Hopefully, in the next week Nomeout will be a thing of the past, but in the meantime, be sure to download the new version (I suspect no one is using it anyway, which would explain why I'm just now finding out about this).

Thanks to David for pointing this out :)


Yeeeaah baby

I've had scarcely any spare time for coding lately; its the time of year I spend mixing live performances on a pretty much constant basis (I think I did over 20 this week, but at some point I lost count and it hurts my brain to think about it too much). 

Regardless, I found a little time to do some digging, and I've found a way to do what I want through the Python scripts.  That means we'll have a bit easier of a time accessing certain functionality of control_surface scripts directly from the LiveAPI.  It also means there will be a new plugin out very soon for the Nocturn, or other similar rotary controls. 

There will probably be an update to the Monomod host in short order that will switch a lot of the heavy lifting over to Python in the iPad script.  I need to fix a little problem with the APC controller script, as well.

Leigh Hunt has provided some externals for me to check out that may facilitate easier MIDI communication/routing on OSX, at least.  Thanks, Leigh :)  I'm so glad some alternatives for these issues are appearing at last.


Optional installs not optional?

I've heard from a little birdy that monomod is not working correctly without the installation of the "optional" files:  midiOut VST and OSCBonjour external. 

I'd really like some feedback on this.  If you've gotten the patches to work without these files, let me know by posting a comment.  If you had problems without them, also let me know.  Include your operating system and version, please.  Thanks :)



The b94 package has now been updated to include monomod_b941 (with corrected behavior for multiple launchpads) and a working TouchOSC template.

Also, check the new documentation page on the right for the details and features of monomodular.

Corrupt TouchOSC Template

Apparently the TouchOSC template contained in the package was corrupt.  I've made a seperate file download for a working one, you can find it on the right.  I'll repackage the entire bundle later tonight and post it.

Thanks to naph @ Live forums for bringing this to my attention.

Cheers :)



That was quick, huh?  Nothing big...I finally got to test it with two Launchpads, and it appears to work great.  I had to fix something in the javascript for the Launchpad, so make sure and download the new version.  I'm not changing the package right now, you can get it from the link on the right via Max for Live dot com.



Monomodular b94

I've gotten it as together as its going to be for a little while.  Please report any bugs that you find.  There are a lot of little things I keep running into as I'm testing it;  you can expect a small bug-fix release in a week or so unless I find out something major has gone awry.  I'm very interested to know how everyone gets on with this, so please drop me some feedback.

I've packaged everything that you need in one zip, you can get it here (on the right).  I will post the individual files to Max for Live as I have time.

I'm very interested to know if anyone is able to get this working with multiple Launchpads...I won't be able to test with more than one until tomorrow or the next day (someone is loaning me one).

Next up:  Frames for programming clients (just like browser windows). You will be able to set a frame definition via the client with a simple message so that a portion of the grid will be reserved for certain data while everything else goes on around it.

I'm going to build a _Framework script for an 8 knob controller.  It will work with Ableton's device system the way that the Novation Automap should work (I'll be using it with a Nocturn, but it will be freely assignable to anything that sends MIDI).

Plinko will get an editor window, so that someone besides me will be able to use it to good effect.

I've got several small plugins that need some work, including Life (which is almost finished), and Loopview,  a GUI for Sooperlooper.  Both are monomod clients.

...and hopefully an Ohm64 shows up in the mail this week, so I can start on that.

Be sure to read the Readme, and let me know if I left anything out.

Cheers :)


Maybe I got a little carried away

I started working on the APC40 portion of the scripts, and, well, kind of got lost in it for a few days.  I'm glad I took the time to do it, though.  I've worked out all the little bugs that the Python scripts were causing me, and now it pretty much works flawlessly.

Best of all, I figured out how to port all of the device_name dictionaries from the _Generic consts of the _Framework portion of the Python scripts over to javascript and m4l.  To those of you who don't know what that means (which, lets hope, is most of you...for your own sakes):  we now are able to get the same kind of readout for an HUD that you can get with, oh, say, a Remote25SL or a Mackie control, directly through m4l and this script.  Until Ableton changes that portion of the scripts, anyway.

So now the HUD works pretty flawlessly as well...whatever device you select will show correct parameter names and parameter values based on the dictionary, and if its not contained in the dictionary, the script looks it up through the API.  This makes the script faster, and above all: accurate.

I spent some time making sure the HUD displays correctly on any monitor.  I really need some feedback on this one, especially from Windows users.  I pretty much do everything on two identical MacBooks, so not a lot of good testing it here.   I'll add the capability of changing its size a little later.

Oh, and I added the capability of using Monomodular with the stock APC40 script, so if you're not using Hanz's version, you can still use Monomod.

I'll be porting the HUD over to a standalone when I've had some feedback from users and get the time to work on it.  The plan is to write a Python script that will basically emulate any 8 knob device controller, and give feedback through an identical HUD to the one I'm using for the APC.  Thus, if you have a Nocturn, Korg Nano, etc, etc, this will work for them with minimal setup.

The patches are almost done, I should have them published by Monday if all goes well.  I'm going to try to create an installer for OSX that will put everything where it goes, along with the abstracts for creating your own patches.  I don't have a clue (or an inclination) to do this on Windows, but if someone knows how and is interested in helping out, let me know.  I can always use help.

Oh, and the swell guys down at Livid were good enough to loan me an Ohm64 to work with, so we'll have support for that in the near future.

After the new revision is released, I'm going to start documenting how everything works with them here on the blog page, so keep an eye out.


Crawling crawling crawling...

I'm working out the final touches to the new patches.  It's hard going.  I've discovered a bug in Max's javascript implementation (I'm pretty convinced of that its a bug, anyway) that is requiring a substantial rewrite to some timing processes.  BUT.  If anyone out there is watching, you can expect a new and improved version of Monomodular that has the following great features very soon:

Auto client/host detection.
(this means that the host will detect all clients as soon as you load them, and delete those clients when you delete them: it will also remember a clients position if you delete it and reload it immediately).
The assignments are persistent between sessions, meaning once you set up a project, it stays that way until you change it.  It also allows you to create templates with your setup (via a Live song) and use those as a basis for any project.

Single plugin for 3 different hardware types:  iPad w/TouchOSC, APC40, and Launchpad.
Autodetection of TouchOSC via bonjour as well as manual assignment of OSC address.
Autodetection of all control scripts installed.

For the iPad:  an improved interface with true multicolor readout. 
a second page with monome 256 multicolor.
Improved performance overall, and I've reduced the amount of time to load the plugin.
I've also greatly reduced the amount of time it takes to create or delete a new track when using the plugin.

For the Launchpad:  navigation performance is improved.  You may now move in single cell increments, and there is a popup when User2 is pressed to provide quadrant navigation.  Current channel and plugin are displayed when you press User2.

For the APC: the same navigation features have been added as for the Launchpad.  Several annoying bugs have been worked out (like having to press shift at the start of a session before you can select grid-mode, switching between full and small modes now no longer kicks you out into clip-mode, and there is no longer the possibility of getting locked out of normal APC operation if you delete the plugin).

Also, broc@Live forums gave me the idea to use IAC for MIDI communication.  Now, Nomeout channels can be bounced to a virtual MIDI port through a ~vst object embedded in each plugin.  This means you can reroute each plugin on the fly to a different input channel in Live.  It requires the installation of the free midiOut plugin, but it works much better than the send/receive system I've been using up until now.  Hopefully Ableton/Cycling comes up with a better and more usable solution in the future.

MIDI port assignment is taken care of from the host plugin.  It will be persistent as long as the port order doesn't change.  That's the best I can do with what I have to work with ;)

I've created several new plugins:

Swing is a new Monomodular host: it can control swing for up to eight clients, assignable in the same manner as Monomod.

Osc-Client is a Monome emulator.  Its in its beginning stages, but it already deals with most Monome patches admirably.  This allows you to use Monomodular to control Monome patches without needing them ported to Monomod format.  It supports autodetection and col or row messages so far, I will implement other messages as I encounter them in Monome patches that I'm porting.

Dummy_client is a new utility for designing Monomod clients.  It allows you to link to the host via UDP when in edit mode, so that you can operate the client patch as normal while the Host patch is still outside of edit mode.  Simple, really.  I should've done this six months ago.

Knobs has been updated a great deal.  It is now a Monomod client.  It allows you to capture all of the current values of whatever parameters are assigned to each knob at the current value of that knob simply by pressing a button.  You can also store knob snapshots (64 of them) and recall them.  Snapshot selection, storage, and clearing are all available from the Monomod grid.  You may also clear individual envelopes from the grid, as well as capture parameter envelopes this way.

Knobs is accessible directly from the TouchOSC template:  the first four knobs are above the master/input/send knobs, the second four are handled by the two x/y boxes.  I think you will find this gives you the capability of controlling just about everything you need to in your set.

I've ported a couple more of Stretta's plugs, tintinnabulo and sment.  Sment has presets now.  Tintinnabulo still needs a bit of work on the preset system, but you can still store presets as json files  like in the original patch.  There will probably be a lot more to come now that I've built the OSC_client and the Dummy_client.

All the other plugins have been updated to work with the new host/client system.

I have it in mind to include support for the original APC40 script in the next revision.  After that I'm going to come up with a better method of preset storage...the method I've been using is effective, but its slow and cumbersome.  We really need a good way to store the contents of coll in a pattr.  Something will present itself, I'm sure.

I really just wrote this blog to give myself a pep-talk, I think (or a to-do list).  Back to work, as I'm almost done.



I'm sitting here watching the blinky lights on three different controllers dance for me in rhythm to the most intricate Live set that I've ever built.  That's a very good thing.  Its an even better thing that they are all doing it at the same time, with the same Live set.

Several weeks ago I had the bright idea that it would be a good thing to have only one patch to deal with.  So I basically rewrote every bit of all the control scripts I've made over the last year into one simple patch.  I wanted a single patch to be able to use for all of my controllers.  And I wanted them to be able to auto-detect which surfaces were connected, and save those settings between sessions.  I also wanted them to be able to autodetect which clients were connected, and save those settings as well.  And to be able to connect to a different set of clients, so each controller could have its own client list.  And and and....

Well.  It works.  And you can have it if you want it (very shortly, anyway).  I have some time over the next several days, so I will finish all the little nagging details, package everything up, and write some more ideas here to let you know what I've been doing, and why.

I've spent a lot of time documenting and cleaning up the code.  It will be much easier to build around now (for those that are interested), and there is much less guesswork.

I'm also looking forward to checking out a new patch Oliver has made in conjunction with Monomod, and making sure that everything runs as smoothly with it.  Hopefully there will be a lot of new stuff to release in the next several days. 


Incremental pattr

I just realized that some of you may be using patches that don't work because I've implemented an updated version of pattr. 

Make sure that if you are using Monomod and any of its client's (or any of my other patches) that you update the pattr external from the following page:

Hopefully this will be resolved in upcoming versions of MaxMSP.

On other fronts, I'm pretty far along on the next version of Monomod beta, which provides many new features:

Full multicolor support for the iPad, utilizing the new version of TouchOSC.  There is a much better feedback system for the grid, and a monome256 screen.  I am in the process of rewriting the framework to make things snappier when adding/removing tracks in Live, as well as overall stability.

The system is now more modular.  There will be a separate plugin for controlling swing.

There is now an automatic system for detecting hosts/plugins, so you can use multiple hosts of mixed types with unlimited plugins per project.  Each host will autodetect all clients present when a new host or client is instantiated in the Live set. Once you have configured the host with the order of its respective clients, the settings are stored across save-state for your Live set.

I am working at compiling all the control surface scripts into a single version, which will support all three interfaces (iPad, Launchpad, APC40) in a single plugin.  I am also going to add monome support when I have a chance (I don't have a monome, which makes this difficult...anyone have one they want to loan me? lol).

Cheers :)


Let's get on with it!

TouchOSC 3.6 is out. I am trying my best to contain myself. It's lovely how things coincide:)

Multicolor iPad Monomod goodness to follow shortly...


Everybody's Talking

Uhhhh....its four in the morning, one is talking (well, except my cat, and she really shouldn't be, so either someone slipped me something when I wasn't looking or I really should get some sleep).

I've managed to get a working prototype of the new monomods appliance.  Unlimited hosts, unlimited clients.  Configure it once, and it stays that way.  Use two or three controllers to control one patch, or use one or more controllers to control 24 patches.  Whatever.  Or build it yourself.  As long as the number of sends being used doesn't bottleneck everything, this schema should work out extremely well. 

Now that I've managed to finish this, I can stop thinking about it for a while and go have some fun.  Most of the hard work is done, now I just need to incorporate it into monomods and change a few things in the host patches.  The client patches shouldn't need any update at all :)

Cheers, if your watching.  I'll have a bunch of new stuff out toward the end of next week if all goes well (including some music, for a change).


If you're going to San Francisco...

I'll be there.  No flowers, though.  This weekend only.  Don't look for me on any billboards or marquees, as I will be playing the underground circuit (read:  a friends living room, probably)....

But that means don't look for me here, either, as I will actually be using all this code I've been writing over the last several months to some good end....wish me luck...I'll post the results on the other page when I get home on Monday or Tuesday :)



Macbook fuzz...and what it means to you.

This isn't the first time I've mentioned it.  This isn't the first time I've experienced it.  This won't be the last time you read it.

Ever wonder why your lappy gets so danged hot?  If you have a plastic macbook (pre unibody), and you're wondering why you can't seem to get the Ol' Lady to bake you some bread, well, look no further than your macbook.  If you find yourself,  in the dead of winter,  huddled around your shiny macbook instead of the hearth, you know what I'm talking about.  These things get ridiculously hot!  And that would be fine, if they were supposed to get that hot.  But they aren't.

Early on in my partnership with macbook, there was a moment when I thought it really wouldn't work out.  I mean, there was potential, but then suddenly, when I wasn't looking, it just started flaking on me.  My audio interface would suddenly drop out for no apparent reason.  I started rewriting code I thought was faulty, and generally investigating everything that I thought might cause this sort of thing.  I blamed my girlfriend (I still think, somehow, it was her fault). I went so far as to take my computer in to a service center, armed with KP logs and other data they didn't even know where to look for (or what they were looking at, though they were extremely helpful in every way possible).  Neither did Apple, apparently, because they had the service center replace the logicboard and give it back to me.

All was well...for about six months.  Then it started to happen again.  I was a little more savvy this time.  I opened the bugger up myself.  Uhhh....did you guys even look at this thing?  The inside was absolutely caked with....well....spooj.  It was like a dust factory in there.  Lint.  ANTS.  (they were dead, I think, but still....can't be good).  I had already invested time in installing some fan utilities, but my temperature had still been hovering around 80C at idle (of course, idle means that a lot is going on when you do the types of things that I do with my poor little macbook). 

A can of air later, and a little tightening of screws (with no extras!) and I was back in business.  What had been 80C was now 50C.  That's....well, a bit of a difference.

I did it again about six months later when my CPU started quitting randomly (which was fortunate, since I probably would've ended up with second degree burns if it hadn't).  Another can of air, voila'!

Now I'm on the third can.  I just did it today.  No ants this time, that was a refreshing change.  Still, though, this puppy was getting pretty hot, and I'd lost the minimum of an hours work due to random forced power cycles.

This is a design flaw, certainly.  The real problem is that  the low temperatures will only last for a couple of weeks, and then they start creeping up again.  Because I know of the issue, I don't feel so nervous about it.  I have talked to so many people that have similar problems, though, and they know nothing about it.  The fact that Apple didn't know what to do about the situation just goes to show the level of knowledge that most of these people have.  Its a very simple thing, and I can't imagine that having blown out my laptop 4 times in 2 years from the necessity of avoiding crashes and random heat protection restarts, everybody else is getting away without any problems.

Or maybe I'm just really dirty.

Spread the word.


Just finished a new patch (its actually part of the original monomod patch...I'm trying to split things up and make them truly modular).

Knobs allows one to control eight different parameters with the twist of one knob.  The parameters can be across the entire project, and use breakpoint envelopes with variable beginnings and ends to edit the values.  Its pretty powerful, now I just need to find out how stable it is. 



Monomod Client Dummy Plugin

Here is a quick and dirty patch to prevent Live from bogging and sends from breaking while you are  designing a Monomod patch.  I haven't used it yet, but the theory is sound ;)  Let me know how it works...I've always done it the hard way, but I think next time I will give this a try.


About the monomods abstract...

I just wrote a quick introduction to the monomods abstract, in case any of you are trying to figure out what is going on.  It can be accessed from the page list on the right.  Cheers :)


Monotes release

I just posted monotes, a little plug that allows MIDI note assignment to the grid.  Its pretty simple, if you have any questions or requests give me a shout.

Cheers :)

A little update....

I'll probably be taking a bit of a break in coding over the next couple of weeks.   Personal things coming up, and, well,  its Summer, right?  I think the sun is out or something....

I'm going to take a closer look at Polygome and implement some features I'd like to use, as well as make sure that the existing structure of the patch is sound.  I need to get my rig up and running so I can test all this stuff in a performance setting and make sure everything works.

I'm coding a little patch that will map the grid to a MIDI output map.  Basically, I'm just ripping the program window out of Plinko and allowing direct output to either the MIDI output of the plugin, or a Nomeout, so that its output can be sent to different destinations.

Plinko will get a few bug-fixes (things that didn't translate exactly right when I ported it from the js), a pop-up program window that will explain exactly what is going on in each node when its selected (so that tutorials will hopefully be obsolete: you will be able to tell what is going to happen by just pressing a node), and I better preset clearing and copying.

There will be a another new plugin that allows one to route Monomod directly to either a m4l or standalone monome app by assigning an OSC input/output.  I think I'll add a section to allow the user to type in custom commands for the built in functions of Monomod (the mode and timing buttons), although I don't know if this will really be useful.  I'm not using any standalone patches, but I do use Molar sometimes, so I'll probably test it out with this.  Any suggestions are welcome.

I'm holding off on publishing the abstracts for Monomod implementation only because I want to make sure everything is rock steady and isn't going to change substantially with future builds.  You can always check them out or rip them from current plugs if you have the desire.  I just haven't commented what things do, and I know this will be useful.  I'm trying to decide how to implement an autodetection system so that the Monomod host knows what clients are present in a project, and this will drastically change the content of the abstract.  I'm hoping to make setup completely transparent;  just add Monomod, drop in clients, and go.  There will still be the capability of assigning channels manually in each plugin window.

And finally, I'd like to find the time to unify the Monomod plugin itself, so it can run up to 4 different control surfaces at once, and mix/match different types.  That will probably take a while, as I have to clean up a lot of the js scripts I've built.  There is a lot of deprecated portions of the framework, and some additions/modifications I want to make to the iPad portion of the script.  Obviously, this would be a lot easier if Rob would update TouchOSC, hence my own procrastination about this bit.

There is a patch I made a long time ago called "Knobs" which some of you may be interested in, I'll try to get it out in the next couple of days.  I want to make some additions to it so that track volumes and sends can be selected for control, as well as all the device parameters. I've found it very useful, and it is somewhat different from the other patches around that do similar things.

I'd love to get some feedback on the updates to TR256.  I've used it a bit since the last changes and found the recording functions pretty stable, but I'm wondering if others have had the same experiences.

Things will trickle a little at a time, keep an eye out.

Cheers :)


Monomod b932rc out to those who are following this:  I'll post this stuff up on when I am sure that there aren't any obvious bugs.  If you are on the mailing list, I'll send you a link to the files.  If your not on the list and you would like to be, make sure I have your email:

Additions/bugfixes/improvements to b932rc:

Plinko: fixed problem with not being able to see grid activity, problem with random restarts, restart on time change option

Gome: possible fix for note duration on first loop (not fully tested yet).

TR256: Added real-time MIDI recording functionality (press sequence play then edit to toggle: sequence edit and play will both change colors), copy/paste (press sequence edit to copy then sequence paste of the sequence you wish to paste to), clear sequence (press sequence edit then any of the mode buttons on the left), trigger sequence on timing change (see below), and trigger sequence step (press play then the step of the sequence you wish to start from).

Trigger sequence on timing change works like this: if its turned on, and you change timing, on the next downbeat it will trigger the current sequence from the beginning so that it coincides with the downbeat.  Plinko will work this way in the future, and possibly Polygome.  I want to test it out realworld for a while and see if anything needs to change with it before I spend a lot of time converting other plugs with the same functionality.

Recording hasn't been tested much, so I assume there will be issues.  Everything is quantized to the timing grid of what is currently selected.

All the copy/paste/clear functionality is sluggish.  This is due to the way in which I have had to store program data within m4l.  Sorry...its the price of being able to save and recall everything easily with each song/preset.

Boinngg and Presscafe: largely untouched, I merely updated the timing engine for them.

Please let me know if you find any problems.

Next on the agenda (besides testing these plugs) is getting a Plug together to deal with native Monome patches.  Oh, and something like "Pitches" (that shouldn't take too long, except that I'd like to figure out a way to re-inject stuff back into control_surfaces so that the plug can also control drumracks ala' external controllers).

On second thought, first order of business will be to get the [monomods] core abstract commented, so I can post it and you guys can know what is what.


Monomod Central

I'm moving my blog (which I never use, because its a PITA) to here....I'll link it from my site. 

I'll make this the "official monomod resource"....whatever that means.  Feel free to comment.

Current status:  b932, everything compatible back to b93.  Should be posted tonight.  Working on record capability and copy/paste for TR256.