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 :)
19.1.11
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)