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
10.1.11
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.....
28.12.10
Back On Track
I've gotten back to the Ohm64 over the last couple of days, and the script is very very very nearly finished. A few finishing touches to be added, and then I can start reworking the control_surface integration with Monomodular.
I've added extra functionality to the linked mixer mode, giving it its own zooming component. In addtion, I've enabled the feature found on the iPad script of linking the volume fader to the first instance of a "Velocity" plugin's "OutHi" parameter when its available on a MIDI track with no audio output. I don't expect anyone to have the slightest idea what I'm talking about, but the good news is that once this is finished I'll have a chance to do some video showing what this stuff really does.
I've added some other goodies that will make you feel like your driving a spaceship or something....you'll just have to wait and see. I'm truly hoping to get the Python script out by tomorrow.
I've added extra functionality to the linked mixer mode, giving it its own zooming component. In addtion, I've enabled the feature found on the iPad script of linking the volume fader to the first instance of a "Velocity" plugin's "OutHi" parameter when its available on a MIDI track with no audio output. I don't expect anyone to have the slightest idea what I'm talking about, but the good news is that once this is finished I'll have a chance to do some video showing what this stuff really does.
I've added some other goodies that will make you feel like your driving a spaceship or something....you'll just have to wait and see. I'm truly hoping to get the Python script out by tomorrow.
21.12.10
Woes
It's been a tough week. My VW bus caught on fire, one of my roommates attempted an ill-conceived mutiny, and my internet has been down for 5 days. Consequently, I haven't gotten much work done on the programming side of things. On the bright side, I've been recording some music. Just a quick update to let you know what's going on.....
Hoping your week has been better than mine ;)
Hoping your week has been better than mine ;)
11.12.10
Python is FUN!!
I'm getting the hang of this now. I've been all over the _Framework now, and at last I understand exactly what is going on in there (well, as much as possible, since true understanding requires two things that I don't have: the current decompyled versions of the scripts, and the backend code that its connecting to).
I've managed to create the necessary overrides to the _Framework so that a standard control script can be modified to include the ability to completely control the functions of the script from within m4l. This means that, for instance, you want to tell the script that a button is pushed on the controller attached to it from m4l, you simply send a message to the corresponding button element with the new value. This wasn't possible before, nor was it easy to achieve (er....it was minor, but it took me a long time to understand how to do it).
I've also managed to create a new Module that overrides the functionality of the ModeSelectorComponent. It allows the ability to assign listener functions to different elements of the Control_Surface, and forward their values directly to m4l when their values change. Those of you that have investigated the C_S portion of the m4l implementation have probably noticed that there aren't very many things that you can actually observe in the C_S objects. In fact, there are only two observable properties: 'value' of __controls__ (which are not even a defined property within any layer of the __control__ heirarchy) and 'mode_index' of the ModeSelectorComponent __component__ (which does have a property, '_mode_index', but the property has a preceding underscore). After tinkering a great deal with all of this, I've come to the realization that there is no general way to get an observable property from modifying the scripts, as there is specific functionality built into the backend code that connects Live to the Python implementation; it must search for specific instances of these modules and connects to staticmethod functions to retrieve their values when they change.
So, instead of giving up, I created an override of the ModeSelectorComponent that allows it to be used as a ValueListenerComponent, and thus transmit the values sent from MidiMap in Live to the m4l side of things simultaneously. Certain value changes can be intercepted in the scripts (usually button values), but most Midi data (bound encoders) is never forwarded to the script before being sent from Live to the controller. This caused me enormous grief, but ultimately gave me a much better understanding of how the scripts work.
Bottom line: the most current version of my scripts allows both settable and listenable properties for every connected control in a script accessible directly from within m4l. This is how things should have been from the beginning....it is, I think, what we all expected regarding control_surface support when m4l was released.
My motivation for doing this all this is to enable the use of Python for all control_surface purposes. The _Framework is much faster processing things than m4l, so all I need from m4l is to be able to set and receive the values that would be sent to a Midi controller. A new version of Monomodular will arrive shortly, which implements an iPad script with much less bloat, and much greater dexterity.
I discovered some bugs with the Python bridge. These bugs have to exist in m4l also, since it is basically just another Python script. Its probable that Ableton knows about them, and has a way of avoiding them by not doing something that I'm unkowingly doing. I will publish some more data about this when I get more information (I need to test the raw Ableton scripts to see if they are generating the same errors). In the meantime, if anyone has questions please contact me directly.
I've managed to create the necessary overrides to the _Framework so that a standard control script can be modified to include the ability to completely control the functions of the script from within m4l. This means that, for instance, you want to tell the script that a button is pushed on the controller attached to it from m4l, you simply send a message to the corresponding button element with the new value. This wasn't possible before, nor was it easy to achieve (er....it was minor, but it took me a long time to understand how to do it).
I've also managed to create a new Module that overrides the functionality of the ModeSelectorComponent. It allows the ability to assign listener functions to different elements of the Control_Surface, and forward their values directly to m4l when their values change. Those of you that have investigated the C_S portion of the m4l implementation have probably noticed that there aren't very many things that you can actually observe in the C_S objects. In fact, there are only two observable properties: 'value' of __controls__ (which are not even a defined property within any layer of the __control__ heirarchy) and 'mode_index' of the ModeSelectorComponent __component__ (which does have a property, '_mode_index', but the property has a preceding underscore). After tinkering a great deal with all of this, I've come to the realization that there is no general way to get an observable property from modifying the scripts, as there is specific functionality built into the backend code that connects Live to the Python implementation; it must search for specific instances of these modules and connects to staticmethod functions to retrieve their values when they change.
So, instead of giving up, I created an override of the ModeSelectorComponent that allows it to be used as a ValueListenerComponent, and thus transmit the values sent from MidiMap in Live to the m4l side of things simultaneously. Certain value changes can be intercepted in the scripts (usually button values), but most Midi data (bound encoders) is never forwarded to the script before being sent from Live to the controller. This caused me enormous grief, but ultimately gave me a much better understanding of how the scripts work.
Bottom line: the most current version of my scripts allows both settable and listenable properties for every connected control in a script accessible directly from within m4l. This is how things should have been from the beginning....it is, I think, what we all expected regarding control_surface support when m4l was released.
My motivation for doing this all this is to enable the use of Python for all control_surface purposes. The _Framework is much faster processing things than m4l, so all I need from m4l is to be able to set and receive the values that would be sent to a Midi controller. A new version of Monomodular will arrive shortly, which implements an iPad script with much less bloat, and much greater dexterity.
I discovered some bugs with the Python bridge. These bugs have to exist in m4l also, since it is basically just another Python script. Its probable that Ableton knows about them, and has a way of avoiding them by not doing something that I'm unkowingly doing. I will publish some more data about this when I get more information (I need to test the raw Ableton scripts to see if they are generating the same errors). In the meantime, if anyone has questions please contact me directly.
21.11.10
Vacation :)
Vacation from the usual work, anyway. I have a little respite from running sound as much as I have been lately...so I'll only be working 1 1/2 full time jobs for a little while. More time for coding :)
I've been trying to tie up some loose ends over the last couple of days. I've created a javascript that emulates a lot of the functionality of the [coll] object and acts a link between [coll] and [pattr]. There are still some things it doesn't do (mostly related to sorting and use of symbol links to coll registers), but I don't use those features and am not terribly inclined to add functionality for them. Everything else appears to work, so I'm going to package this new object up with all of my patches for the next revision. I'm curious to see how well the system works....it should be faster and more efficient than using [matrixctl] linked to a parameter enabled [pattr]. This object should make future efforts of porting patches between raw Max and m4l a good deal easier.
I'm almost finished with the Sooperlooper interface I've been working on, but haven't had any time to test it out. I'm going to try to take care of that tomorrow.
I have a couple weeks to work without much interuption, and the weather here right now is perfect for staying inside and burning copious amounts of wood (and other burnables) to stay warm and dry. Expect the next revision of Monomodular in short order, along with final versions of the Ohm64 control script. It will see some pretty major additions if all goes well; if not, it will see some minor ones and a quick release. Either way, there will be some note-modes available and Drum Rack support.
I will add a link to the raw files for the [coll_pattr] object. It works by living in between [pattr] and [coll]. You can send it any command you would send a [coll] except for "delete", which is a reserved internal js function name (use "del" instead, it will forward the proper command to the [coll] it is connected to). It updates the pattr with the new coll every time it receives one of the messages it understands. There is a list of functions which it merely passes on to the coll, without making any changes in its internal structuring of the data. It is also capable of retrieving the information directly from [coll] if the two are connected properly. The first, second, and fourth outlets of the [coll] must be connected to the second, third and fourth inlets of [js coll_pattr.js] for [coll] to send its data to the [pattr]. The function "collect" will read the current data from the [coll] object.
If there is no need for collecting data from the [coll], then its only necessary to connect the output of the javascript to the input of the [coll] and send any message you would send to [coll] to the input of the javascript. As long as a [pattr] is connected to the first inlet of the javascript, and has "parameter mode" enabled, it will function nearly identically to the [coll] downstream from it and will store nearly identical data in the [pattr].
"Nearly"...what does that mean? I don't know yet. Some ordering will probably get lost....time will tell. Check it out.
http://dl.dropbox.com/u/6044993/collstore_112110_release.amxd
I've been trying to tie up some loose ends over the last couple of days. I've created a javascript that emulates a lot of the functionality of the [coll] object and acts a link between [coll] and [pattr]. There are still some things it doesn't do (mostly related to sorting and use of symbol links to coll registers), but I don't use those features and am not terribly inclined to add functionality for them. Everything else appears to work, so I'm going to package this new object up with all of my patches for the next revision. I'm curious to see how well the system works....it should be faster and more efficient than using [matrixctl] linked to a parameter enabled [pattr]. This object should make future efforts of porting patches between raw Max and m4l a good deal easier.
I'm almost finished with the Sooperlooper interface I've been working on, but haven't had any time to test it out. I'm going to try to take care of that tomorrow.
I have a couple weeks to work without much interuption, and the weather here right now is perfect for staying inside and burning copious amounts of wood (and other burnables) to stay warm and dry. Expect the next revision of Monomodular in short order, along with final versions of the Ohm64 control script. It will see some pretty major additions if all goes well; if not, it will see some minor ones and a quick release. Either way, there will be some note-modes available and Drum Rack support.
I will add a link to the raw files for the [coll_pattr] object. It works by living in between [pattr] and [coll]. You can send it any command you would send a [coll] except for "delete", which is a reserved internal js function name (use "del" instead, it will forward the proper command to the [coll] it is connected to). It updates the pattr with the new coll every time it receives one of the messages it understands. There is a list of functions which it merely passes on to the coll, without making any changes in its internal structuring of the data. It is also capable of retrieving the information directly from [coll] if the two are connected properly. The first, second, and fourth outlets of the [coll] must be connected to the second, third and fourth inlets of [js coll_pattr.js] for [coll] to send its data to the [pattr]. The function "collect" will read the current data from the [coll] object.
If there is no need for collecting data from the [coll], then its only necessary to connect the output of the javascript to the input of the [coll] and send any message you would send to [coll] to the input of the javascript. As long as a [pattr] is connected to the first inlet of the javascript, and has "parameter mode" enabled, it will function nearly identically to the [coll] downstream from it and will store nearly identical data in the [pattr].
"Nearly"...what does that mean? I don't know yet. Some ordering will probably get lost....time will tell. Check it out.
http://dl.dropbox.com/u/6044993/collstore_112110_release.amxd
2.11.10
Back to work.
It's been a while since I've had time to post here. I've been extremely busy in real life running sound for shows that have been going on here in town. It's been fun, but harvest is about over and the weather is getting grim, so its time to hole up in the studio and get some work done there whilst burning things to keep warm.
I won't even go into enumerating all of my plans for ammending my previous work and making things better. I'll try to post on a more regular basis as I work on things. I have some good ideas now that I've spent some time writing the Python scripts for the Ohm64 about how to better use Python to make m4l more powerful and productive. The main goal is a complete rewrite of the TouchOSC interface using Python...but this is still probably a few weeks off. And of course I need to publish the finished version of the Ohm64 script after I've made the necessary refinements to it (thanks to the beta-testers for their feedback on this).
I also want to spend some time documenting the Monomods abstract so that others can use it if they want, however I've given this relatively low priority since nobody has really complained about the missing info. If anyone needs direction, let me know....otherwise I assume no one is using this stuff besides me for writing code.
On the other hand, someone is reading this stuff (and using it presumably)......anyway, people keep downloading it ;)
Cheers.
I won't even go into enumerating all of my plans for ammending my previous work and making things better. I'll try to post on a more regular basis as I work on things. I have some good ideas now that I've spent some time writing the Python scripts for the Ohm64 about how to better use Python to make m4l more powerful and productive. The main goal is a complete rewrite of the TouchOSC interface using Python...but this is still probably a few weeks off. And of course I need to publish the finished version of the Ohm64 script after I've made the necessary refinements to it (thanks to the beta-testers for their feedback on this).
I also want to spend some time documenting the Monomods abstract so that others can use it if they want, however I've given this relatively low priority since nobody has really complained about the missing info. If anyone needs direction, let me know....otherwise I assume no one is using this stuff besides me for writing code.
On the other hand, someone is reading this stuff (and using it presumably)......anyway, people keep downloading it ;)
Cheers.
Subscribe to:
Posts (Atom)