Howdy, Stranger!

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

Sign In with Twitter

edited November -1 in Software Discussion


  • Thanks! This explains a lot. Unfortunately it didn't work completely...
    I've tried for like 10 times to edit the like you did in the post above, but somehow I end up with a 7x8 red box (witch is good!) but no scene launch (even no midi information) and I can only control the first track in the grid of the ohm. I did a factory reset to the ohm but nothing changed...
    In the attachment there is the edited version, maybe you can have look? In the meantime I'm gonna puzzle with trial and error scripting :-)

  • Hmmm, upload no attachment
  • It would probably be more useful to see the log.txt file that was generated when you loaded your modified script the last time. It will tell us what is going wrong, and from there I might be able to tell you how to fix it. Often times bad syntax will cause that sort of thing, and its very usual to have a script load (as yours is doing), but then break once it hits an error.

    You might also try starting from a new script if you didn't already (e.g. download the most recent OhmModes script again from our website...that is what I started out from).

  • Hi Amounra,

    Hereby the log.txt I've looked into the remote script errors but it is hard for me to understand what the problem is...
  • 9667 ms. RemoteScriptError: Traceback (most recent call last):

    9668 ms. RemoteScriptError: File "MIDI Remote Scripts/OhmModes/", line 7, in create_instance

    9668 ms. RemoteScriptError: File "MIDI Remote Scripts/OhmModes/", line 89, in __init__

    9668 ms. RemoteScriptError: File "MIDI Remote Scripts/OhmModes/", line 207, in _setup_session_control

    9668 ms. RemoteScriptError: IndexError
    9668 ms. RemoteScriptError: :
    9669 ms. RemoteScriptError: list assignment index out of range
    9669 ms. RemoteScriptError:
  • No worries, included is the version I've ammended (I should've included it in the first place, maybe, but that also doesn't encourage figuring out things for yourself!). It compiles and works as far as I can tell, but I haven't taken the time to test it thouroughly.

    Evaluating the log error works like this: the compiler starts at the root call that caused the exception, which in your case is the __init__ method of the top level script, which is trying to build the main module:

    `9668 ms. RemoteScriptError: File "MIDI Remote Scripts/OhmModes/", line 7, in create_instance`

    Then it keeps going to each call that preceded the exception. The next one is in the __init__ of

    `9668 ms. RemoteScriptError: File "MIDI Remote Scripts/OhmModes/", line 89, in __init__`

    The next message (the last one) is telling you exactly where the error is:

    `9668 ms. RemoteScriptError: File "MIDI Remote Scripts/OhmModes/", line 207, in _setup_session_control`

    and what kind of error it was:

    9668 ms. RemoteScriptError: IndexError
    9668 ms. RemoteScriptError: :
    9669 ms. RemoteScriptError: list assignment index out of range
    It's the same type of error that I came across (and noted in my earlier post) when I first tried to compile the script. You've asked Python to look up part of an array that doesn't exist.

    So there is an error somewhere in your _setup_session_control method, possibly the exact same one that came up for me. In any case, you can check it against mine and see what is going on. Let me know how things turn out ;)


    P.S. yeah it won't let me put a .py or .zip here either, so here's a link to the file in my dropbox:
  • Thanks for the script. The basics are working now. I'm happy wit it! The problem seems to be the number of scenes given in the scipt. In my own script 7 and in yours 8. That did the trick...
    The thing is still that I want the last row to be empty for Midi assign, now it's part of the buttonlaunch grid.
    I'm also trying to make the scenelaunch column in a different color, but somehow it has the same off value as stopped clips...
  • There's a good question for this thread (or rather straight to you Amounra)... how easy is it to isolate elements from the OhmRGB (say, for instance, a bank of four sliders) and just give them a static MIDI CC assignment, while keeping the rest of the buttons or sliders available to the OhmModes functions?

    Thanks so much for the help btw, it's extremely appreciated!
  • @ jomesin: Ok, that was my mistake. So what's happening is that it's assigning the scenelaunch to shift (obviously) because we gave it 8 buttons to assign. We can fix that by isolating the scenelaunch assignment, it's in _assign_page_0():

    for index in range(7):
    self._grid[7][index]._off_value = SCENE_LAUNCH_COLOR[self._rgb]
    I'm guessing your's may say: for index in range(8)? If so, you need to change it to 7. If that's not it, I'll have to check it out and get back to you.

    @ mux:

    I've created some customized capability in my scripts for doing this sort of thing. You can't do it "out of the box" in the regular scripts, as it relies on some overrides in the ControlElement()s themselves. But basically, that's what I'm doing in the _assign_page_1() method, and you can get an idea of what's going on there. For each control, you need to do several things:

    A). Make sure its not assigned to anything else (this should have been done in deassign_matrix() already, so you shouldn't have to worry about it).

    B) Set a new channel, e.g.:


    It's getting the constant PAGE1_DRUM_CHANNEL from, and you can set up your own arrays in there (it's recommended doing things this way, as it puts all the global variables in one easy-to-edit place...but you can also just assign it manually in the script if you want).

    C) Set the new identifier, i.e. the control or note number you want it to remap to in Live, e.g.


    D) Optional, but nice: Send a different color to the control, if its a button:

    `self._grid[column][row].send_value(DRUM_COLOR[self._rgb], True)`

    The True bool at the end is necessary so that the value gets sent even if the control's cache has the same value in its registry....this happens a lot, and is very frustrating.

    E) Most importantly, you have to disable the ControlElement. This is where my override comes in, as without it disabling the control will merely prevent it from notifying internal methods. We want it to decouple from the script, but continue forwarding data to Live:


    That's about it. If you do that stuff to the button that you want to reroute in one of the _assign_page_n methods, it should decouple it from the surface controls.

    Remember, you have to make sure to remove any other assignments to that element that are being made in the same _assign_page_n() method, or this won't necessarily work.

    I'll be around and in front of my dev machine later if you guys need more help, cheers!

  • Hmm, there are 7's in the script in de page_0 that's not it. Almost there :-)
    Thanks for the help!
  • You know what would really, really help out here? More/better comments in the OhmModes code.

    I would venture to say that a fair number of people attempting to work with the OhmModes code are also attempting to learn Python at the same time, so it would REALLY help out if pretty much every line of code had a comment explaining what it does and, more importantly, why it's doing it.

    Pretty please? Lots more comments in the code? Like, LOTS?
  • On top of this, maybe some extra dumbing-down of the code? Like, for instance, couldn't:

    for column in range(7):
    self._grid[column][5]._on_value = MUTE_COLOR[self._rgb]
    be re-written as:

    # this section sets up the button color for the mutes, as defined in
    # number values after self._grid are X and Y coordinates; the matrix starts counting from 0
    self._grid[0][5]._on_value = MUTE_COLOR[self._rgb]
    self._grid[1][5]._on_value = MUTE_COLOR[self._rgb]
    self._grid[2][5]._on_value = MUTE_COLOR[self._rgb]
    self._grid[3][5]._on_value = MUTE_COLOR[self._rgb]
    self._grid[4][5]._on_value = MUTE_COLOR[self._rgb]
    self._grid[5][5]._on_value = MUTE_COLOR[self._rgb]
    self._grid[6][5]._on_value = MUTE_COLOR[self._rgb]
    self._grid[7][5]._on_value = MUTE_COLOR[self._rgb]
    I mean, I know it's not elegant... but would it make any difference to the overall performance of the remote script to really dumb it down? I know a lot of electronic musicians are programmers, but there's also an awful lot who aren't...
  • (just so as we're clear, I'm studying the framework now and intend to... well, perhaps not *master* it, but at least get to the point where I'm capable.)
  • @ jormesin: I totally misread your last post, and gave you the wrong advice. Sorry about that. I've been a little too busy the last several days to properly address your questions, but I'll hopefully be able to get back to you this evening or tomorrow.

    @ mux: re: comments. There will be a lot more commenting in the upcoming scripts.

    re: dumbing. There are conventions for writing this stuff, both for the sake of performance as well as usablility. But this is more an issue of readability. Its very hard for a programmer to read a script written in the manner you suggest, if for no other reason than that it takes up so much room that you can't see what is going on around it. It's also a very important factor that the more text is in there, the more likely you are to have typed/changed/edited yourself an error into the mix.

    There is a certain amount of responsibility that has to be taken by even a casual editor of these scripts, the bare minimum being that you know how to read Ableton's _Framework. Since I am (largely) mirroring the same style as the Abe's syntax, its not a stretch to read what's going on in the Livid stock scripts if you can read the _Framework. As with any language, learning to write requires first learning how to read. Sorry, there's not a shortcut here. (Well, there is can always hire someone to write your scripts for you).

    I'm here to teach you how to read (sorry if I'm not a so good a teacher hehe ). I'm glad to break it down for you or tell you where to go to learn more about the syntax and the functions in Python, or to explain how something works from the _Framework scripts. I also want the scripts I write to be as understandable as possible to other programmers, so I'm certainly always willing to take advice about readablility....but we've made the page for those that don't have enough Python to make serious edits, and I'm afraid that anything more than that is frankly dangerous without understanding the bare essentials of the Python syntax.

    I hope I'm not coming off as super-pretentious elitist programmer dude....I say it often, I really am just a hack ;)
  • Heheheh, you're not coming off as pretentious... though I do wonder exactly what you mean by "dangerous" in the grand scheme. Am I wrong in thinking that the worst possible thing you could do by editing these scripts is cause them not to work, so that you'd have to download a fresh copy? I doubt somehow a casual editor can cause the OhmRGB to explode. :)

    I spent a good four hours in the scripts last night and made a lot of progress, but even poring over the Framework documentation I still wasn't able to make much sense of an awful lot of it... like, for instance, in the file, the comment is that that file allows reassignment of the controls from their default arrangement. Try as I might, I cannot make any sense at all of why the controls are remapped in that way - like, the "buttons" are mapped to note values 65-68 and 73-76... but why are they in a staggered order??
  • Yes! Thank you. Finaly it is a 7x7 grid. I'm now figuring out how to create a different color setting for the scenelaunch buttons...

  • Hey, can someone clarify one point for me?

    If I am using the stock OhmModes script, and I don't care about a function, I can just use Ableton's MIDI mapping to override the remote script. Is that correct?

    Like, say I don't want the sliders to affect the same tracks as the button grid - can I just map the sliders manually to the channel volumes that I want and those mappings will take precedence over OhmModes, without interfering with OhmModes?

    First of several shows is in twenty days, and I have to lock down my hardware and get back to writing music and rehearsing the show. So far working with customizing remote scripts hasn't been a good experience at all, and about 90% of the OhmModes script (a good script though it is) just doesn't apply to me.
  • You are correct about the remapping behavior: if you don't need a particular function, you can remove its assignments by remapping it with Live's MIDI Mapping. That's how I see most users customize their setups.

    There is another avenue for customizing the scripts I think a lot of users don't know about: the User Remote Scripts folder, in Live's preferences folder. This gives you a way to create a custom script in Live without writing a single line of Python. I've been meaning to do a little 'expose' on the process of getting that going, but in fact all the instructions are in that folder. Just a thought.

    There's also the MonOhm script. It's quite a bit deeper than the OhmModes script, but it might be more suitable for you.

    Re: bad experiences. Yeah, definitely not fun for me either ;)

  • Honestly looking over your MonOhm script a while back it seemed *far* more up my alley... but don't you need a copy of M4L to use that? I just spent my budget on an Ohm controller, I don't have the extra $250 for more software right now. :(
  • hey jormesin, did you ever figure out how to make the scene launch buttons different colours? it's pretty confusing having them the same colour as the clip launch buttons. I see that they change colour when you hit them, but then they return to white again.

    Also, amounra, see if you can follow me here - I've decided that what I really want on my grid is four scenes (so each of the top four rows would have seven clip launches and one scene launch), then three rows of eight clip-launch buttons (no scene launch), then one row left over for MIDI assignment. Is this possible?
  • Hey mux,

    You should be able to do what you'll have to enlarge your session to a width of 8, and just not use all the clip launch buttons when you assign things. I'll take a look when I get a chance and make sure it's possible, but it probably won't be until Monday....I'll be in the woods mixing live sound all weekend, so I won't have internet.
  • Guys, after monitoring a lot of stuff here and I have decided to ask for your help :)
    I have finally decided to edit some assignments in CNTRLR script by Aumhaa.
    Would love to hear your help, some of the things I managed to do myself, but few need your help.
    I am editing 2 bottom rows of Cntrlr assignments.
    How and where to look for:
    1) changing Solo and Mute buttons for Track Devices and Tracks Status
    2) changing Arm and Track Devices to Solo and 8 Bars, 4 Bars, 1 Bar and None Quantization
    3) move Shift up instead of Left/Right Arrow
    4) is it possible to remove Play, Stop and Record, but leave Green flashing button of Play?

    I know it is possible to map some functions via manual midid assignment (Cmd+M), but in this case I will lose sequencer assignments.

    Any help will be much appreciated!
    Thanks in beforehand.
  • Sorry man, been outta town lately and away from internet access. Let me see if I can answer your questions:

    1) I'm not sure what you mean here: are talking about the Device navigation buttons? If so, that's pretty straightforward. By track status, what do you mean?

    2) Quantization: that would be tricky. There's no provision in the _Framework for this sort of thing, so you'd have to write your own Python class for this. I wouldn't recommend that for a would even take me several hours to do this myself, I'd imagine.

    3) Yeah, that also is no big deal. Just a matter of swapping assignments around in the existing script.

    4) Theoretically, no. Practically, that's not going to be very easy to do (see comment to 2).

    I imagine you may have figured some of this out already since this post is over a week old...let me know how you are fairing and I'll help however I can. I'm kind of pressed for time at the moment, so it may take me a minute to get back to you.....


  • deleted double post
Sign In or Register to comment.