Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Twitter

Editing OhmRGB mapping in Ableton Live

edited November -1 in Hardware
Hi all

I have an OhmRGB and I'm getting into Ableton Live to put together a live show. I have the OhmModes script up and running and it's very cool, but I'm hoping to get in and edit a few button assignments / colours etc to fit my needs.

This is where I'm hitting a stumbling block. So far I have worked out how to override some of the OhmMode mappings in Ableton to re-assign certain buttons, but how do I change the LED colours? Do I need to get into Python? That's a bit daunting.

An example - on the 2nd page of Ohm Modes, I have the top left grid of (green) buttons playing a drum rack, but I was hoping to re-assign some of the other buttons for recording / looping.

I have mapped some of the red buttons to a Live Looper's main Record / Play / Overdub, Undo and Clear controls. Ideally I would like the RGBOhm to reflect this visually - perhaps with the first button changing colour to reflect whether the Looper is recording / overdubbing / playing. But I can't see any obvious way to assign colours (via velocity) using Live's MIDI editor.

As a comparison - I've been playing with Traktor too, and whilst the mapping prefs there are by no means user friendly, I can at least work them out and set colours up on the RGBOhm whilst also assigning controls. Does something similar exist in Ableton? I expected to be able to open up a page in Ableton listing all of OhmMode's mapped controls and colours somewhere, which I could then edit myself - was this a bit naïve?

Thanks for any help!


  • You can play around with the file "" in the OhmModes script folder, then reload OhmModes in Live (i think you have to load another script, then load OhmModes).
    Using MIDI learn to override a function in the script is one option, but, as you noted, Live provides no option for changing the outgoing velocity and color.
    However, if you want to change the function AND the color, it does get tricky, since you'll have to get into the script and make those changes there. But it's a bit moot, since with the Looper, I'm 99% certain there's no direct access to the Looper device from scripting. Additionally, I think another unfortunate aspect of the Looper provides no feedback to any controllers when using MIDI learn. I think the only real way to get around these issues to to make a Max for Live based Looper, which is probably less than ideal.

    Speaking of Traktor, there's a map for the Ohm64 here which you might find is an easier starting point for working with Traktor and the RGB.
  • Thanks for the reply Peter.

    Re-mapping to Looper was just an example and far from the be all and end all of what I'm planning. I was hoping to be able to make my own mappings similar to OhmModes.

    To be honest, the way the RGB is advertised seems a little misleading - seeing the videos for OhmModes, I assumed I'd be able to set up something similar myself with a copy of Live and an RGB. Are you confirming that it's not possible without learning Python??

    I loaded the Ohm64 mapping for Traktor, but Traktor doesn't seem to enjoy having previously mapped controls overwritten. I was mapping controls and LED info over the Ohm64 mapping, but Traktor was losing connections somehow - i.e. clicking channel 2 cue in the Traktor GUI would illuminate the correct button on the RGB, but pressing the same button on the RGB would register in Traktor's MIDI I/O, but wouldn't actually perform the correct function. Plus there were odd little things like the crossfader being mapped backwards, which made me wonder if perhaps the Ohm64 Traktor mapping was not compatible with the RGB somehow.

    I'm having much more luck by deleting all loaded mappings and starting from fresh.
  • FWIW - editing the Python file for the OhmModes control script is pretty easy. It's just a text file, and most of the controller numbers are pretty easy to figure out (even if you don't know Python).

    Looking at - around line number 84 (bottom of the file), the script goes into the color maps.

    # Note 2 = white
    # Note 4 = cyan
    # Note 8 = magenta
    # Note 16 = red
    # Note 32 = blue
    # Note 64 = yellow
    # Note 127 = green
    COLOR_MAP = [2, 64, 4, 8, 16, 127, 32]

    So the color map equates to [white, yellow, cyan, magenta, red, green, blue]

    The next bit of code is a little confusing, but there are some comments in the code that might help. You might do some trial and error to see what happens when you change those values (Make a backup of the original control script first - just in case).

    Last ditch - you could try to email amounra (who wrote the scripts) for some assistance with your modifications. He posts here on the forums, or you can find him here
  • Thanks stevennoreyko

    So I can just open the .py files in Text Edit or similar?

    How about things like LED flashing / modifiers / colour switching on button presses... will it be fairly obvious how to code such things?
  • Thanks Moon. I'm brand new to Live, so it's doubly hard trying to decipher any of this Python code, since I'm still learning about half the functions in Live it's referring to.

    What are the banks? I assume they're different to what is referred to in OhmModes as pages?

    This is proving to be a bit of a struggle! Today I'm trying to use the 2nd page of OhmModes to set up some kind of MPC-style sample triggering / live sequencing.

    Ideally, I'd like the green and red zones at the top to trigger 2 different drum racks. And then I need to work out some kind of way to record / loop / overdub what I'm playing in those drum racks.

    I'd also like to change the bottom half of the second page so that it still gives access to clip / scene launching for the whole project.

    First of many headscratchers - how do I make the red buttons on page 2 of OhmModes act in a similar way to the green buttons? i.e. triggering the highlighted pads on a Drum Rack on channel 11?
  • 01. How do I clear out the Key / Scales mappings on Page 2 of OhmModes?

    Trying to re-map the buttons in Ableton causes errors, because several of the buttons output duplicate notes. I've gone through the Python scripts and tried simply deleting code which I can identify refers to this section of controls, but this just shuts down the Ohm completely and makes all pages blank.

    02. How can I replace the Keys / Scales mapping on Page 2 of OhmModes with 4 rows of clip / scene launch controls?

    03. How can I replace the function keys on Page 2 of OhmModes so that they mirror the function keys on Page 1 (i.e. Start / Stop / Up, Down, Left, Right Nav)? I've tried copying and pasting code, but only got as far as making a couple of the nav buttons blue, which then turn back to yellow when pressed.

    04. How can I split the top right grid on Page 2 of OhmModes into different colours / functions? I want to set up some kind of control for recording / overdubbing MIDI played on the drum pads in the top left. I need to be able to switch overdub on/off and undo recordings (for starters) and I'd like the button colours to reflect the fact that certain buttons in this grid are assigned to certain functions.

    I've tried making the coloured Bass grid only 2 columns wide as an experiment, but this also affects the size of the coloured drum grid for some mysterious reason.

    05. How can I set up the drum grid buttons to flash when the relevant cells int he drum grid are playing back? The empty MIDI track sending back to the Ohm trick which I've found online doesn't work. Is this something to do with the setup of the pads in OhmModes which enables them to follow the highlighted drum rack grid?
  • Thanks Moon

    Just to clarify my complete lack of programming background - What do you mean by "comment out"?
  •'re trying to do some pretty fancy stuff for having 'no programming background'. I think you will find a lot of this sort of stuff more easily accomplished through m4l, but let me see if I can help with the simple stuff.

    First off, just remapping buttons will only affect WHICH buttons do WHAT....the functions they are linked to will still be present.

    Second off, you can only have one Drum Rack translation per script (_Framework limitation, not mine), AFAIK. That's the bit that allows you to always be triggering the visible portion of a drumrack. If you want to control 2 drumracks, you would have to do at least one of them fixed.

    Third, just commenting certain lines is usually going to get you into trouble. Take a look @ your log.txt file in (assuming you are on OSX)....this will tell you when the python script hits errors; you're flying blind without having a look at this. You are better off changing component states than just commenting things out if you are trying to make functional changes to the scripts,
    for instance:

    self._octave_mode.set_mode_buttons(tuple([self._menu[5], self._menu[2]]))

    You can try changing the enabled state to True, or just comment THIS part entirely. (Not sure what that will do without trying it, but its a step in the right direction).

    Unfortunately, the scale mode and octave mode components are necessary (after a fashion) because they provide the variables for mapping portions of the rest of the grid as well. You can also get rid of this bit:

    int(PAGE1_MODES_MAP[self._scale_mode._mode_index][column]) + int(self._octave_mode._mode_index * 12))

    and it should disable that entire part of the script, I think.

    edit:: actually, just get rid of the end of that: you'd want something that looks like:

    int(PAGE1_MODES_MAP[column + (row*8)]

    That should get you a fixed assignment that is not dependent upon the scale/octave component for the keys.

  • sorry, I knew you were going to ask me about that: Log.txt file:


    That's mine...your's should be in the same place (~ means user space, like: Users/YourName/).
  • 1: Not easy....I'd have to think about it. I don't think it'll work at all without fixed mapping (you'd have to do away with Pad Translation completely), and even then it would be tricky (dependent upon routing in Live, etc.).

    2: That should be pretty easy, let's have a look:

    First get rid of this in page1:

    for index in range(4):
    self._menu[2 + index]._on_value = (DEVICE_NAV_COLOR[self._rgb])

    Then add from page0:

    for index in range(4):
    self._menu[2 + index]._on_value = NAV_BUTTON_COLOR[self._rgb]
    self._session.set_track_bank_buttons(self._menu[4], self._menu[3])
    self._session.set_scene_bank_buttons(self._menu[5], self._menu[2])

    3: It doesn't quite work like that. I've already set up a 5x7 grid, you can't reassign the session dimensions on the fly....once a session component is set up, that's what size it remains. I'm pretty sure you'll get errors if each clipslot doesn't have a button assigned to it. You can have two that are different dimensions, but that is going to require some more practice, grasshopper ;) Each script can only have 1 box at a time, so there are lots of little tricks used to make that happen when two (or more) session components are present in the same script. You might try to rethink how you are working first, and see if that bit is absolutely necessary.

  • Double post....can't I delete a post, guys?
  • 1. I don't mind going with fixed mapping for the drum pads. The more I've read, I'm not sure I'll be able to do what I was hoping to do anyway:

    - Load all one-shots for a live show into a single Drum Rack
    - Scroll through this Rack as the set progresses (perhaps triggered by certain scene changes?)

    With fixed mapping, maybe I could instead map a couple of button to preset navigation in order to change which sounds are triggered by the drum pads?

    2. I removed the code and replaced it with the code from Page0. Now pressing the red stop button wipes out all LEDs on Page1 and the Drum Pads lose their connection with the Drum Rack.

    3. OK... how about...

    ... If you could help me get that up and running you will be my hero and I will make it up to you somehow, someway....
  • ... absolute ideal would be to have 16 drum pads and then some kind of modifier for muting, using the same pads, and some kind of LED feedback to show which pads are muted. I would happily give up a line of clips to make way for more drum pads too:

    OhmModes is a beautiful thing, but it doesn't really fit what I need for live performance.

    I'd love to be able to switch scenes whilst playing pads, all on the same page.

    ... and also "drop in" to record whilst pad playing. Best way I've managed this so far is with empty MIDI regions of preset lengths, and then toggling overdub on and off whilst playing to build up layers. OhmModes isn't really set up for that.
  • Sorry....swamped for a bit. When I get a moment I'll sit down and take a look at your situation to see if I can give some clearer instructions. To be honest, I'm not sure how MIDI feedback works with Pad Translation, as I've never used it. I do all that sort of stuff in m4l. Hold tight....

    I do have time to say, however (because its easier for me to give opinions than look up hard facts ;) ), that if you are after a single page setup that doesn't utilize much of the special portions of the OhmModes script (e.g. pageshifting, scale-mode, note-mode, multi-channel grid, etc) you might be best off starting with a different script, or at least a completely stripped version of Ohm-Modes, and then building up (instead of stripping down what is there bit by bit)....I merely say this because a): you'll then understand what each component is actually doing as you insert it, b): you will run into less errors due to removing portions of routines that are necessary.

    The __init__() function starts the whole thing off, and reads like a table of contents to a book. If you look at each function it lists off, thats the order things are created. Remove stuff that's not needed (like the setup_modes() function, since you are only using 1 page), and put everything in a static function (i.e. assign_page_constants, because there's only 1 page, and its going to remain constant).

    If you go about things in this manner, you're more likely to have success in understanding exactly what's going on. And I think you may also find that even if you only learned Spanish because of the vacation you took to Spain last summer, you're still a lot more likely to go to Spain again in the future.

  • Thanks amounra

    I appreciate the advice, and I can see what you're getting at... but the problem is that I need to have something that works by the end of this week. Learning Python scripting from scratch is more like something you do at your leisure. I can't really justify (or afford) having this controller sitting around collecting dust waiting for the day that I'm finally able to use it.

    Hopefully you guys can see where I'm coming from and understand that from reading the RGB product page and watching the videos, it's really not clear for people like me that the RGB is only "fully customizable" for use with Ableton Live in the same way that, say, the APCs are also "fully customizable"... i.e. through hacks in the API. If you don't know how to code, you're reliant on other peoples' templates.

    Max For Live is way too expensive to buy it just for the purposes of mapping a controller, but I'm frustrated and desperate enough to consider it. Could I get something up and running in a few days with M4L or is it another long slog?

    Could I, for example, map a single button on the Ohm to the Mackie Control CC for Undo
    in M4L (and maybe make it turn blue) without having a nervous breakdown? ;P
  • Well, m4l is just another programming language. I think the 'nervous breakdown' part is that you gave yourself a week to make something work without knowing exactly how you were going to do it. Totally reasonable without the deadline, but with one...I might be pulling my hair out too ;)

    I see where you're coming from, but let me assure you that 'fully customizable' is a pretty correct assessment. You can't do most of the things with the APC that you can do with an Ohm (reassignment of MIDI, banking, etc.). I work with a lot of different controllers (just check out Monomodular, you'll see what I mean). Also, just to be clear, I don't work for Livid; I just really love their gear, and they ask me to write stuff for them from time to time.

    Specifically regarding your last question: you can do the same sort of thing in Python, its just a different language. The limitations your talking about with all of these things are limitations imposed by Live, not the OhmRGB.

    Best advice: scale down your expectations a bit, work with what works for now, and keep learning what you can. You still have the best controller available, and quite frankly, I don't think anything else does what you want it to out of the box anyway.

    There are also scripters that will write exactly what you want for some dough (I do happen to be among them, but that's not a plug - I promise!).
  • Guilty....It should be pretty easy to add a page to the existing script that's completely user-mappable (meaning no assignments at all), but also capable of having its own color map. Would this help, at least for your current situation?
  • Make sure its not mapped in Live's MIDI Map? This will defeat any Python stuff (it intercepts it before the CS script gets it)....otherwise, make sure things aren't screwy by doing a 'reset to defaults' with the OhmRGB Editor. Which MIDI light is flashing, the left or right one?
  • No notes mapped in Live's MIDI Map.
    I have reset to factory default in RGB Editor.
    It's the yellow light to the left of the MIDI map button in Live that flashes.

    Even leaving the Project X mapping untouched has the same result - pressing the button assigned to play (61) does nothing, but pressing play in Live's GUI lights up the correct LED on the Ohm.

    Switching back into OhmModes, the buttons work as expected. So what is in the ProjectX code that stops Ohm button presses performing the assigned functions?
  • I'm not sure what the deal is with the ProjectX script and the transport. It could be a channel thing....that's weird, though. I'll check it out Friday when I have my Ohm in front of me.

    I'll work on a version of the OhmModes script this afternoon as time permits that will give everyone a good starting point for further script changes, and also allow color mapping from within the script (not sure how to do that yet, either).


    edit:: making a blank template is no problem, but getting the color map thing working, I don't even know if that's possible since Live is intercepting Remote Mappings before Python gets the data. Should have thought about that a bit more....(and will).

    Drop me your email addy, I'll send you what I've got.
Sign In or Register to comment.