I've updated enough of the new website to move everything over there.....I'll be there for now on.
a
http://www.aumhaa.com
27.12.11
Solsticized
Lemur stuff is up on SVN, for those of you that are waiting. Ignore the LCD portion, and report errors please :) Far from finished, but plenty functional. I recommend MyWi if you're jailbroken, its blazing fast....(how did I not know about that until a week ago?!)
Max4Live native Installers for both platforms are finished, and in the testing stages with several helpful users. They should be available in several days to the public, and will download direct from the SVN repo to install in the correct places on your system. If you're savvy, you can grab stuff from SVN, but the point, I guess, is that things are going to be changing regularly from now on, and the installer will make it much easier to stay in sync if you are so inclined.
I'm focussing on the new website next, which among other things holds a wiki that will be linked to from all of the individual Mods for better documentation (another reason I had to finish the installers). Hopefully my next blog post will be from there!
I'm trying to get some live music and artwork up there as well this week, so if your interested keep an eye out....so many things to do hehe.
Happy new year to all, its going to be a very interesting one ;)
Stay tuned.....
a
Max4Live native Installers for both platforms are finished, and in the testing stages with several helpful users. They should be available in several days to the public, and will download direct from the SVN repo to install in the correct places on your system. If you're savvy, you can grab stuff from SVN, but the point, I guess, is that things are going to be changing regularly from now on, and the installer will make it much easier to stay in sync if you are so inclined.
I'm focussing on the new website next, which among other things holds a wiki that will be linked to from all of the individual Mods for better documentation (another reason I had to finish the installers). Hopefully my next blog post will be from there!
I'm trying to get some live music and artwork up there as well this week, so if your interested keep an eye out....so many things to do hehe.
Happy new year to all, its going to be a very interesting one ;)
Stay tuned.....
a
18.12.11
Corners
I guess its to be expected when one spends so much time dealing with grids and graphs and squares and angles. I'll be turning a corner here soon....but for the moment I seem to have backed myself into one.
Several things are coming down the pipe. But unfortunately things have gotten out of hand on my end, and I'm not able to accomplish what I want as quickly as I'd like. So be patient please, and I'll in turn try to be more patient with myself...
Aside from getting my own Live rig up and running, here's what I'm currently working on, most of which is finished at this point:
A new Website and Wiki for Mods.
Native Live installer for OSX and Windows (OSX version is mostly done at this point).
Pedal for Looper (plugs directly into OhmRGB/Block expansion port, and soon into Arduino-based hub)
Mystery hardware device ;) (yeah, I've been talking about this one for a while...I'm back on it again).
Looper plugin (getting really close on this one).
AumPad II for Lemur (finished).
Aum256 II for Lemur (finished...I think?).
AumPad update (found some serious bugs...see below).
Aum256 (256 grid - only version of AumPad...this has been finished for a while).
New LCD that contains all compatible scripts in a single device, and also transmits to TouchOSC/Lemur.
Fixes for Tintinambulo (found a few bugs in that one).
New Boids patch (finished...a while ago).
New Conway patch (finished...a while ago).
General speed improvements for MonOhm/AumPad scripts.
Soooo....most of this stuff is ready, but I have the following dilemma:
In order to release all this new stuff and not waste a lot of time packaging it, I need to finish the new installer.
The new installer will take care of most of the difficulty of distribution for me, and allow me to add things a little at a time.
In order to release the new installer, I have to finish designing the wiki and website, which the new installer is dependent upon for documentation, etc.
Consequently, it might be a while before the next official sub-release happens. I'm trying to get things together as quickly as possible, but I'm actually spending more time on narcissistic exploits right now (things like releasing some old recordings made with Mod and making some new ones).
Here's the good news: if you want any of this unreleased stuff, drop me some mail and I'll happily send you the goods via email along with the new installer if you're on OSX. In addition, as soon as I have a chance to check out the newest versions of the files, I'll add them to SVN and the current install package...there's just no telling when this is actually going to happen.
Several things are coming down the pipe. But unfortunately things have gotten out of hand on my end, and I'm not able to accomplish what I want as quickly as I'd like. So be patient please, and I'll in turn try to be more patient with myself...
Aside from getting my own Live rig up and running, here's what I'm currently working on, most of which is finished at this point:
A new Website and Wiki for Mods.
Native Live installer for OSX and Windows (OSX version is mostly done at this point).
Pedal for Looper (plugs directly into OhmRGB/Block expansion port, and soon into Arduino-based hub)
Mystery hardware device ;) (yeah, I've been talking about this one for a while...I'm back on it again).
Looper plugin (getting really close on this one).
AumPad II for Lemur (finished).
Aum256 II for Lemur (finished...I think?).
AumPad update (found some serious bugs...see below).
Aum256 (256 grid - only version of AumPad...this has been finished for a while).
New LCD that contains all compatible scripts in a single device, and also transmits to TouchOSC/Lemur.
Fixes for Tintinambulo (found a few bugs in that one).
New Boids patch (finished...a while ago).
New Conway patch (finished...a while ago).
General speed improvements for MonOhm/AumPad scripts.
Soooo....most of this stuff is ready, but I have the following dilemma:
In order to release all this new stuff and not waste a lot of time packaging it, I need to finish the new installer.
The new installer will take care of most of the difficulty of distribution for me, and allow me to add things a little at a time.
In order to release the new installer, I have to finish designing the wiki and website, which the new installer is dependent upon for documentation, etc.
Consequently, it might be a while before the next official sub-release happens. I'm trying to get things together as quickly as possible, but I'm actually spending more time on narcissistic exploits right now (things like releasing some old recordings made with Mod and making some new ones).
Here's the good news: if you want any of this unreleased stuff, drop me some mail and I'll happily send you the goods via email along with the new installer if you're on OSX. In addition, as soon as I have a chance to check out the newest versions of the files, I'll add them to SVN and the current install package...there's just no telling when this is actually going to happen.
8.12.11
Lemur Module on the way...
Got the news late last night...Lemur for the iPad. Something I expected to see, well, about two years ago.
Guys at Liine did a good job, as far as I can tell. It took me a while of wading through the manual to find out the things I needed to know, but once I found the pertinent information I was up and running.
So you will see a module for lemur that does exactly what the current (unreleased) version of the Aum256 script with the next release. Its probably going to happen next week...I'm getting impatient about finishing up the Windows version of the installer (due to lack of time/the need to finish installing all of the components on the Windows partition of my dev machine), so all the new stuff will probably get released as a subrelease of b992.
For those of you presently using TouchOSC and AumPad, I can tell you that the Lemur version of Aum256 should be a great deal faster. Can't promise anything though....I'll have to do some testing. But initially, I've been getting much faster results using it.
It makes me wonder why I didn't just buy a Lemur 2 years ago.....sheesh, I do go the long way around sometimes.
Also, thanks to another user tip, I've been alerted to a serious flaw with my last rev of Tintinambulo (the timing engine got taken out and never put back in), so I'm in the process of updating that.
I'll make another post when I finally get all this stuff published. I've got several other real-life responsibilities at present, so it may be the beginning of next week before you see anything.
I'm starting to feel the overwhelming vastness of all this stuff I've been making again....its kind of crippling me. If I disappear for a bit in the upcoming holiday season, rest assured on I'm working on things, but being quiet about it....
a
Guys at Liine did a good job, as far as I can tell. It took me a while of wading through the manual to find out the things I needed to know, but once I found the pertinent information I was up and running.
So you will see a module for lemur that does exactly what the current (unreleased) version of the Aum256 script with the next release. Its probably going to happen next week...I'm getting impatient about finishing up the Windows version of the installer (due to lack of time/the need to finish installing all of the components on the Windows partition of my dev machine), so all the new stuff will probably get released as a subrelease of b992.
For those of you presently using TouchOSC and AumPad, I can tell you that the Lemur version of Aum256 should be a great deal faster. Can't promise anything though....I'll have to do some testing. But initially, I've been getting much faster results using it.
It makes me wonder why I didn't just buy a Lemur 2 years ago.....sheesh, I do go the long way around sometimes.
Also, thanks to another user tip, I've been alerted to a serious flaw with my last rev of Tintinambulo (the timing engine got taken out and never put back in), so I'm in the process of updating that.
I'll make another post when I finally get all this stuff published. I've got several other real-life responsibilities at present, so it may be the beginning of next week before you see anything.
I'm starting to feel the overwhelming vastness of all this stuff I've been making again....its kind of crippling me. If I disappear for a bit in the upcoming holiday season, rest assured on I'm working on things, but being quiet about it....
a
3.12.11
Windows....grrrrrrr
I'm posting this from my iPad, since my dev computer has been sufficiently rendered impotent at the moment by my attempts at installing a working version of Boot Camp on it. Please ignore any misspellings or overt sexual innuendos, assume they are the result of ios's amazing and entertaining spellchecking features.
I've been busy lately playing with monomodular, and adapting some new generative plugins for use with the current suite. Also, there will be a new m4l based installer released with the next revision which will allow users to connect to subversion and download the most recent revision of the suite, all from within Live. I'm hoping it doesn't catch anyone's computer on fire.... It requires nothing beyond a single .amxd file on macos, but unfortunately will require a java class file to be in the right place for windows users. The osx version is finished and working on several machines, but I haven't had time to finish the windows version yet (thus the boot camp debacle).
In addition, I've finished the 256 TouchOSC patch, but am waiting for release until I finish both installers. I had some strangeness the other night with it, which corroborates someone else's report of ridiculous latency, so I'm going to examine the situation further before release.
In other news, the looper has undergone some serious surgery and is working better than ever. Hopefully it will make it into the next release. I'm currently building a switch/pedal for it that will connect directly to the block/ohm's expansion jack and allow direct control of the looper and some scene firing functionality with the next versions of the python scripts.
I'm happy to see more and more people recognizing the potential of monomodular, and the support is greatly appreciated. There are several new videos up on YouTube covering different setups and instructions for use, and I'll try to link them later when I have a real computer to use again.
I'm trying to get a website together to showcase some of the "music" that I've made over the last several years of developing this stuff and to permanently house all the documentation (that I intend to write someday ;) ).
Happy blinking :)
I've been busy lately playing with monomodular, and adapting some new generative plugins for use with the current suite. Also, there will be a new m4l based installer released with the next revision which will allow users to connect to subversion and download the most recent revision of the suite, all from within Live. I'm hoping it doesn't catch anyone's computer on fire.... It requires nothing beyond a single .amxd file on macos, but unfortunately will require a java class file to be in the right place for windows users. The osx version is finished and working on several machines, but I haven't had time to finish the windows version yet (thus the boot camp debacle).
In addition, I've finished the 256 TouchOSC patch, but am waiting for release until I finish both installers. I had some strangeness the other night with it, which corroborates someone else's report of ridiculous latency, so I'm going to examine the situation further before release.
In other news, the looper has undergone some serious surgery and is working better than ever. Hopefully it will make it into the next release. I'm currently building a switch/pedal for it that will connect directly to the block/ohm's expansion jack and allow direct control of the looper and some scene firing functionality with the next versions of the python scripts.
I'm happy to see more and more people recognizing the potential of monomodular, and the support is greatly appreciated. There are several new videos up on YouTube covering different setups and instructions for use, and I'll try to link them later when I have a real computer to use again.
I'm trying to get a website together to showcase some of the "music" that I've made over the last several years of developing this stuff and to permanently house all the documentation (that I intend to write someday ;) ).
Happy blinking :)
16.11.11
Nothing but the black Abyss of the bean.
Yeah, so I've been drinking too much coffee lately. It makes me feel nice. Till about the fourth cup, anyway....
I've put up the first two parts of some video tutorials I shot last weekend. They just detail some information about the new Monomodular functions, and give an account of what Binary does. I've shot some footage for EndCoders as well, but I may reshoot it before I get around to actually putting it up.
I've been retooling my studio a bit, and trying to make some music. These processes are both exceedingly rewarding and discouraging at the same time. Perdurabo!
I'm currently spending the most amount of time testing and refining things with the new suite, and finishing up the Looper plugin I've been working on for the last several months. Its closer to being done now than I thought it would be....I've finally managed to get the tricky timing bits worked out. I'll put some video of the process up as soon as I get some free time.
On the horizon for b993:
iPad TouchOSC template/new Script with only the 256 Monomodular screen (I need this myself).
AumPad speed improvements.
Python speed improvements (for some reason refresh calls are getting made way too many times ever since b991).
New Alt functions for Monomod: Mute plugin, Disable plugin. Taking additional suggestions on these.
Looper Plugin.
Monome support rewrite.
Improvements and bug-fixes for Binary and (especially) EndCoders.
Grid-based snapshot support for EndCoders.
Hopefully, though, the next thing I release is music instead of code ;)
a
edit:: Oh, I almost forgot. Markus Naumann has produced some further tutorial videos for you to watch, hosted on his YouTube site here:
http://www.youtube.com/user/morphicfield
Thanks Markus!
I've put up the first two parts of some video tutorials I shot last weekend. They just detail some information about the new Monomodular functions, and give an account of what Binary does. I've shot some footage for EndCoders as well, but I may reshoot it before I get around to actually putting it up.
I've been retooling my studio a bit, and trying to make some music. These processes are both exceedingly rewarding and discouraging at the same time. Perdurabo!
I'm currently spending the most amount of time testing and refining things with the new suite, and finishing up the Looper plugin I've been working on for the last several months. Its closer to being done now than I thought it would be....I've finally managed to get the tricky timing bits worked out. I'll put some video of the process up as soon as I get some free time.
On the horizon for b993:
iPad TouchOSC template/new Script with only the 256 Monomodular screen (I need this myself).
AumPad speed improvements.
Python speed improvements (for some reason refresh calls are getting made way too many times ever since b991).
New Alt functions for Monomod: Mute plugin, Disable plugin. Taking additional suggestions on these.
Looper Plugin.
Monome support rewrite.
Improvements and bug-fixes for Binary and (especially) EndCoders.
Grid-based snapshot support for EndCoders.
Hopefully, though, the next thing I release is music instead of code ;)
a
edit:: Oh, I almost forgot. Markus Naumann has produced some further tutorial videos for you to watch, hosted on his YouTube site here:
http://www.youtube.com/user/morphicfield
Thanks Markus!
4.11.11
Sole Bugs
I spent last night setting up my live rig with the new b992 stuff, and getting ready to make some tutorials/exhibitions. I found some serious bugs with the new MIDI additions right off, so spent the rest of the evening fixing (I think) those issues. I'm packaging them now, and they'll be included in the b992 content if you download it again.
I'm still figuring out the best way to manage all these changes. I had been deleting the older versions in the packages and including new ones, but I've decided to change how I'm doing things. Until the official b992 release happens (the 'sole bugs' remix, because at that point they will all be on the bottom of my shoe), I'm merely going to add new versions to the package with their corresponding revision number. Make sure to check out each package and see what has changed.
Latest changes:
Fixed Nome support for multichannel plugs (Plinko, Monotes, Binary).
Fixed MIDI through behavior for Monotes (input should have been transmitted to assigned output channel when 'Thru' was turned on).
Fixed external timing receive for all plugins (it was only working for channel 1).
Added 16 Channel NomeOut plugin to package.
Restored Swing8 to package (but still need to create offset controls, since there are 16 channels now).
Fixed MIDI preferences so the lh_midi port is recalled correctly between saves/sessions.
Added line to LaunchMod script so that when in ModMode, 'Magic Rectangle' is removed.
New versions are up; download and reinstall as usual.
Check back later today, there should be some videos up for the new b992 patches.
a
edit :: I didn't come up with any videos I liked today....I did try, though. Soon....I'm still finding bugs and learning the new devices. And I'm terribly out of practice at this stuff.
I did commit another edit, b992r7, for some of the devices tonight. I think this one finally has solved all the MIDI/Nome bugs that have been plaguing me (mainly just reinit states for the last 24 hours...that one appears to be solved now).
I'm still figuring out the best way to manage all these changes. I had been deleting the older versions in the packages and including new ones, but I've decided to change how I'm doing things. Until the official b992 release happens (the 'sole bugs' remix, because at that point they will all be on the bottom of my shoe), I'm merely going to add new versions to the package with their corresponding revision number. Make sure to check out each package and see what has changed.
Latest changes:
Fixed Nome support for multichannel plugs (Plinko, Monotes, Binary).
Fixed MIDI through behavior for Monotes (input should have been transmitted to assigned output channel when 'Thru' was turned on).
Fixed external timing receive for all plugins (it was only working for channel 1).
Added 16 Channel NomeOut plugin to package.
Restored Swing8 to package (but still need to create offset controls, since there are 16 channels now).
Fixed MIDI preferences so the lh_midi port is recalled correctly between saves/sessions.
Added line to LaunchMod script so that when in ModMode, 'Magic Rectangle' is removed.
New versions are up; download and reinstall as usual.
Check back later today, there should be some videos up for the new b992 patches.
a
edit :: I didn't come up with any videos I liked today....I did try, though. Soon....I'm still finding bugs and learning the new devices. And I'm terribly out of practice at this stuff.
I did commit another edit, b992r7, for some of the devices tonight. I think this one finally has solved all the MIDI/Nome bugs that have been plaguing me (mainly just reinit states for the last 24 hours...that one appears to be solved now).
31.10.11
8 is not enough
I was finding it difficult to only use 8 Mod patches at a time, so I changed all the scripts to support 16. You can choose the second sixteen by pressing the (x=0, y=3) button on the grid when you press shift. Patches 9-16 are shown in inverse. Same goes for channels 9-16....the shift button for them is on the right side (x=7, y=3).
Mostly untested....it worked on the AumPad script. If things don't work as planned, I'll update as soon as possible. Let me know what you find.
As usual, just re-download, reinstall.
a
edit:: forgot to change the .py files to the current ones. I shouldn't release software when I'm delirious from sickness. Anyway, fixed....all the correct files should be in there (now just need to see if they all work or not).
edit2:: forgot to change name of new AumPC20 and AumPC40 scripts in installer, so I'm sure it didn't work. Updated, should work now.
edit3::changed some BlockMod stuff to make it work correctly without Monomodular installed.
Mostly untested....it worked on the AumPad script. If things don't work as planned, I'll update as soon as possible. Let me know what you find.
As usual, just re-download, reinstall.
a
edit:: forgot to change the .py files to the current ones. I shouldn't release software when I'm delirious from sickness. Anyway, fixed....all the correct files should be in there (now just need to see if they all work or not).
edit2:: forgot to change name of new AumPC20 and AumPC40 scripts in installer, so I'm sure it didn't work. Updated, should work now.
edit3::changed some BlockMod stuff to make it work correctly without Monomodular installed.
29.10.11
A little update
I've updated the new release with some bug-fixes and color maps.
Plinko was using the wrong version of Monomods, and now has a color map for monochrome.
TR256 got color maps.
Binary got color maps.
The BlockMod script had a bunch of bugs that I noticed when I started documenting it....it should work correctly now.
Just redownload and reinstall (OSX) or replace the relevant files in your setup (Windows).
a
Plinko was using the wrong version of Monomods, and now has a color map for monochrome.
TR256 got color maps.
Binary got color maps.
The BlockMod script had a bunch of bugs that I noticed when I started documenting it....it should work correctly now.
Just redownload and reinstall (OSX) or replace the relevant files in your setup (Windows).
a
28.10.11
Just a few more colors.
I've compiled everything for b992 into a working installer for OSX. I've tested it on a couple of computers besides my dev machine, but honestly, there is so much new content, I just don't have time to test everything all at once. Besides, I have a nasty cold, and a weekend full of shows coming up.
So instead of the painstaking testing I'd planned to do before releasing this version, I'm going to release it now and you can do the testing yourself. As I find issues (and I know there probably will be plenty), I'll fix them and post them here. As I find time to document things, I'll add it to the current content. As I find time to FINISH all the stuff I wanted to get done in this version, I'll update it to the current content.
If you are on OSX, I've created a simple OSA installer that will put the files where they go, but you have to point it to the right places. As I make changes and post them, you can easily just reuse the installer to overwrite the last subversion. The installer will overwrite any previous files and folders with the default names that they were installed as. Keep in mind, if you make custom Mod presets you'll want to put them somewhere else, as this process will overwrite them the next time you update your Monomodular install.
Refer to the readme file per changes....I'm afraid its quite incomplete at the moment, but rest assured I'm working on all this stuff daily.
Stuff that didn't get finished:
Mainly, I haven't had a chance to sit down with every controller and write a color map for it. Color map support is included now, which basically means that each patch can have its own custom color map for every controller it supports. As an example: TR256 play position indicator. On a monochrome, it should be 'off'. On a RGB, it could be any color that is different from the length indicator. Etc. The color map attributes allows the patcher to set a different color map for each controller type, even within the same patch. I've been trying to figure out a convenient way to do this for a while, and finally discovered the 'save()' function inside js. Duh. Anyway, the attribute is now supported, but I have 4 color maps for every single patch that need to be written and tested now, and quite frankly, it takes a lot of time. I'll be working on them as I have time, and publishing updating them to the release as I get them done.
Documentation. Yeah, I know. I suck at documentation. If its any consolation, I'll be spending the majority of the b993 cycle writing documentation instead of patching. In the meantime, I'll film some videos as soon as time permits (earliest, by the beginning of next week) explaining how the new scripts work. Of course I'd love some help, but since there is no documentation to refer to (doh!) I don't expect any.
The APC20 and 40 scripts are largely the same as the stock ones. There are some notes about their operation in the readme.
The new BlockMod script works largely the same as the MonOhm script, with a few exceptions due to space.
The Codec script will get some updates as I actually have a chance to use it and find out what works and what doesn't as far as ergonomics and needs.
As always, thanks for the support and kind words, and I sincerely hope some of you enjoy the new Mods I've created in this version.
Happy Blinking :)
a
for OSX installer, download:
http://dl.dropbox.com/u/6044993/Monomodular%20b992.zip
for raw files, download:
http://dl.dropbox.com/u/6044993/b992%20release.zip
So instead of the painstaking testing I'd planned to do before releasing this version, I'm going to release it now and you can do the testing yourself. As I find issues (and I know there probably will be plenty), I'll fix them and post them here. As I find time to document things, I'll add it to the current content. As I find time to FINISH all the stuff I wanted to get done in this version, I'll update it to the current content.
If you are on OSX, I've created a simple OSA installer that will put the files where they go, but you have to point it to the right places. As I make changes and post them, you can easily just reuse the installer to overwrite the last subversion. The installer will overwrite any previous files and folders with the default names that they were installed as. Keep in mind, if you make custom Mod presets you'll want to put them somewhere else, as this process will overwrite them the next time you update your Monomodular install.
Refer to the readme file per changes....I'm afraid its quite incomplete at the moment, but rest assured I'm working on all this stuff daily.
Stuff that didn't get finished:
Mainly, I haven't had a chance to sit down with every controller and write a color map for it. Color map support is included now, which basically means that each patch can have its own custom color map for every controller it supports. As an example: TR256 play position indicator. On a monochrome, it should be 'off'. On a RGB, it could be any color that is different from the length indicator. Etc. The color map attributes allows the patcher to set a different color map for each controller type, even within the same patch. I've been trying to figure out a convenient way to do this for a while, and finally discovered the 'save()' function inside js. Duh. Anyway, the attribute is now supported, but I have 4 color maps for every single patch that need to be written and tested now, and quite frankly, it takes a lot of time. I'll be working on them as I have time, and publishing updating them to the release as I get them done.
Documentation. Yeah, I know. I suck at documentation. If its any consolation, I'll be spending the majority of the b993 cycle writing documentation instead of patching. In the meantime, I'll film some videos as soon as time permits (earliest, by the beginning of next week) explaining how the new scripts work. Of course I'd love some help, but since there is no documentation to refer to (doh!) I don't expect any.
The APC20 and 40 scripts are largely the same as the stock ones. There are some notes about their operation in the readme.
The new BlockMod script works largely the same as the MonOhm script, with a few exceptions due to space.
The Codec script will get some updates as I actually have a chance to use it and find out what works and what doesn't as far as ergonomics and needs.
As always, thanks for the support and kind words, and I sincerely hope some of you enjoy the new Mods I've created in this version.
Happy Blinking :)
a
for OSX installer, download:
http://dl.dropbox.com/u/6044993/Monomodular%20b992.zip
for raw files, download:
http://dl.dropbox.com/u/6044993/b992%20release.zip
24.10.11
Imminent....
I spent all weekend working on scripts, and everything is pretty much done at this point. Things took a lot longer than planned, mostly because 'Binary' started out without any direction six months ago and has become much more than it was originally conceived to be. I had to rewrite a lot of it, and its still going to require some work after this release. Good news, everything else is getting faster and better.
I'm tweaking the base Python scripts to make sure that everything works as well as possible, and adding color maps to all the current patches. I managed to break my brand new video camera yesterday, so tutorials may take a bit longer than expected. Also, I've not managed to do any documentation on new features/patches yet, and I don't expect to get all this stuff done before I release the files.
Probably looking at a few more days...maybe a bit more depending on my schedule. In any case, its imminent....
a
I'm tweaking the base Python scripts to make sure that everything works as well as possible, and adding color maps to all the current patches. I managed to break my brand new video camera yesterday, so tutorials may take a bit longer than expected. Also, I've not managed to do any documentation on new features/patches yet, and I don't expect to get all this stuff done before I release the files.
Probably looking at a few more days...maybe a bit more depending on my schedule. In any case, its imminent....
a
15.10.11
Akai Scripts
I finished the APC40 and APC20 b992 Monomodular scripts just now. All together it only took me about three hours to completely integrate both control surfaces with the new Monomod scripts. I think that's a record! The first releases will be very simple, as I completely started from scratch with the stock 8.22 scripts; its a no-frills setup.
As time permits, I will integrate the b992 scripts with Hanz's scripts, as well as my own edits that I had used before I moved over to the Ohm64.
In addition, I've added some lines to the AumPad script to make the agonizingly slow WIFI speeds work better, and hopefully I'll get back to it soon to add Codec support (the new Livid Code script). I wouldn't look for this until b993, though, as I really want to get a release out soon....I know its been a while, and everyone out there is using painfully old versions of this stuff (there are a lot of changes and additions in b992).
What's left to do? I have some buggers to fix in one of the new patches (Binary), I need to finish up non-codec support for EndCoders, the new timing engine still hasn't been completed, and I need to implement the new color maps for the entire suite of plugins (possible now that I've finished coding scripts for all the control surfaces I plan on supporting). I've got a little time off this week, so chances are good that I will in fact be able to release something by the end of next week. Wish me luck :)
a
As time permits, I will integrate the b992 scripts with Hanz's scripts, as well as my own edits that I had used before I moved over to the Ohm64.
In addition, I've added some lines to the AumPad script to make the agonizingly slow WIFI speeds work better, and hopefully I'll get back to it soon to add Codec support (the new Livid Code script). I wouldn't look for this until b993, though, as I really want to get a release out soon....I know its been a while, and everyone out there is using painfully old versions of this stuff (there are a lot of changes and additions in b992).
What's left to do? I have some buggers to fix in one of the new patches (Binary), I need to finish up non-codec support for EndCoders, the new timing engine still hasn't been completed, and I need to implement the new color maps for the entire suite of plugins (possible now that I've finished coding scripts for all the control surfaces I plan on supporting). I've got a little time off this week, so chances are good that I will in fact be able to release something by the end of next week. Wish me luck :)
a
13.10.11
Any Lion Users?
Looking for someone currently using Lion along with the MonOhm control surface (either an RGB or a Monochrome) that can confirm that things are working/not working with certain parts of the script. I have a user that has reported some strangeness, but I can't confirm it on 10.6 nor do I have the time currently to invest in installing Lion on one of my machines.
Any interested parties please apply ;)
a
Any interested parties please apply ;)
a
12.10.11
EndCoders
A little update....
Just finished a new patch last night, 'EndCoders', so named because it is likely the last parameter management patch you will ever need (well, not really...but I didn't want to just call it 'Knobs for Code', since it does quite a bit more than the original 'Knobs' patch did). Testing and tuning now, but the patch looks pretty clean and efficient at this point.
Now the only thing left to do before the next update is finish up the new timing engine, fix a few bugs with the Codec script, and finish coding support for the APC40/20. Looks like I might have this out by the end of next week, if things go well. Wish me luck :)
a
Just finished a new patch last night, 'EndCoders', so named because it is likely the last parameter management patch you will ever need (well, not really...but I didn't want to just call it 'Knobs for Code', since it does quite a bit more than the original 'Knobs' patch did). Testing and tuning now, but the patch looks pretty clean and efficient at this point.
Now the only thing left to do before the next update is finish up the new timing engine, fix a few bugs with the Codec script, and finish coding support for the APC40/20. Looks like I might have this out by the end of next week, if things go well. Wish me luck :)
a
3.10.11
b991b bug fix release
Hey guys,
I figured out what was going on with the crashing situations with b991. There was an old version of lh_midi on my system that was getting included in the frozen files. I was under the impression that externals were not included in frozen m4l patches, but apparently that is not the case. The link below will get you the fixed versions, and all you should have to do is replace the maxpatches in your Live library (the included version of lh_midi was the most current, so no need to replace it).
The old lh_midi plugin was causing monomodular to crash Live when other applications using virtual ports were open. Hopefully this fix works for everyone, and of course please let me know if you are still having problems.
In other news, I'm still plugging along with getting b992 out, but work restraints are taking their toll. I'm half way through finishing the second patch that will be released (a replacement for "Knobs"), and the first one just needs a few tweaks now. You can expect the following additions with the next update (I'm just stating it again here to reorient myself):
renewed APC40 support
APC20 support (haven't started on this one yet)
native Block support (finished)
Code support (nearly finished)
updated timing engine for all plugins
Binary Mod (nearly finished)
"Super Knobs" Mod (haven't decided what to call it yet)
Custom color/flash maps for different control surface scripts
Some other tweaks and bug fixes
I may release b992 without APC support if it seems like its taking too long, but I don't expect the APC stuff to take too much time since I've already done most of the work on the APC40 script in older versions.
In addition, I'm aware that MonoLink doesn't work with autoconfig at present, and its on the list of future changes, but I can't comment on how long it will take as I haven't looked into what changes are necessary yet. I imagine it will be pretty simple, and if possible I'll include it with b992, but then again the more changes that are included with b992, the longer it will take to release.
Thanks to Pete and Marc for helping me out with this current crashing situation, it was greatly appreciated. Of course this kind of thing is going to pop up when I don't really have much time to work on revisions ;)
a
link to new revisions:
http://dl.dropbox.com/u/6044993/b991b_release.zip
I figured out what was going on with the crashing situations with b991. There was an old version of lh_midi on my system that was getting included in the frozen files. I was under the impression that externals were not included in frozen m4l patches, but apparently that is not the case. The link below will get you the fixed versions, and all you should have to do is replace the maxpatches in your Live library (the included version of lh_midi was the most current, so no need to replace it).
The old lh_midi plugin was causing monomodular to crash Live when other applications using virtual ports were open. Hopefully this fix works for everyone, and of course please let me know if you are still having problems.
In other news, I'm still plugging along with getting b992 out, but work restraints are taking their toll. I'm half way through finishing the second patch that will be released (a replacement for "Knobs"), and the first one just needs a few tweaks now. You can expect the following additions with the next update (I'm just stating it again here to reorient myself):
renewed APC40 support
APC20 support (haven't started on this one yet)
native Block support (finished)
Code support (nearly finished)
updated timing engine for all plugins
Binary Mod (nearly finished)
"Super Knobs" Mod (haven't decided what to call it yet)
Custom color/flash maps for different control surface scripts
Some other tweaks and bug fixes
I may release b992 without APC support if it seems like its taking too long, but I don't expect the APC stuff to take too much time since I've already done most of the work on the APC40 script in older versions.
In addition, I'm aware that MonoLink doesn't work with autoconfig at present, and its on the list of future changes, but I can't comment on how long it will take as I haven't looked into what changes are necessary yet. I imagine it will be pretty simple, and if possible I'll include it with b992, but then again the more changes that are included with b992, the longer it will take to release.
Thanks to Pete and Marc for helping me out with this current crashing situation, it was greatly appreciated. Of course this kind of thing is going to pop up when I don't really have much time to work on revisions ;)
a
link to new revisions:
http://dl.dropbox.com/u/6044993/b991b_release.zip
1.10.11
BAD Automap!
So, I've had a couple of users notify me lately that Monomodular and Automap are incompatible. Well, that's news to me. But I investigated tonight, and indeed, they are no longer friends. I suspect this is due to the lhmidi external, but I'm not presently sure (in fact, I'm rather baffled!). So I'll be investigating this over the course of next week as I'm allowed the time. I'd love any further reports of crashing so I can inform the relevant parties and get it all sorted out.
Thanks to the guys that reported this!
a
Thanks to the guys that reported this!
a
21.9.11
seasonal
First off, it comes to my attention that I've not been clear about something regarding how to install Monomodular:
YOU MUST INSERT THE MONOMODULAR SCRIPT IN YOUR MIDI PREFERENCES.
Not just the script for your particular controller (MonOhm, AumPad, BlockPad, etc. ad naseum), but also the Monomodular script. I've ran across several users lately that were having trouble because of this (quite frankly, nothing will work without it).
The good news is that I've created an installer for OSX that, with a little guidance from you, will put all the relevant files exactly where they are supposed to go. Baby steps. I'll get there eventually. Windows users, unfortunately your still going to have to read the directions. Expect the b992 update to be packaged in this manner.
The next release is still a little ways off...I'm in the middle of building two plugins, writing a CS Script for the APC20, and modding the APC40 script. I've also had some freelance work to do, so coding time has been limited to that lately. Anyway, thanks to those of you that repeat my name a lot, you know who you are; apparently some people have been listening.
I'm off to EarthDance in Vallejo this weekend to run sound for a truly awesome Bass-centric Electronic event....I've worked with less than half of the performers playing there, so in addition to seeing some old acquaintances, I'll be getting a dose of new music; I'm really looking forward to it! As always, this is 'work' season for me, so free time and free stuff hit the backburner for a while....but fret not, I'm still working almost everyday, and the next release is going to have some really cool goodies in it for some of you.
Its funny: the idea of v.1.0 Monomodular gets closer on any day that I finish a release, and further away the very next when I think of new things that I want to add...someday soon, perhaps ;)
a
edit:: as an aside, its my intention to get a better svn repository working very soon. Not just with all of the frozen files (as it is currently, and is the reason I haven't and don't update it regularly), but instead the unfrozen patches with all their dependencies. This was the intention at the outset, but requires time and a better file structure than what I'm currently using. I know this would do at least one person some good (not including myself).
YOU MUST INSERT THE MONOMODULAR SCRIPT IN YOUR MIDI PREFERENCES.
Not just the script for your particular controller (MonOhm, AumPad, BlockPad, etc. ad naseum), but also the Monomodular script. I've ran across several users lately that were having trouble because of this (quite frankly, nothing will work without it).
The good news is that I've created an installer for OSX that, with a little guidance from you, will put all the relevant files exactly where they are supposed to go. Baby steps. I'll get there eventually. Windows users, unfortunately your still going to have to read the directions. Expect the b992 update to be packaged in this manner.
The next release is still a little ways off...I'm in the middle of building two plugins, writing a CS Script for the APC20, and modding the APC40 script. I've also had some freelance work to do, so coding time has been limited to that lately. Anyway, thanks to those of you that repeat my name a lot, you know who you are; apparently some people have been listening.
I'm off to EarthDance in Vallejo this weekend to run sound for a truly awesome Bass-centric Electronic event....I've worked with less than half of the performers playing there, so in addition to seeing some old acquaintances, I'll be getting a dose of new music; I'm really looking forward to it! As always, this is 'work' season for me, so free time and free stuff hit the backburner for a while....but fret not, I'm still working almost everyday, and the next release is going to have some really cool goodies in it for some of you.
Its funny: the idea of v.1.0 Monomodular gets closer on any day that I finish a release, and further away the very next when I think of new things that I want to add...someday soon, perhaps ;)
a
edit:: as an aside, its my intention to get a better svn repository working very soon. Not just with all of the frozen files (as it is currently, and is the reason I haven't and don't update it regularly), but instead the unfrozen patches with all their dependencies. This was the intention at the outset, but requires time and a better file structure than what I'm currently using. I know this would do at least one person some good (not including myself).
7.9.11
Send me music links:
Hey guys,
I'd love to hear some music made with Monomodular, and make it available to other users....I've added a little sidebar to the blog with links to material that has been made using Monomodular. Please chime in and add your creations to the mix! Just drop me a comment or a mail with the address to link to.
Meanwhile, I'm working on Block/Code scripts, a patch called 'Binary' which spans both the Code and any connected grid controller allowing variable speed sequence creation.
In addition, there will be a new timing module available to all Monomod plugins as an alternative to the standard module. It will allow the timing to be driven by MIDI input to the plugin. In this way, you can use whatever is connected to the input of the plugin as a timing source, paving the way for some crazy combinations/modularity between different plugins or even from MIDI clips in Live. Think: binary ==driving==> tr256 ==driving==> every other monomod plugin for some crazy capabilities in variable timing. Hard to explain, but as soon as I get my camera back, you'll see what I mean. This stuff is almost finished, as I wrote the core of 'Binary' a while ago.
Anyway, I'll be doing Atlantis fest outside OC in L.A. this weekend, second stage I think (running sound, not performing)....if you're out there, slide on by. I'll be getting back to coding in a week or so after I get back.
a
I'd love to hear some music made with Monomodular, and make it available to other users....I've added a little sidebar to the blog with links to material that has been made using Monomodular. Please chime in and add your creations to the mix! Just drop me a comment or a mail with the address to link to.
Meanwhile, I'm working on Block/Code scripts, a patch called 'Binary' which spans both the Code and any connected grid controller allowing variable speed sequence creation.
In addition, there will be a new timing module available to all Monomod plugins as an alternative to the standard module. It will allow the timing to be driven by MIDI input to the plugin. In this way, you can use whatever is connected to the input of the plugin as a timing source, paving the way for some crazy combinations/modularity between different plugins or even from MIDI clips in Live. Think: binary ==driving==> tr256 ==driving==> every other monomod plugin for some crazy capabilities in variable timing. Hard to explain, but as soon as I get my camera back, you'll see what I mean. This stuff is almost finished, as I wrote the core of 'Binary' a while ago.
Anyway, I'll be doing Atlantis fest outside OC in L.A. this weekend, second stage I think (running sound, not performing)....if you're out there, slide on by. I'll be getting back to coding in a week or so after I get back.
a
31.8.11
Squaring the Circle
I've just gotten back to my Code....I've had a terrific idea about how to utilize it and add something truly new and different to Monomodular. Think: variable speed everything, with custom groove mapping. Anyway, I'm working on it as I type, hopefully I'll have it out soon. Its funny, I've been putting off doing it for a couple of days, and went to bed thinking about it last night, and this morning I had written the entire thing in my sleep....now I just have to find the time to put it together and get it working.
I've gone and left my camera in San Francisco, so I can't film any new stuff. I was anticipating filming a bit of a live set when I got back (the one that I didn't end up playing @ GAFFTA), but it didn't work out. The 'secret' mulitlooper I've been building with Monomodular will just have to remain a secret a while longer. It's okay, I'm not sure if I'll be giving it away anyway....its pretty core to my own performance. But I'm anxious to show it off, as it demonstrates some cool things you can do with the Monomodular framework if you are so inclined.
In the meantime I've decided that I will start publishing some practice sessions as I get to know my new controller...I've had a few people ask to hear what I've been doing. So, if you're interested in some verbose and unedited wanking, look no further than here:
http://soundcloud.com/aumhaa
Cheers :)
a
I've gone and left my camera in San Francisco, so I can't film any new stuff. I was anticipating filming a bit of a live set when I got back (the one that I didn't end up playing @ GAFFTA), but it didn't work out. The 'secret' mulitlooper I've been building with Monomodular will just have to remain a secret a while longer. It's okay, I'm not sure if I'll be giving it away anyway....its pretty core to my own performance. But I'm anxious to show it off, as it demonstrates some cool things you can do with the Monomodular framework if you are so inclined.
In the meantime I've decided that I will start publishing some practice sessions as I get to know my new controller...I've had a few people ask to hear what I've been doing. So, if you're interested in some verbose and unedited wanking, look no further than here:
http://soundcloud.com/aumhaa
Cheers :)
a
29.8.11
Hacked....
A quick thanks to Christopher Willits and Cullen Miller for putting together the m4l Hack Night @ Gray Area Foundation for the Arts in San Francisco....it was a long way to drive, but I got to meet a bunch of cool people and learn some new things. It was nice to play through GAFFTA's 7 Channel Ambisonic sound installation.....even if I couldn't hear myself while I was doing it (!).
A few things could have worked a little better. I learned one REALLY important thing about my own setup: if you create a looping plugin that emulates tape-based looping, don't assume your plugin is broken when you catch a loop and you don't hear it playing back. Instead, make sure the tape's transport is running....
Meantime, I'll be 'checking out' for a bit: it's back into the swing of the show season for me; but I'll still be hacking away and patching in my spare time, I just won't have quite as much of it to spread around.
Working on getting current patches documented and posted to SVN, then I'll update the current distribution to b991r2. Might be a little bit before then, but I'll post when I get things finished. I've actually made quite a few changes to some of the patches since the last public release.
Cheers :)
a
A few things could have worked a little better. I learned one REALLY important thing about my own setup: if you create a looping plugin that emulates tape-based looping, don't assume your plugin is broken when you catch a loop and you don't hear it playing back. Instead, make sure the tape's transport is running....
Meantime, I'll be 'checking out' for a bit: it's back into the swing of the show season for me; but I'll still be hacking away and patching in my spare time, I just won't have quite as much of it to spread around.
Working on getting current patches documented and posted to SVN, then I'll update the current distribution to b991r2. Might be a little bit before then, but I'll post when I get things finished. I've actually made quite a few changes to some of the patches since the last public release.
Cheers :)
a
19.8.11
self.disconnect(self)
I've been unifying the MonomodComponent Python module so that the identical version can be used in every one of the controller scripts that I've made....this is for my own benefit, as it becomes excruciating modifying every one of the scripts individually, and the process is very prone to error. Besides, I think this has something to do with the definitions of both 'portable' and 'modular'.
So, I've found a bunch of things that weren't happening correctly in the disconnect, and I've mostly fixed them in the 'living' version of the scripts that I'm using on the dev machine. However, lots of things are happening in my life right now, so I won't be able to update anything for a while. One nice thing is that the newer scripts are backwards compatible....I'm currently using the b922 versions of the Python perfectly easily with the b991 release versions of the m4l patches, and can hopefully keep it this way for a while. As soon as I have a working, stable version of the new scripts, I'll add them to the b991 release and post something about it.
New features that I haven't mentioned (mostly bug fixes):
Controller no longer changes selected device when you change shift modes.
Controller now remembers assignment of last right_function_mode track, so that it basically just works as a 'memory' button now....if I assign the mixer in right mode 1 to track 5, it will go back to track 5 the next time I go to mode 1. Same for modes 2 and 3. Eventually, I will add the Master and Return channels to the left mixer, so that they can be navigated to as well.
Disconnect calls no longer throw errors (which would cause major problems anytime you uninstalled/reinstalled a script, or if you opened the m4l editor window).
Various other little things....
IN OTHER NEWS: getting ready for GAFFTA show next week, and really digging playing with all this stuff....but its hard to not stop every time I run into something I want to fix and do it right then. I'm having to resort to little pieces of paper lol. Anyway, I hope to at some point this weekend put together some video footage, so don't think I lied straight up last week when I said I would do it....its just (as always) taking a little longer than intended.
Cheers :)
a
So, I've found a bunch of things that weren't happening correctly in the disconnect, and I've mostly fixed them in the 'living' version of the scripts that I'm using on the dev machine. However, lots of things are happening in my life right now, so I won't be able to update anything for a while. One nice thing is that the newer scripts are backwards compatible....I'm currently using the b922 versions of the Python perfectly easily with the b991 release versions of the m4l patches, and can hopefully keep it this way for a while. As soon as I have a working, stable version of the new scripts, I'll add them to the b991 release and post something about it.
New features that I haven't mentioned (mostly bug fixes):
Controller no longer changes selected device when you change shift modes.
Controller now remembers assignment of last right_function_mode track, so that it basically just works as a 'memory' button now....if I assign the mixer in right mode 1 to track 5, it will go back to track 5 the next time I go to mode 1. Same for modes 2 and 3. Eventually, I will add the Master and Return channels to the left mixer, so that they can be navigated to as well.
Disconnect calls no longer throw errors (which would cause major problems anytime you uninstalled/reinstalled a script, or if you opened the m4l editor window).
Various other little things....
IN OTHER NEWS: getting ready for GAFFTA show next week, and really digging playing with all this stuff....but its hard to not stop every time I run into something I want to fix and do it right then. I'm having to resort to little pieces of paper lol. Anyway, I hope to at some point this weekend put together some video footage, so don't think I lied straight up last week when I said I would do it....its just (as always) taking a little longer than intended.
Cheers :)
a
14.8.11
Monomodular Video Tutorials
I've made some rudimentary videos describing some of the basic functionality of Monomodular using the new OhmRGB and the MonOhm script....I split them up into 4 different vids, its probably best to watch them in order. I'll be adding some additional information that I left out with annotations later, now that they are up on YouTube. Sorry it took me so long, I actually did these last week but my internet connection is so slow at home that I had to wait until I was at work before I could manage to upload them all.
Now that I've been playing with the release for a week, I've found a bunch of things that I can't live with...better to deal with them now than have to hunt them down after I start working on individual patches and new Control Surface Scripts. I've been adding functionality to the Monomodular Python script so that everything is perfectly portable between the different controls scripts. So far, I've added the following:
Color Map support: this means that each m4l client will have its own color maps, one for each supported control surface. These will be maintained by the client patch itself, and could be easily made to support pattrs and user assignment.
Additional grid commands: I've added receive_grid_column, receive_grid_row, and receive_grid_all commands to the Monomodular script. This should ease some bandwitch requirements a little bit.
Persistent Grid Offset per client/per host: now when you navigate a client to a location on the grid, leave that client, and come back, the offset will be the same. This is on a per-controller basis, so it is still possible to have two Monomodular controllers connected to the same client with different offsets.
Select Current Client as Device: now holding down Alt + Key 8 will bring up the current client in the device editor. I'll be adding some other Alt + Key combinations in the near future when I figure out what works best ergonomically.
Set Nomeout Channel from client: this basically just allows the client to set the current the Nomeout channel from init, so that it matches the last selected channel before the client was saved....this is a display bug fix.
Also, I've spent some time (and will spend more) making the monomods.js script link/delink perfectly from the Python stuff between preview/load/save states. Getting there, but still a little work to do before its perfectly friendly.
Hopefully I get to publish this stuff in the coming days, and update it to the SVN. In the meantime, enjoy the videos, and I'll try to make some more pretty soon :)
a
Now that I've been playing with the release for a week, I've found a bunch of things that I can't live with...better to deal with them now than have to hunt them down after I start working on individual patches and new Control Surface Scripts. I've been adding functionality to the Monomodular Python script so that everything is perfectly portable between the different controls scripts. So far, I've added the following:
Color Map support: this means that each m4l client will have its own color maps, one for each supported control surface. These will be maintained by the client patch itself, and could be easily made to support pattrs and user assignment.
Additional grid commands: I've added receive_grid_column, receive_grid_row, and receive_grid_all commands to the Monomodular script. This should ease some bandwitch requirements a little bit.
Persistent Grid Offset per client/per host: now when you navigate a client to a location on the grid, leave that client, and come back, the offset will be the same. This is on a per-controller basis, so it is still possible to have two Monomodular controllers connected to the same client with different offsets.
Select Current Client as Device: now holding down Alt + Key 8 will bring up the current client in the device editor. I'll be adding some other Alt + Key combinations in the near future when I figure out what works best ergonomically.
Set Nomeout Channel from client: this basically just allows the client to set the current the Nomeout channel from init, so that it matches the last selected channel before the client was saved....this is a display bug fix.
Also, I've spent some time (and will spend more) making the monomods.js script link/delink perfectly from the Python stuff between preview/load/save states. Getting there, but still a little work to do before its perfectly friendly.
Hopefully I get to publish this stuff in the coming days, and update it to the SVN. In the meantime, enjoy the videos, and I'll try to make some more pretty soon :)
a
12.8.11
BlockPad Monomodular script for Livid's Block!
So, this might be some kind of personal victory for me....and that's kind of depressing hehe. I received Livid's Block controller in the mail today, and I'm honestly impressed with the ergonomics of the controller. It's compact and yet well organized, with enough controls to get by with under most circumstances.
Of course, before I can really see what its all about, I had to integrate it into Monomodular. Since the Launchpad is its closest cousin (besides a monome, which I don't possess), I thought it would be easy to adapt the LaunchMod script I've just finished writing to use with the Block as well.
Several hours later (most of which was spent learning the control protocol for the Block, and trying to figure out why two of the LED's weren't lighting on my Block), I've got a working script that does everything that the Launchpad does.
Its included with the current distribution of the Monomodular suite, which can be downloaded from the sidebar on the right.
(edit 081211:: there was a problem in the __init__ of the original upload...I've corrected it and recompiled the package, so if you downloaded it earlier, you might try it again since the first version didn't work)
Unfortunately, I don't really like the ergonomics of this script all that much, so I probably won't develop it very far....there's just not much use for "Button Slider Elements" on a controller that already has knobs....but still, I will incorporate the knobs at a later time so that the script is more useful.
In the meantime, here's the rundown:
The top two Function buttons switch between Session and Mixer modes.
The other four Function buttons are for Navigation.
Gary is a shift button, he does the following when held down:
You can switch to User1 or User2 by pressing shift and either Session or Mixer.
When in Mixer mode, holding shift turns the the Nav buttons into Mode Buttons (to change views between Volume/Pan/Send1/Send2)
When in Session mode, holding shift turns the far Right column of the grid into Session Launch buttons.
To get to Monomodular Mode, quickly press shift twice.
In ModMode (trademark ;) ), top function buttons are Lock and Alt, bottom Nav buttons are the same.
I haven't incorporated the Faders/Knobs yet, and haven't quite decided how to. The Launchpad script is less open than I had hoped in terms of how I can play with it easily, and I just don't want to spend too much time on this. I'd much rather adapt the MonOhm script to work with the Block, as its more generally usefull I think in the presence of faders/knobs. So I'll spend some time on that next, and you guys can play with this one in the mean time.
As a side note, I'm very joyous at how easy it has been to incorporate the new version of Monomodular into different controllers (this one took less than three hours!), and how well everything is working (for me anyway) when I'm done. I think I might be getting better at this, finally....
Please send feedback my way...this is totally untested in the real world, but I can't imagine its going to do anything terribly strange. I'll spend some more time on it when I get further feedback, and try to come up with an intelligent way to add the faders/knobs in the meantime. Keep in mind, User1 and User2 are available, this remaps the grid to different channels so you can use them for whatever you want. Check the Launchpad docs if you're wondering how things work, as things are largely the same since I started from the same script.
If you've changed the defaults for your Block, your going to have to reset to factory settings in order to get this to work. There's no "Map.py" file like the MonOhm script (yet).
Back to tutorial making.....
Happy blinking!
a
Of course, before I can really see what its all about, I had to integrate it into Monomodular. Since the Launchpad is its closest cousin (besides a monome, which I don't possess), I thought it would be easy to adapt the LaunchMod script I've just finished writing to use with the Block as well.
Several hours later (most of which was spent learning the control protocol for the Block, and trying to figure out why two of the LED's weren't lighting on my Block), I've got a working script that does everything that the Launchpad does.
Its included with the current distribution of the Monomodular suite, which can be downloaded from the sidebar on the right.
(edit 081211:: there was a problem in the __init__ of the original upload...I've corrected it and recompiled the package, so if you downloaded it earlier, you might try it again since the first version didn't work)
Unfortunately, I don't really like the ergonomics of this script all that much, so I probably won't develop it very far....there's just not much use for "Button Slider Elements" on a controller that already has knobs....but still, I will incorporate the knobs at a later time so that the script is more useful.
In the meantime, here's the rundown:
The top two Function buttons switch between Session and Mixer modes.
The other four Function buttons are for Navigation.
Gary is a shift button, he does the following when held down:
You can switch to User1 or User2 by pressing shift and either Session or Mixer.
When in Mixer mode, holding shift turns the the Nav buttons into Mode Buttons (to change views between Volume/Pan/Send1/Send2)
When in Session mode, holding shift turns the far Right column of the grid into Session Launch buttons.
To get to Monomodular Mode, quickly press shift twice.
In ModMode (trademark ;) ), top function buttons are Lock and Alt, bottom Nav buttons are the same.
I haven't incorporated the Faders/Knobs yet, and haven't quite decided how to. The Launchpad script is less open than I had hoped in terms of how I can play with it easily, and I just don't want to spend too much time on this. I'd much rather adapt the MonOhm script to work with the Block, as its more generally usefull I think in the presence of faders/knobs. So I'll spend some time on that next, and you guys can play with this one in the mean time.
As a side note, I'm very joyous at how easy it has been to incorporate the new version of Monomodular into different controllers (this one took less than three hours!), and how well everything is working (for me anyway) when I'm done. I think I might be getting better at this, finally....
Please send feedback my way...this is totally untested in the real world, but I can't imagine its going to do anything terribly strange. I'll spend some more time on it when I get further feedback, and try to come up with an intelligent way to add the faders/knobs in the meantime. Keep in mind, User1 and User2 are available, this remaps the grid to different channels so you can use them for whatever you want. Check the Launchpad docs if you're wondering how things work, as things are largely the same since I started from the same script.
If you've changed the defaults for your Block, your going to have to reset to factory settings in order to get this to work. There's no "Map.py" file like the MonOhm script (yet).
Back to tutorial making.....
Happy blinking!
a
11.8.11
Block is here!
Just got a Livid Block in the mail....I didn't think I was going to be excited about this, but apparently I am! This thing is pretty sexy....
So first order of business is to get this thing working with the standard Launchpad script that I just wrote, and then I'll go from there....
Spent all day yesterday playing with the Mod suite, and adding more content to my MonoLoop/LoopMaster plugins....way fun! I've come up with a lot of revisions/bug fixes for the plugins I've been using, so its time to start on the 992 update.
In addition, I recorded a quick tutorial for TR256, Boiingg, PressCafe, and Polygome last night. I'm editing them now and will add them to my YouTube channel when I get finished uploading them.
Cheers :)
a
So first order of business is to get this thing working with the standard Launchpad script that I just wrote, and then I'll go from there....
Spent all day yesterday playing with the Mod suite, and adding more content to my MonoLoop/LoopMaster plugins....way fun! I've come up with a lot of revisions/bug fixes for the plugins I've been using, so its time to start on the 992 update.
In addition, I recorded a quick tutorial for TR256, Boiingg, PressCafe, and Polygome last night. I'm editing them now and will add them to my YouTube channel when I get finished uploading them.
Cheers :)
a
9.8.11
grrr....b991 already
Here ya go:
http://dl.dropbox.com/u/6044993/b991_release.zip
I really hadn't intended on updating this stuff quite so soon, but I found a bug tonight that prevents the patches from loading from a saved Live set....something I added at the last minute and should have checked out further.
IMPORTANT: replace boiingg_b99.class in the Max/Cycling '74/java/classes folder with the new one (b99b). In fact, I left 'classes' off the destination address, so, in fact, if you followed the directions you put both the .class files in the wrong folder: make sure plinko_b99b is in the right place.
If you downloaded the first package, you should download this one now. If you have saved any patches with the old plugins and have preset info stored in the project, you can just drop the new plugin (version b991) on top of the old one and resave the project....all the pattr information will transfer to the new plugin. Besides the actual m4l client plugins, everything is identical.
In addition, I've fixed the preset storage in Plinko and Boinngg so that presets can be stored and accessed from the grid. Just hold down Alt (top right function button on Ohm, User2 button on Launchpad) and the grid is split in two while its held down: the top 32 cells will be blank, and will indicate locations after they are stored, while the bottom 32 are flashing, and represent empty locations that can be stored. If you press a bottom cell it will store a preset location in the corresponding top cell. If you press a lit cell on the top (if its turned on because you've stored a location there) it will recall that location. I had to do it this way because I was out of buttons and didn't want to rewrite a bunch of new stuff right now....besides, there are enough silly button combinations as it is. Let me know if that makes sense to anyone?
Boinngg will recall the same grid space as it existed right when you store the preset. I'll have to work on the timing later.
Expect similar preset systems for all the other plugins as I have a chance to integrate this new method. The object I'm using will become a reuasable abstract as I get the bugs worked out and decide what works best (for instance, there's still no way to copy and paste or erase already stored presets....but you can always just overwrite a preset, and for copying, just recall a preset into the grid and store it in another location).
Still no tutorials, my evening was spent fixing bugs instead....hopefully things go better tomorrow. I did get to play some music with the new stuff tonight, though, so that's encouraging :) Everything went swimmingly after I figured sorted out the bug.
I'm still running into weirdness when switching between edit mode or saving m4l patches as presets (which is what the introduction of the b99 bug was all about....I made a change that was supposed to fix that problem, but instead it caused another). I'm working on it...I don't think anyone is using this stuff for further coding anyway, but if someone runs into issues, let me know.
I'll be migrating to 10.6 later this week, so I should have a better testing platform for those of you that are on MacOS. Wish me luck...that's 3 computers to upgrade and without anything breaking....blehhh.
It honestly wouldn't be so irritating if I didn't have to open up every single patch, resave it, refreeze it, resave it.....whatever. Labor of love ;)
a
http://dl.dropbox.com/u/6044993/b991_release.zip
I really hadn't intended on updating this stuff quite so soon, but I found a bug tonight that prevents the patches from loading from a saved Live set....something I added at the last minute and should have checked out further.
IMPORTANT: replace boiingg_b99.class in the Max/Cycling '74/java/classes folder with the new one (b99b). In fact, I left 'classes' off the destination address, so, in fact, if you followed the directions you put both the .class files in the wrong folder: make sure plinko_b99b is in the right place.
If you downloaded the first package, you should download this one now. If you have saved any patches with the old plugins and have preset info stored in the project, you can just drop the new plugin (version b991) on top of the old one and resave the project....all the pattr information will transfer to the new plugin. Besides the actual m4l client plugins, everything is identical.
In addition, I've fixed the preset storage in Plinko and Boinngg so that presets can be stored and accessed from the grid. Just hold down Alt (top right function button on Ohm, User2 button on Launchpad) and the grid is split in two while its held down: the top 32 cells will be blank, and will indicate locations after they are stored, while the bottom 32 are flashing, and represent empty locations that can be stored. If you press a bottom cell it will store a preset location in the corresponding top cell. If you press a lit cell on the top (if its turned on because you've stored a location there) it will recall that location. I had to do it this way because I was out of buttons and didn't want to rewrite a bunch of new stuff right now....besides, there are enough silly button combinations as it is. Let me know if that makes sense to anyone?
Boinngg will recall the same grid space as it existed right when you store the preset. I'll have to work on the timing later.
Expect similar preset systems for all the other plugins as I have a chance to integrate this new method. The object I'm using will become a reuasable abstract as I get the bugs worked out and decide what works best (for instance, there's still no way to copy and paste or erase already stored presets....but you can always just overwrite a preset, and for copying, just recall a preset into the grid and store it in another location).
Still no tutorials, my evening was spent fixing bugs instead....hopefully things go better tomorrow. I did get to play some music with the new stuff tonight, though, so that's encouraging :) Everything went swimmingly after I figured sorted out the bug.
I'm still running into weirdness when switching between edit mode or saving m4l patches as presets (which is what the introduction of the b99 bug was all about....I made a change that was supposed to fix that problem, but instead it caused another). I'm working on it...I don't think anyone is using this stuff for further coding anyway, but if someone runs into issues, let me know.
I'll be migrating to 10.6 later this week, so I should have a better testing platform for those of you that are on MacOS. Wish me luck...that's 3 computers to upgrade and without anything breaking....blehhh.
It honestly wouldn't be so irritating if I didn't have to open up every single patch, resave it, refreeze it, resave it.....whatever. Labor of love ;)
a
8.8.11
Windows b99
Updated the package to contain the relevant files for Windows installation, and have received reports that everything is working on that platform.
Apparently, I had some misunderstandings about the color scheme for the production version of the OhmRGB, so that script will have to be updated shortly when I get it sorted out....no big deal, since I don't think anyone actually has one yet ;)
a
Apparently, I had some misunderstandings about the color scheme for the production version of the OhmRGB, so that script will have to be updated shortly when I get it sorted out....no big deal, since I don't think anyone actually has one yet ;)
a
Somebody drop a beat....
Alright, then. I have to get this out....I have a feeling I'll find lots of stuff wrong with it, but I have to get it out....
The files:
http://dl.dropbox.com/u/6044993/b99_release.zip
The problem with having so many files floating around is that by the time I get done checking the last ones, the first ones are deprecated hehe. I need a team...a team of elves...a team of elves that write code. And make cookies (mmmmm cookies.....)
Moral: PLEASE let me know what happens when you try this stuff out. I don't have an installation of 10.6 or 10.7 so I have no idea what it will do with those OSes. Working on 10.6, its bound to be a good thing to have. In the meantime, you are my cybernetic eyes and ears.
You will need versions 8.22 of Live, 5.18 of Max, and update your Java installs just for good measure.
I've chased down every single bug I could find with the MonOhm script, but I suspect there might be a few little ones left.
The plugins are largely untouched...except for Plinko, which is much more stable, faster, capable of recalling up to 32 presets, and still completely undocumented (don't worry, that bit is just over the horizon....).
OSX only for the time being. When I can find someone with Windows who will test for me, I'll put together a package for that OS as well.
And NOW....for the tutorials. I've already posted one for the Ohm64 script (yesterday?), and I'll be working on some new ones for each individual plugin later this week. Furthermore, I've come up with an idea:
I'll be presenting at GAFFTA in San Francisco on the 25th of August (Ableton Hack Night), and I don't have any material that I want to use. So for the next two weeks, I'm going to video document my progress in creating a short Live PA set for the performance that evening. I'll start roughly from scratch with an empty template project and gradually add plugins that I'm going to use for either preproduction or during the actual performance itself. I'll give an explanation of what each plugin does, how to use it, tricks you can do with it, and probably some performance. I think this is the only way I'm going to be able to force myself to get these tutorials over with, as the other way is just boring me (and you, I'm sure) to tears. In addition, you'll get to see some of the plugins that are 'as yet unreleased' in action, and maybe you can give me some pointers about how I can suck less ;)
Incidentally, there's a whole lot more stuff that goes with this, but can't be released right now. Expect a Livid Code script (I have a working one, but I need to polish it up a bit....and finish two patches that go with it, or its fairly worthless), a Livid Block script (I'm waiting on the Block to arrive in the mail...it shouldn't take long after I get it), and an APC40 script (again...shouldn't take longer than a day, although I don't think I've gotten one response from ANYONE using the old one, so that one may sit on the shelf for a while).....Oh, and an iPod script for TouchOSC, just because a good friend of mine really should have one. But I'll rant about that stuff another on another evening.
Oh, and if someone would send me a monome, I'd gladly incorporate it as well....
Btw, if any of this stuff catches your house on fire or something, I am NOT responsible.
a
The files:
http://dl.dropbox.com/u/6044993/b99_release.zip
The problem with having so many files floating around is that by the time I get done checking the last ones, the first ones are deprecated hehe. I need a team...a team of elves...a team of elves that write code. And make cookies (mmmmm cookies.....)
Moral: PLEASE let me know what happens when you try this stuff out. I don't have an installation of 10.6 or 10.7 so I have no idea what it will do with those OSes. Working on 10.6, its bound to be a good thing to have. In the meantime, you are my cybernetic eyes and ears.
You will need versions 8.22 of Live, 5.18 of Max, and update your Java installs just for good measure.
I've chased down every single bug I could find with the MonOhm script, but I suspect there might be a few little ones left.
The plugins are largely untouched...except for Plinko, which is much more stable, faster, capable of recalling up to 32 presets, and still completely undocumented (don't worry, that bit is just over the horizon....).
OSX only for the time being. When I can find someone with Windows who will test for me, I'll put together a package for that OS as well.
And NOW....for the tutorials. I've already posted one for the Ohm64 script (yesterday?), and I'll be working on some new ones for each individual plugin later this week. Furthermore, I've come up with an idea:
I'll be presenting at GAFFTA in San Francisco on the 25th of August (Ableton Hack Night), and I don't have any material that I want to use. So for the next two weeks, I'm going to video document my progress in creating a short Live PA set for the performance that evening. I'll start roughly from scratch with an empty template project and gradually add plugins that I'm going to use for either preproduction or during the actual performance itself. I'll give an explanation of what each plugin does, how to use it, tricks you can do with it, and probably some performance. I think this is the only way I'm going to be able to force myself to get these tutorials over with, as the other way is just boring me (and you, I'm sure) to tears. In addition, you'll get to see some of the plugins that are 'as yet unreleased' in action, and maybe you can give me some pointers about how I can suck less ;)
Incidentally, there's a whole lot more stuff that goes with this, but can't be released right now. Expect a Livid Code script (I have a working one, but I need to polish it up a bit....and finish two patches that go with it, or its fairly worthless), a Livid Block script (I'm waiting on the Block to arrive in the mail...it shouldn't take long after I get it), and an APC40 script (again...shouldn't take longer than a day, although I don't think I've gotten one response from ANYONE using the old one, so that one may sit on the shelf for a while).....Oh, and an iPod script for TouchOSC, just because a good friend of mine really should have one. But I'll rant about that stuff another on another evening.
Oh, and if someone would send me a monome, I'd gladly incorporate it as well....
Btw, if any of this stuff catches your house on fire or something, I am NOT responsible.
a
5.8.11
LaunchMod for Launchpad, a new Block script, and any Virus users?
While I'm waiting for the fix from Livid for the RGB stuff, I decided to go ahead and start building the script for the LaunchPad. It seems that hard work has paid off...it took less than a couple of hours to get this thing going, and most of that time was spent with fixing Python errors due to the lack of decompyled 8.22 Launchpad scripts. This just demonstrates the portability of the scripts I've already written. I should be able to release the new Monomodular script for the Launchpad ('LaunchMod') at the same time as the rest of the b99 scripts.
One cool thing I've been able to do is to put the Monomodular mode in a completely seperate space. You'll be able to use the script exactly as it normally works, and by pressing User1 + User2 at the same time, enter Monomodular mode. I think this will offer some more possibilities, since the individual User1 and User2 modes remain intact, and you can use them for whatever you were using them before.
In addition, Jay @ Livid agreed to send over a Block for me to test with, so there will be a new script available for it as soon as I receive it. I'm going to port the Launchpad script directly over to it, and perhaps the Ohm64 script as well....so those of you with Blocks will have a bunch of new toys to play with!
One last thing....I've discovered a serious bug with mxj's and the Virus Control plugin...I've contacted the relevant authorities (hehe), but I'm wondering if any of you out there have a Virus and are willing to test out some files and see if they can reproduce my results?
a
One cool thing I've been able to do is to put the Monomodular mode in a completely seperate space. You'll be able to use the script exactly as it normally works, and by pressing User1 + User2 at the same time, enter Monomodular mode. I think this will offer some more possibilities, since the individual User1 and User2 modes remain intact, and you can use them for whatever you were using them before.
In addition, Jay @ Livid agreed to send over a Block for me to test with, so there will be a new script available for it as soon as I receive it. I'm going to port the Launchpad script directly over to it, and perhaps the Ohm64 script as well....so those of you with Blocks will have a bunch of new toys to play with!
One last thing....I've discovered a serious bug with mxj's and the Virus Control plugin...I've contacted the relevant authorities (hehe), but I'm wondering if any of you out there have a Virus and are willing to test out some files and see if they can reproduce my results?
a
4.8.11
(whistles while twiddling thumbs)
Some of my stuff got buggered with the new firmware on the RGB. Almost back up to speed, but we have to fix/figure a few things out before release....stay tuned.
a
a
3.8.11
One last thing.
The MonOhm script for the Ohm64 is finished. I worked out the last bug I could find this afternoon.
The AumPad script for TouchOSC is finished. I have one more test run to make with it.
I've started video tutorials for the MonOhm script.
The new version of Plinko is done. 4x faster, with grid-based preset storage that works.
One last thing to do before release: Livid just released a new firmware now that the RGB is public, and it should make things a little nicer. I need to update the firmware on my RGB and make a few code tweaks, and you will all have some new toys to play with :)
If you're bored in the meantime, check out the new docs page for the MonOhm script. Its available to the left of this post.
a
The AumPad script for TouchOSC is finished. I have one more test run to make with it.
I've started video tutorials for the MonOhm script.
The new version of Plinko is done. 4x faster, with grid-based preset storage that works.
One last thing to do before release: Livid just released a new firmware now that the RGB is public, and it should make things a little nicer. I need to update the firmware on my RGB and make a few code tweaks, and you will all have some new toys to play with :)
If you're bored in the meantime, check out the new docs page for the MonOhm script. Its available to the left of this post.
a
1.8.11
A few pics...
Here's a few pics of the new template. The top ones are in "Bright" mode, the bottom in dim. Dim mode is far easier on the eyes for me, and a lot faster (since the AumPad script only has to send about two thirds as much data each time it updates).
Monday is EVIL.....
I'm just not feeling this monday thing right now.
Instead of making videos last night, I completely redesigned the pattr system used in Plinko for the (seventeenth) time. It appears to work now. It appeared to work before, until I started using it, and then it didn't work. Go figure. Sometimes I hate Max.
That was merely 4 or 5 hours of scratching my head and cursing at inanimate objects....I really hope I don't have to do that again for a while.
It is a step towards having a universal grid-based memory recall system for all the monomodular patches. But its NOT a step forward in getting instructional materials released.
For those of you that are wondering: the iPad script is finished. There are a few details I've left out, so consider it beta (erm....consider everything I do beta. Its just the rule. Always. Unless otherwise notified. Its beta. Yup). I'll update those as I figure out the best way to do it (hint: I am refering to the two x/y pads on page two that do absolutely nothing right now, but eventually will have an interface equivalent to my 'knobs' plugin). It'll be published as soon as I figure out what to do about the Windows version, since I'm using Cassiel's Zeroconf ports on OSX and I'm not sure how they work (if they work) on Windows.
I played with it last night for a few hours after Plinko was up and running and OH BOY! Blinky :) Yay!
I squashed some bugs during the recent dev process, and since the iPad script and the Ohm64 script are nearly identical in function, I've located most of the bugs in the Ohm64 script as well. I still need to port the changes over to it, but a release is imminent (a day and hours, not weeks like before). I'm still on track to record some tutorials and make some docs tonight and tomorrow, but I've learned there's no sense in trying to explain how something works when it doesn't, in fact, 'WORK'.
a
Instead of making videos last night, I completely redesigned the pattr system used in Plinko for the (seventeenth) time. It appears to work now. It appeared to work before, until I started using it, and then it didn't work. Go figure. Sometimes I hate Max.
That was merely 4 or 5 hours of scratching my head and cursing at inanimate objects....I really hope I don't have to do that again for a while.
It is a step towards having a universal grid-based memory recall system for all the monomodular patches. But its NOT a step forward in getting instructional materials released.
For those of you that are wondering: the iPad script is finished. There are a few details I've left out, so consider it beta (erm....consider everything I do beta. Its just the rule. Always. Unless otherwise notified. Its beta. Yup). I'll update those as I figure out the best way to do it (hint: I am refering to the two x/y pads on page two that do absolutely nothing right now, but eventually will have an interface equivalent to my 'knobs' plugin). It'll be published as soon as I figure out what to do about the Windows version, since I'm using Cassiel's Zeroconf ports on OSX and I'm not sure how they work (if they work) on Windows.
I played with it last night for a few hours after Plinko was up and running and OH BOY! Blinky :) Yay!
I squashed some bugs during the recent dev process, and since the iPad script and the Ohm64 script are nearly identical in function, I've located most of the bugs in the Ohm64 script as well. I still need to port the changes over to it, but a release is imminent (a day and hours, not weeks like before). I'm still on track to record some tutorials and make some docs tonight and tomorrow, but I've learned there's no sense in trying to explain how something works when it doesn't, in fact, 'WORK'.
a
29.7.11
Anway
It was a nice idea, but the closure thing didn't work out after all. Still, it was good for learning some new things about Python and the Live _Framework, and I'll be able to use it later for other things. Instead of the original thought, I wrote some simple overrides and everything works great now. I'd still really love to figure out how to do this stuff with some closures and staticmethods, but I can't work out exactly how to do it....
The iPad script is done for the most part. Its very slow at this point, but that will improve now that the groundwork is in place and I can focus on the details. I have a huge laundry list of things to get done on all of the current stuff, but everything is functional.
Having wasted two days chasing a white rabbit, I'm going to spend some time tomorrow documenting and making some short videos about what I've been working on. I have a couple of days off of work, so hopefully this is the home stretch in getting something functional out into the wild in a usable, understandable form.
a
The iPad script is done for the most part. Its very slow at this point, but that will improve now that the groundwork is in place and I can focus on the details. I have a huge laundry list of things to get done on all of the current stuff, but everything is functional.
Having wasted two days chasing a white rabbit, I'm going to spend some time tomorrow documenting and making some short videos about what I've been working on. I have a couple of days off of work, so hopefully this is the home stretch in getting something functional out into the wild in a usable, understandable form.
a
27.7.11
Some closure(s)
Yeah, sorry, the title is misleading....what I MEAN is, I'd been having trouble figuring out a way to port the iPad Nameserver (for clip names) over to Python without writing overrides for every part of the _Framework session components. Soooo, that's what has been taking so long. I did a little bit of studying yesterday and discovered a way to hack the _Framework scripts by using a simple closure in the top Class, so hopefully I'll have the basic functionality of the iPad script finished this evening. Again, this is a lovely little technique will avail most of you in hacking the _Framework scripts without having to write an override for the base-level components/controls. I'll probably begin using in other places as well if I don't find any good reason not to (anyone know a good reason not to?).
I'd love to have some testers for this stuff, so if you have an iPad or an Ohm64 and the desire to manually install some components, the current versions are on svn. I'll have a new version of the AumPad script up as soon as I finish writing the new NameServer portion of the scripts.
There are a lot of piddly little details that need to be ammended, but I haven't ran into any major problems with any of it (I've had the current version running on my Live rig for about 5 days straight with no reboots and no crashes).
Plans (in order): finish and publish iPad script to svn, record some tutorial videos, publish a package with all the finished scripts, start working on a Block script.
I'd love to have some testers for this stuff, so if you have an iPad or an Ohm64 and the desire to manually install some components, the current versions are on svn. I'll have a new version of the AumPad script up as soon as I finish writing the new NameServer portion of the scripts.
There are a lot of piddly little details that need to be ammended, but I haven't ran into any major problems with any of it (I've had the current version running on my Live rig for about 5 days straight with no reboots and no crashes).
Plans (in order): finish and publish iPad script to svn, record some tutorial videos, publish a package with all the finished scripts, start working on a Block script.
23.7.11
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 :)
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 :)
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 :)
8.2.11
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.
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.
19.1.11
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 :)
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 :)
17.1.11
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
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
11.1.11
Its out.
Beta testers have it. Hopefully all goes well and I can have it out to the public in a week. Stay tuned....
10.1.11
...ahem....
At last.....
Yes, it took a while (read: too long), but the script is done. I'm currently working on documentation and videos. If you have m4l, then you're in luck: after connecting Monomodular to the Ohm64, you can press the HELP button, and a fully working representation of the Ohm64 will appear. You can click on an area of the control surface, and it will tell you what that region does in each mode. Also, this view will be updated any time that you move a control or change modes.
There are still a few oversights...I think a few of the User Mappings for the Rotaries may not work, but I want to get this out to everyone before NAMM....expect refinements before the final release.
For those of you that don't need two mixers, simply press the left and right shift buttons at the same time, and this will both sides of the mixer together (this is actually a third mixer with its own settings...the locations and modes of the other two mixers remains the same when you go back to them). The shift-modes for the linked mixer are the same as those for the left mixer. You change Shift-Modes by pressing shift (right or left) and pressing one of the channel select buttons on the same side as the pressed Shift. The Modes are as follows:
(Left Mixer's Fader's are always assigned to Track Level)
Left Shift Mode 1: Upper 8 Knobs = Device Control
Lower 4 Knobs = Send Level for Selected Track
Left Shift Mode 2: All Knobs = Send 1-3 for corresponding Fader
Left Shift Mode 3: Upper 4 Knobs = Cutoff for filter of corresponding Fader
Middle 4 Knobs = Q for Filter of corresponding Fader
Lower 4 Knobs = Pan for corresponding Fader
Left Shift Mode 4: All Knobs are User Assignable via Live's built-in MidiMapping functionality
(Except for Mode 1, the Right Mixer's grid is User Assignable either in part or completely)
Right Shift Mode 1: Knobs = Return Level (1-4), Faders = Right Mixer Volume
Right Shift Mode 2: Knobs = Return Pan (1-4), Faders = Return Level (1-4), Top 5 rows
of Grid are User Mappable (default assigned to Pad Translation),
Also, bottom row of the grid on the right zeros all Send Levels in project.
Right Shift Mode 3: Knobs = User Mappable, Faders = Return Level (1-4)
Right Shift Mode 4: Knobs & Faders User Mappable (this may be broken in current beta, I have to check it....)
Linked Shift Modes 1-4 are the same as for the Left Mixer. While linked, the right Knobs are always assigned to the Return Levels.
The top right buttons Unshifted do the following from left to right, top to bottom:
Play, Stop, Record
Loop, Stop All Clips, Overdub
When shift is pressed, the same buttons control the Device Controller:
Device Left, Device Right, Lock
Parameter Bank Left, Parameter Bank Right, On/Off
The Grid (generally) controls clip launching for the first 5 rows.
The sixth row unshifted is Mute.
The seventh row unshifted is Solo.
The eighth row unshifted is Arm.
The sixth row shifted becomes a device selector (see below).
The seventh row shifted becomes crossfade assign.
The eight row shifted is stop clip.
If Monomod is connected, pressing the Livid button will put the Ohm64 in Monomod mode. IF MONOMOD IS NOT CONNECTED, PRESSING THE LIVID BUTTON PUTS THE ENTIRE GRID INTO USER ASSIGNABLE MODE.
Device Selector: a quick way to select a device without actually changing tracks. This is mostly useful if you are using Monomod and its LCD screen. Rename your plugin with the prefix 'p1' through 'p8' (for each button in the device selector), and when you press shift and one of the device selector buttons, the plugin will automatically be loaded into the Device Controller. (You have to release shift before the change is reflected on the LCD....this will be changed on the next version, hopefully)
Master Volume and Cue Volume: Press the Right Shift, and while it is held, the far Right Fader becomes the Master Volume, and the far Right Knob becomes the Cue Volume.
Oh, and you may notice that now when you change modes, the backlighting of the Ohm64 changes to let you know. The method of lighting for each mode may be changed in the MonOhmodMap.py file, along with all the User identifier/channel settings for each button.
I think that's it....if I've missed something, please refer to the Help section of Monomod (if you have it). I'm working on some video tutorials at the moment, but I have a show tomorrow night and it will take me a bit longer than planned. In the meantime, I'm posting a short "wank session" video I did after getting frustrated with my fourth attempt to narrate a comprehensive tutorial video...no musical value, and very little tutorial value, but at least it gives you an idea of what is possible with the script, and some reasons to use Monomodular in conjunction with the Ohm64.
Some technical notes about changes and additions: I maintain that I did NOT spend a week making some silly-ass tutorial sketch merely to enlighten the public. In fact, I had some ulterior motives. The framework I built will become the basis for the next major revision of the _Framework Mods scripts, making it possible to easily add/remove capabilities to this generic schema of control setup. Take a look at the js bundled within Monomod, if you have inclination. There are a bunch of functions I've added that are of general use for anyone working with the _Framework scripts, and they basically function the same as their corresponding components in Python. If you use the 'element()' function to create an API object, it will be appended to an array that can be easily destructed upon dissolving the patch. It also allows the assignment of other attributes upon instantiation of the object. THIS GREATLY SIMPLIFIES THINGS, and should be incorporated into the js 'Live API' object itself, in my opinion. There is also a dictionary that defines a bunch of regions (this is what powers the INFO engine)...that's the bit that will eventually become the new framework for the Python stuff, and is borrowed (read: stolen) from the Device naming dictionary method's in the _Framework scripts.
Unless you've done some work with this sort of thing, you probably didn't blink an eye; but if you have done some work with this sort of thing, you should be saying, "Holy Hack, Batman! How the hell did he do that?!" I've been talking for a while about adding some overloads to deal with the crippled _Framework components that Ableton has given us with the stock m4l. Now it is possible to have the values sent to the connected controller forwarded to callbacks in m4l. It is also possible to send value's from m4l objects and be received in the same manner that they would be received if the controller was sending them. In short, I'm working towards the goal of being able to use the _Framework scripts to do all the heavy lifting, but still be able to tell them what to do from m4l (which is much more scriptable). I think I have succeeded in this, but only time and testing will tell.
The short of it: the tutorial sketch is the Framework for the new iPad interface. That means that soon you will have the ability to access all of this functionality (and MORE!) through TouchOSC. It also means that the script I have written should be adaptable to other control surfaces, either through coaxing in Python, or direct interaction in m4l.
Planned changes: Oh, lots ;)
In particular: before final release (or possibly in first revision, depending on how much time I have), I am going to add some components that tell m4l when the controller is actually present, as well as when the script destructs (so that it can clean up without any hassles).
If I can find a good way, I will add some stuff to automatically orient the crossfader correctly (I've been going round and round with this....nothing satisfies me so far). In the meantime, make sure that you reverse the stock orientation of the crossfader with Ohm64Control.
There is some tweaking to do still with the grid in Linked mode....I just noticed since I've been documenting things, and asking myself, "hmmmm....I wonder what that does in this mode...." Alas, we are all fallible, every one of us.
Channel Select is not working as I planned when in Monomod mode: this will be fixed.
I think there are some incorrect assignments for the grid in Right Mixer Modes 2-4. This will get fixed.
General documentation in the Python script will be added, and I'll clean it up a bit, when I know that everything is working optimum.
There will be User configuration mapping to change a few default behaviours:
1. Whether or not using the Device Selector also puts Live's focus to the Plugin being controlled.
2. Default boot state of the Mixer mode (Linked or Unlinked).
3. SUGGESTIONS ARE WELCOME, AND I WILL IMPLEMENT THEM IF ITS NOT TOO DIFFICULT.
I've probably left out tons of important details....
Cheers for now, enjoy, and let me know if anything isn't working as expected.
James
("The check is in the mail".....beta testers will see files this evening, in the meantime you can check out this video:)
http://www.youtube.com/watch?v=9ypoR7JH1cY
Yes, it took a while (read: too long), but the script is done. I'm currently working on documentation and videos. If you have m4l, then you're in luck: after connecting Monomodular to the Ohm64, you can press the HELP button, and a fully working representation of the Ohm64 will appear. You can click on an area of the control surface, and it will tell you what that region does in each mode. Also, this view will be updated any time that you move a control or change modes.
There are still a few oversights...I think a few of the User Mappings for the Rotaries may not work, but I want to get this out to everyone before NAMM....expect refinements before the final release.
For those of you that don't need two mixers, simply press the left and right shift buttons at the same time, and this will both sides of the mixer together (this is actually a third mixer with its own settings...the locations and modes of the other two mixers remains the same when you go back to them). The shift-modes for the linked mixer are the same as those for the left mixer. You change Shift-Modes by pressing shift (right or left) and pressing one of the channel select buttons on the same side as the pressed Shift. The Modes are as follows:
(Left Mixer's Fader's are always assigned to Track Level)
Left Shift Mode 1: Upper 8 Knobs = Device Control
Lower 4 Knobs = Send Level for Selected Track
Left Shift Mode 2: All Knobs = Send 1-3 for corresponding Fader
Left Shift Mode 3: Upper 4 Knobs = Cutoff for filter of corresponding Fader
Middle 4 Knobs = Q for Filter of corresponding Fader
Lower 4 Knobs = Pan for corresponding Fader
Left Shift Mode 4: All Knobs are User Assignable via Live's built-in MidiMapping functionality
(Except for Mode 1, the Right Mixer's grid is User Assignable either in part or completely)
Right Shift Mode 1: Knobs = Return Level (1-4), Faders = Right Mixer Volume
Right Shift Mode 2: Knobs = Return Pan (1-4), Faders = Return Level (1-4), Top 5 rows
of Grid are User Mappable (default assigned to Pad Translation),
Also, bottom row of the grid on the right zeros all Send Levels in project.
Right Shift Mode 3: Knobs = User Mappable, Faders = Return Level (1-4)
Right Shift Mode 4: Knobs & Faders User Mappable (this may be broken in current beta, I have to check it....)
Linked Shift Modes 1-4 are the same as for the Left Mixer. While linked, the right Knobs are always assigned to the Return Levels.
The top right buttons Unshifted do the following from left to right, top to bottom:
Play, Stop, Record
Loop, Stop All Clips, Overdub
When shift is pressed, the same buttons control the Device Controller:
Device Left, Device Right, Lock
Parameter Bank Left, Parameter Bank Right, On/Off
The Grid (generally) controls clip launching for the first 5 rows.
The sixth row unshifted is Mute.
The seventh row unshifted is Solo.
The eighth row unshifted is Arm.
The sixth row shifted becomes a device selector (see below).
The seventh row shifted becomes crossfade assign.
The eight row shifted is stop clip.
If Monomod is connected, pressing the Livid button will put the Ohm64 in Monomod mode. IF MONOMOD IS NOT CONNECTED, PRESSING THE LIVID BUTTON PUTS THE ENTIRE GRID INTO USER ASSIGNABLE MODE.
Device Selector: a quick way to select a device without actually changing tracks. This is mostly useful if you are using Monomod and its LCD screen. Rename your plugin with the prefix 'p1' through 'p8' (for each button in the device selector), and when you press shift and one of the device selector buttons, the plugin will automatically be loaded into the Device Controller. (You have to release shift before the change is reflected on the LCD....this will be changed on the next version, hopefully)
Master Volume and Cue Volume: Press the Right Shift, and while it is held, the far Right Fader becomes the Master Volume, and the far Right Knob becomes the Cue Volume.
Oh, and you may notice that now when you change modes, the backlighting of the Ohm64 changes to let you know. The method of lighting for each mode may be changed in the MonOhmodMap.py file, along with all the User identifier/channel settings for each button.
I think that's it....if I've missed something, please refer to the Help section of Monomod (if you have it). I'm working on some video tutorials at the moment, but I have a show tomorrow night and it will take me a bit longer than planned. In the meantime, I'm posting a short "wank session" video I did after getting frustrated with my fourth attempt to narrate a comprehensive tutorial video...no musical value, and very little tutorial value, but at least it gives you an idea of what is possible with the script, and some reasons to use Monomodular in conjunction with the Ohm64.
Some technical notes about changes and additions: I maintain that I did NOT spend a week making some silly-ass tutorial sketch merely to enlighten the public. In fact, I had some ulterior motives. The framework I built will become the basis for the next major revision of the _Framework Mods scripts, making it possible to easily add/remove capabilities to this generic schema of control setup. Take a look at the js bundled within Monomod, if you have inclination. There are a bunch of functions I've added that are of general use for anyone working with the _Framework scripts, and they basically function the same as their corresponding components in Python. If you use the 'element()' function to create an API object, it will be appended to an array that can be easily destructed upon dissolving the patch. It also allows the assignment of other attributes upon instantiation of the object. THIS GREATLY SIMPLIFIES THINGS, and should be incorporated into the js 'Live API' object itself, in my opinion. There is also a dictionary that defines a bunch of regions (this is what powers the INFO engine)...that's the bit that will eventually become the new framework for the Python stuff, and is borrowed (read: stolen) from the Device naming dictionary method's in the _Framework scripts.
Unless you've done some work with this sort of thing, you probably didn't blink an eye; but if you have done some work with this sort of thing, you should be saying, "Holy Hack, Batman! How the hell did he do that?!" I've been talking for a while about adding some overloads to deal with the crippled _Framework components that Ableton has given us with the stock m4l. Now it is possible to have the values sent to the connected controller forwarded to callbacks in m4l. It is also possible to send value's from m4l objects and be received in the same manner that they would be received if the controller was sending them. In short, I'm working towards the goal of being able to use the _Framework scripts to do all the heavy lifting, but still be able to tell them what to do from m4l (which is much more scriptable). I think I have succeeded in this, but only time and testing will tell.
The short of it: the tutorial sketch is the Framework for the new iPad interface. That means that soon you will have the ability to access all of this functionality (and MORE!) through TouchOSC. It also means that the script I have written should be adaptable to other control surfaces, either through coaxing in Python, or direct interaction in m4l.
Planned changes: Oh, lots ;)
In particular: before final release (or possibly in first revision, depending on how much time I have), I am going to add some components that tell m4l when the controller is actually present, as well as when the script destructs (so that it can clean up without any hassles).
If I can find a good way, I will add some stuff to automatically orient the crossfader correctly (I've been going round and round with this....nothing satisfies me so far). In the meantime, make sure that you reverse the stock orientation of the crossfader with Ohm64Control.
There is some tweaking to do still with the grid in Linked mode....I just noticed since I've been documenting things, and asking myself, "hmmmm....I wonder what that does in this mode...." Alas, we are all fallible, every one of us.
Channel Select is not working as I planned when in Monomod mode: this will be fixed.
I think there are some incorrect assignments for the grid in Right Mixer Modes 2-4. This will get fixed.
General documentation in the Python script will be added, and I'll clean it up a bit, when I know that everything is working optimum.
There will be User configuration mapping to change a few default behaviours:
1. Whether or not using the Device Selector also puts Live's focus to the Plugin being controlled.
2. Default boot state of the Mixer mode (Linked or Unlinked).
3. SUGGESTIONS ARE WELCOME, AND I WILL IMPLEMENT THEM IF ITS NOT TOO DIFFICULT.
I've probably left out tons of important details....
Cheers for now, enjoy, and let me know if anything isn't working as expected.
James
("The check is in the mail".....beta testers will see files this evening, in the meantime you can check out this video:)
http://www.youtube.com/watch?v=9ypoR7JH1cY
5.1.11
Done, but still not done....
Ohm64 script is done.....I'm writing tutorials and testing it presently. Out to the tester's in some random number of hours, and to the public very soon afterwards. Any time now, any time now.....
Subscribe to:
Posts (Atom)