header image
 

Monomodular Subversion

I’ve set up a svn account with Google Code for those of you that are brave and want access to the work in progress. Everything is current with my own working copy, but again, no documentation.  I’ll be working on videos tomorrow, and hopefully will have a package for the Ohm64 and iPad by the end of the weekend.

In addition, I’ve ironed out some problems with Plinko tonight, so its nearly ready at this point.  Big performance boost with this one, and I’ll try to focus some time on recording a better instructional video.

SVN site:  http://code.google.com/p/monomodular

I’ll have an installation package for you as soon as I have a chance to finish up some more details, but it may be a week or so before things get to that point.  In the meantime, I’ll post important changes and additions here.

Please drop a comment if you find any major issues, thanks 🙂

Breaking the (Silence)

Hi to all of you that are following this.  I’m very sorry for being out of touch for so long.

I’ve just returned from a three week vacation, and its time to get back to work.  It will take a  few days to get back in the swing of real life,  but honestly I think any more ‘vacation’ might have killed me.  Its good to be back!

I know that it probably appears like I’ve dropped the ball on Monomodular since I haven’t posted here in a while, but the fact is that I’ve been hard at work on several projects, and a new, completely revised edition of Monomodular is very near completion and release.  In fact, I’ve been using the new Ohm64 RGB Monomodular scripts for well over a month now, and I’ve had very good results.   I’m not going to get into too many details, but I guess I can spell out some of the major changes that have been made since the last public version.

First off, the Monomodular engine is now built completely in Python.  It is inserted as a MIDI Remote Script in Ableton, and communicates directly with its connected surfaces through the Python backend of Ableton.  This means an increase in speed, and a great deal more simplicity in setup for the user.  Instead of needing a host plugin loaded in Live, one merely loads the appropriate Remote Scripts in Ableton’s preferences and everything remains set between projects.

Because of the change in the Monomodular host-side  architecture, things have changed on the client end as well.  Currently, each client will auto-detect its position (‘bank’) to be inserted in, and can be manually changed by the user after insertion.  This state is saved across project loads.

I was able to condense the number of API objects required to communicate with Ableton’s control_surfaces to just two….hopefully this will mean more stability in the long run, and certainly means ease of programming in the short.  Those of you writing in Python will do yourself a favor by examining my methods, as I haven’t seen them anywhere else, and they weren’t arrived at without a lot of fumbling around with ways that didn’t work nearly as well.

In addition to porting all of the Host code over to Python, I have created some new externals for the engines in Boinngg and Plinko.  No more skipping or timing inaccuracies, and you can now save presets in Boinngg.  Also, run them as fast as you want.  Sixty four note triplets?  No problem 😉

The iPad version of the scripts is also nearly finished.  It is a complete rewrite, which utilizes a lot of new Python tricks I have learned from past experimentation.  You can expect to see these initial scripts published sometime in the next week, with others to follow as I have time to prepare and test everything.  I also plan to provide scripts for APC40, Launchpad, Block, and iPod/iPhone via TouchOSC.  The current working versions support Ohm64, Ohm64 RGB, Code, and iPad.  The Code remote script is thus far incomplete, but functional none the less.  I hope to get a chance to enrich it a great deal in the near future.

The fact that all the host-side support exists in Python now makes integration with new scripts much easier and straight forward.  This means that I’ll probably integrate Monomodular support into some other generic scripts as time permits (e.g. the stock Code and Ohm64 scripts, as well as the new Code/Griid script).  If someone wants to send me a Monome, I’d be happy to integrate it as well.

I also have several new client plugins I hope to finish in the near future.  No promises, but you’ll see at least two dedicated Code clients (one for effects similar to ‘Knobs’, and a new step sequencer with integrated multicontroller grid support) and a new generative ‘game of life’ patch for the grid.  Unfortunately right now I have more ideas than I have time to write code for them.

I had hoped to release all of this material at the same time, but it has taken me longer than anticipated to complete working versions.  Unfortunately, the next round of releases will probably trickle out a little bit at a time over the next several months.  The truth of it is that I had redesigned all of this new version in a completely new way within Javascript before I decided to chuck it and rewrite everything in Python.  So you might notice that the next public version will be b99, skipping completely two subversions that were never released.   My apologies for this, but at least you can be sure that the next release will be stable, and the main components won’t be changing again until the next major Live/Cycling release. 

Those of you that wish to create your own client patches will have better tools to do so.  I have already designed a much more instructive ‘Help patch’ with some built in tools and scripts to make things faster more easily understandable.  Although not finished yet, I think that its a step in the right direction.  The last thing that I’ll do before releasing any of this is to record some videos of the pertinent sections of the Remote Scripts, along with some instructions about what each of the client patches are supposed to do.  If you are wondering what is taking so long, you can be assured that THAT is what is taking so long.

So keep in touch, and be assured that just ‘a little more patience’ is all that is required.

Also, if your in San Francisco in late August, you may want to check out an event I’ll be part of at the Gray Area Foundation for the Arts.  Cullen Miller and Chris Willits have put together an evening of performance and instruction with the theme of ‘Hacking Ableton Live with Max for Live’, and I’ll be the first presenter.  Get a look at the awesome new Ohm64 RGB, along with the new tools I’ve been building in Monomodular for use with it and some other controllers.  Here’s a link to the official announcement, I think:

http://www.overlap.org/blog/text/13387803

Keep an eye out here, and I’ll try to get the core nuggets out to everyone this weekend.

a

New Direction

I spent some time over the last couple of weeks designing an amended version of the APC40 script.  It adds some new functionality and improves on some of the old;  I’m still testing it out as time allows, but you can look for it in the near future. 

I’ve made some decisions about the future direction of my patches, after having made some further (awesome) discoveries about ways I can manipulate the _Framework scripts to my own end.  Bottom line:  in the version 1 release of Monomodular, all the heavy lifting will be done by the Remote Script itself.  There will be no host patches, only client patches.  All you’ll have to do is install the Remote Script for your particular device.   More details as I have time to do some testing (and hopefully this is not a huge waste of time!).

Also in the (hopefully not too distant) future:  support for Livid’s Code.  They were kind enough to send me some hardware to work with, so you can expect a new Script for it, and some Monomod patches as well.  I’ve got several cool ideas about how to incorporate this thing into Monomod.  Of course, you’re at the mercy of my own whims and workflows.  Anybody out there already have one of these things?  I’m curious how people are using them right now….

Of course, this all depends on me getting fired from one of my day jobs (but don’t fret….I’m working on it!).

Some observations about the 8.22 update and m4l

Just a quick note…I’ve spent last night fixing some things that got broken with the most recent updates of Max and Live, and I thought I might mention a few things that I found.

I was very disappointed at first that all of my LCD patches were broken for my controllers.  That is:  it was no longer possible to get the actual value of a parameter by calling an objects ‘mapped_parameter’ from a ‘control’ in ‘control_surfaces’.  Instead of giving you the parameter value (e.g. ‘-23 db’ instead of the 0.0 to 1.0 that you can get from parsing it from the ‘live_set’), it gives you the idea of the mapped parameter in the live_set.  After mucking about with it for a while, I realized this would do me no good in this instance, because there is no current way now to get this info (‘-23 db’ instead of float 0. to 1.). 

However, this is great news:  this means that most of the work I did in the Python scripts to gain backend access to the scripts is now unnecessary, as you can do all of this stuff directly in m4l.  I think this means I’ll be able to ammend the Ohm64 scripts to make them much more readable and configurable in the future.

As far as the problem of getting the verbose value of a control, that has been managed within my Python scripts now.  Its very annoying to me that this information STILL is not available to the user from within m4l as a standard asset, but at least there is a workaround.  I’ll continue working as time permits, and hopefully have some updates in coming weeks.

There are a lot of other features in the new updates that should make my patches much more efficient at what they do, so I’m hoping to have a little time to spend on them.

Cheers 🙂

a

Quick Fix

Since I don’t have a working Ohm, all I could do was trace the obvious problems and fix them.  Here is a link to the MonOhmPad script that should work with Live 8.22.  It will load, but I can’t test it further for a while.  Please provide me with feedback and copies of your log.  Good Luck!

http://dl.dropbox.com/u/6044993/MonOhmPad_b972.zip

New Toys! ….er, nevermind.

New versions of Live and MaxMSP have arrived, and I’m happy to say that it looks very promising.  I see some easy solutions to some problems I’ve been having for a while (especially initialization ordering).  You can look forward to some updates when I have time to sit down and have a look-see.  I’ve been trying to bend my time towards making some music lately, which means that I’m discovering bugs, flaws, and ergonomics issues with all of my patches.  Bad in the short term, but good in the long term as I have a chance to fix things.  Cheers 🙂

edit::  so much for that.  Ableton has changed the remote scripts.  Everything appears to be broken (Hanz’s scripts as well, as far as I can tell).  I would fix my Livid scripts, but….

My Ohm64 has picked today, of all days, to completely take a dump.

Heavy sigh…..

I can’t even switch back to the APC, because my scripts are broken for it, as well.  In any case, it looks like I’ll be fixing the APC scripts first, since I actually have one that works….

Sometimes progress is painful 🙁

Quiet….I’m thinking.

I’ve done very little programming for a while.  My head has departed from the: “what can I do with the controllers that exist,” to the : “how can I make the control surface that I really want”.  I’m very happy with the software tools I’ve created, but I don’t wish to write anything further until I’ve decided exactly what I need to incorporate into a final version of Monomodular to support what I have in mind for a “all-inclusive” grid controller.

What does that mean, exactly?  Well, let’s just say this:  it hasn’t been done yet.  When I’ve got a working prototype, I’ll post more details.

In the meantime, I’ll be trying to navigate back to older versions of Monomodular to add some stability to them , as well as adding a few new features and fixes to the Ohm64 scripts. 

Coincidentally, as I’m writing this I’ve just received a box in the mail from Mouser…now the fun begins 🙂

Construction Time Again

Just a quick note….

I’ve mostly been dealing with ‘Life’ lately (no…I mean ‘REAL Life’, not the generative Monomodular patch I’ve been promising to release for over a year and haven’t gotten around to….ironic)….mostly running live sound a lot.  Last week I experienced the ultimate in dichotomy:  first, I ran sound for Bassnectar (probably the loudest show I’ve ever done), and the following day I ran sound for the Bee Eaters:  four large diaphragm condenser mics, all several feet from the performers, mixed so that its only loud enough to sound like you are standing right next to the musicians anywhere in the room.  It might have been nicer if the Bee Eaters show had been BEFORE  Bassnectar.  And of course, I’ve been reassembling a 78 VW Bus after catching it on fire two months ago (it will be nice when I’m “mobile” again).

Monomodular has taken a back seat lately, but I’m still working.  Debugging is much more difficult now that I’m compartmentalizing things….I hit a snag last week and just finally figured it out.  I got the current version up and running last night, though, so progress is being made.  I have no idea how long the rest will take, as this is a very major rebuild of the whole framework.

In the meantime, if you want to try out the current beta version of the material, there’s a link at the bottom of this post.  I had held off making this public as long as possible with the hopes of releasing a full package for all the supported controllers, but I simply haven’t been able to finish everything as soon as I’d hoped.  I got a little too ambitious with this new version, but all in all, it will allow me to integrate more types of hardware controllers much more easily into version 1.0, as well as allowing expansion of the feature set of Monomodular considerably in the future. 

If you have any issues/questions about the current beta package, please drop a comment here, or feel free to contact me directly.

Cheers 🙂

http://dl.dropbox.com/u/6044993/Monomod%20b96b_release.zip

Please note that this beta version is only compatible with the Livid Ohm64….the other controllers haven’t been reintegrated yet.

A little stumped….

Its funny that I’ve been able to do all this hacking to other peoples code, and now that I’m working with code that I wrote my self, I’m having difficulties. 

The integration for the iPad version of the MonOhmPad script is nearly done….I have some details to work out (mostly displaying correct parameter names/values when they change assignments), but its working swimmingly.  That means I’m using an iPad as a control surface to communicate directly with Live’s Python scripts just as though it were an actual Ohm64.  (I needed to write that, it kinda felt good 😉 ).

So, now I’m working on completely rebuilding the Monomod framework so that it is configurable in a more general manner.  I’ve used the _Framework as a guide, and I guess I’m finally getting the idea of what object oriented programming really is.  But I’ve hit a bit of a snag….there’s so many different ways to go ! 

I hope to present a completed version by the end of the weekend (simply because I have other things I’d rather be doing than staring at a computer screen for hours on end).  I’m taking my time with it:  the idea is to create the framework I’d originally intended on, which will make it a great deal easier to add new control surface support as I/others have time.  I had hoped to make it understandable to the general user, but I guess I kind of missed that boat when I used the _Framework scripts as a model.  Anyway, the final version of Monomod will contain a single js contained in a very barebones Max patch.  Eventually, I plan to code a pure Python version of Monomoduar….wouldn’t that be nice 🙂

Nitty Gritty

I’ve been plugging along all weekend (pun-intentional), splitting time between fixing the VW (what a mess!  I wish I could script its problems away….) and writing code to integrate the m4l stuff with the new version of the Ohm64 script.  I’ve made good progress.

The final release will probably take a little longer than I originally planned (imagine that? hehe).  I’ve rewritten the entire framework of the m4l stuff based on what I’ve learned from the _Framework scripts in Python.  Its very satisfying to be able to port entire sections of my older scripts in a very quick, easy manner and have things just work.  On the other hand, I’ve been taking my time so that the new javascript framework/objects are as reusable and programmable as possible.  I have it in mind to make some new layouts for the iPad in the future, and I’d also like the framework to be accessible to others that may want to use it.

I haven’t been able to achieve everything I’d hoped with the direct use of the Python scripts and m4l.  I (grudgingly) was forced to create a nameserver in javascript, instead of doing it in Python.  The reasons for this are various, but mainly I do not want to replace framework elements wholesale….if I cannot provide an override for a Class, or come up with a workaround in the main Module, I’ll do it in m4l.  It seems like this is the best option for compatibility.  I will be investigating the Serato scripts to see if I can find better solutions than what I’ve currently worked out.

Finally, I plan on making a few key changes to the Ohm64 base script before release.  It’s come to my attention that grid navigation is less than desirable with the script.  I have to agree, and its been bugging me for a while.  I’m going to add an extra shift mode that utilizes one of the top left keys to make the bottom left buttons become navigation keys WITHOUT zooming the grid out.  This way you will be able to move track/scene at a time while still looking at the grid (Launchpad style) as well as have a visual indication (via button lighting on the bottom) of which directions are available to navigate.  Hopefully this extra mode doesn’t make things too confusing for those of you that might already be a little fuzzy.

The Monomod script is currently working in its new incarnation, but it might be this weekend before I get it into everyone’s hands (or longer, I guess, but I’m being optimistic).  I’ve stopped playing with the Ohm64, and am now working solely on integrating TouchOSC with the Python scripting so that you can either use the iPad as a replacement for the Ohm64, or use it for additional input/controls via the same script (the first release will probably not include many extras, but you will be able to use the 256 Monome multicolor grid at the same time as the Ohm64, and hopefully I’ll have time to port some simple LCD feedback to the same patch so that the iPad displays the same sort of thing that the LCD patch in m4l does).

Just wanted to post a short update, I’ll be in touch.  Cheers.

a