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 :)
23.7.11
20.7.11
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
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
21.4.11
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!).
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!).
1.4.11
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
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
31.3.11
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
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 :(
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 :(
15.3.11
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 :)
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 :)
Subscribe to:
Posts (Atom)