Howdy, Stranger!

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

Sign In with Twitter

CODE :: regular LED Feedback dropout

yet another question regarding the Code:

During a performance last night the Code's Encoders happened to not respond any more to MIDI feedback, while I was able to transmit data from the device, changing params did not change the LED Rings. The MIDI tools of the editor confirmed this, messing with local control and loading presets to the device more than once eventually solved the issue but it didn't seem predictable nor comprehensible. I am or was using yesterday 3 custom MAX programs for Code, Ohm & Launchkey, those communicating with the Ableton Sets and vice versa could perhaps have caused this, still there is bound to be an explanation as to why this can happen. Today I've updated the Code's firmware to v222, reloaded my presets and sometimes on one of the banks the same issue still occurred: no LED response of the encoders, and hardly a logical explanation came to mind as to which config causes it, nor how it got solved in the end. The rings do receive the values, the encoders do not. Is there a ctl number/value accidentally sent thru the settings channel or a sysex command combination which could cause this issue?

I really have no idea… help would be awesome, yes, and definitely needed!
thanks very much in advance!
Tagged:

Comments

  • thanks Moon,

    detailed insights are always appreciated! thanks for your reply!

    »…the LED Ring Mapping takes priority, and the Encoder Value does not update«

    this was new to me, I have been wondering what would happen if I were to set both Encoder and Ring to identical values, or have one Encoder receive the same value as another Encoder's Ring… at least this is now clearer — great!
    now I understand that the Encoder value +32 isn't set to control the LED Ring but ideal in a default mapping with 32 Encoders. From what I gather all that needs to be ensured is that all LED Rings are mapped to 32 different numbers from the 32 Encoders to avoid the aforementioned conflict… right?

    »When a message received matches an ledring mapping, then the encoder value does Not change, and the LED Ring does update«

    yes, this is a known and very useful feature for me. I personally use it in Ableton to display meters of channel volumes I control with the Encoder, LC doesn't need to be disabled here for there's a steady stream of LED Ring feed.

    When I tested the LED Rings during the show I had Encoder and Ring set to different values (from what I saw), the Ring responded (i.e. CC 33 in the Editor Tools) whereas the Encoder (i.e. CC 1) didn't…
    not sure where to go from here, will keep testing…

    thanks for your reply and let's hope we get it fixed!
  • Despite having programmed a personal Code Editor yesterday after this awkward interference and understanding most of what the SysEx chart has to offer, there are still numerous commands which are rather nebulous to my. If you have time to answer a few questions regarding mapping of controls/LEDs then not only will this surely solve the issue in the long run, but I could finalize the Editor and share it if anyone is interested. its handling is mega smooth and transparent, and everything can be changed/monitored clearly on the fly with a minimum of guesswork once the system is clear. it requires a few more features to work reliably, but this I certainly need help for.

    any chances?

    image

    — red buttons :: button CC map
    — green borders :: toggle mode
    — green numbers :: encoder note map
    — button/enc maps can be shifted starting from anywhere
    — same property can be set for all controls immediately
    — 3 menus to access and monitor all necessary settings for any control
    — choose which settings are to be changed with preset/migrated to a new one
    — so far so good.

    help appreciated!
  • interesting.

    i have been struggling with the mapping of LEDs as for the indexes aren't intuitive nor logical at all and duplicate assignments aren't supported. unfortunately there isn't a clearcut guide to be found anywhere as to how the mapping of a control to an LED works. from what i gathered, the sysex code for mapping notes to LEDs is built up like this: (¿questionmark?)

    default mapping (notes to LEDs)
    127 0 1 2 3 4 5 6 7 8 9 11 12 13 16 17 18 19 20 21 22 23 24 25 27 28 29 32 33 34 35 36 37 38 39 40 41 43 44 45 48 49 50 51 52 53 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127

    if say, the LED of button #1 (first push encoder) is to be controlled by Note 33 (instead of first gridbutton), the 34rd (33+1) position of the sysex string is to be replaced with the button's ID-1 (i.e. '0'), while its recent assignment (Note 1 —> position 1st+1 = 2nd; 0 by default) needs to be mapped to 127 for Note 1 to not control any LED on the Code. (¿questionmark?)
    then, looking like this:
     127 127 1 2 3 4 5 6 7 8 9 11 12 13 16 17 18 19 20 21 22 23 24 25 27 28 29 32 0 34 35 36 37 38 39 40 41 43 44 45 48 49 50 51 52 53 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127

    if however, the same button's LED is to be changed to be controlled by CC80, the sysex string (36 for CC LED Map), which has this default I believe:

    127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127

    needs the 81st position (CC number + 1) to be replaced by the button's ID (0 in this case for it's push encoder 1(-1) we talk about), while, again, its original/previous cc-mapping (x-pos+1) needs a 127 mapping, like so:
    127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 0 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127 127

    i'm sweating a little…
    unfortunately the numbers don't pertain to the button ID's directly but with a crooked logic of numerous IDs having been removed from the sequence… Note 33 is a 38 and so on…

    i find it difficult to devise a reliable logic that allows custom mapping of LEDs but without sending it to the Code when there are mapping conflicts with other controls. the livid editor lets one know that there are multiple assignments to LEDs but overwrites the older mapping with 127 (no response). it would be better to have the choice, and, what's more — if a button's LED is set to be controlled by a CC and an LED Ring receives the same CC, the editor does NOT remind of this, but maintains the mapping for the LED ring and not the button…

    any hints from your end?
    sorry, but there just was not a way to explain this whole thing simpler, as for it is reeeeally nebulous… i am sweating
  • okay, i've now two global coll objects comprised of the two definitive references lists, thanks.

    And I take it that the encoders' LED Ring Code, on the other hand, ranges from 54 to 85 (32 steps in an uninterrupted numerical seq)…

    this then gives us the following guideline for mapping LEDs to controls on the Code:
    • the LED mappings are formatted as two lists, one each for Notes and CCs respectively
    • hence only one origin of LED control can be assigned to either a Note or a CC (between 0-127)
    • to map a control to an LED, then, depending on its type (Note/CC), the position/index in the formatted sysex string defines which Note/CC is being controlled and the corresponding value gives the origin of control (i.e. a button's LED Code index according to the sheets, or an LED Ring's index between 54-85), which can of course only be one of them

    a lot clearer now, methinks.
    anyhow, you mentioned that

    »When a message received matches an ledring mapping, then the encoder value does Not change, and the LED Ring does update«

    right? I just tested this and the opposite was the case :: having mapped encoder 1 to CC1 and its LED Ring to CC2 while encoder 2 is mapped to CC2 and its LED Ring to 34 … sending a CC2 to the Code changes the second Encoder and not the Ring of Encoder #1. Am I missing something? seems like the Encoder and not the Ring takes priority… same if I map LED Ring #3 to CC2 as well, the second Encoder value is still being controlled… this would actually be preferable as for the rings show the current Encoder values.

    thanks so far. i should be able to work with this for now!
  • big thanks Moon for your detailed answers!

    i have definitely figured it all out now and the only room for improvement is that beyond my own programming lacks… however, I just successfully ran the first test of what I wanted to achieve:

    the actual editor allow presets to be applied to the current bank, selectively migrated from other presets etc. or by remapping everything manually, whether in groups or for a single control. the top-level patcher though, allows storage and recalling of presets for all banks simultaneously, the mapping for the respective banks will be instantly applied when switching to it, hence only a microsecond is taken to remap the LEDs and controls before its safe and stable — thanks to the bank cycle report sysex you provided in the beta firmware. this means one can handle settings for the entire Code in one step, this step automatically being called when a new ableton set is loaded, in my case… just switch to another bank and use the new mappings with pleasure — this is just fantastic.

    thank you so much, the reason i cannot safely share the patch yet, is because i have to run it in my Code App first for the upcoming performances and later I can create a solid public solution that works without the App. sneak preview here:

    image
  • Hey Moon,
    glad you fancy the UI!
    the app is entirely done in Max for I have no programming background and only began modifying scripts for live handling a mere year ago.  Despite a few whimsical fits the whole mapping algorithm seems to work smoothly, however, the app is meant to be linked and be useful to a bigger patch, which hijacks all communication between the Code and Ableton, providing access to numerous ways of controlling the surface and enable more intuition when doing so. I won't go into much detail because it will take me quite some time to turn it into something other people than myself can profit from. Most of the errors caused cannot really be dealt with by others, so I have to take care of this on my own. However, and yes indeed, there still are a few remaining queries regarding the settings on the Code. The LED mapping is up & running so it's all good for now. 

    How can I map Channels to individual controls?
    In the SysEx-chart, as well as in some Code Remote Scripts for Ableton, the command is listed and used as

    Buttons: 240, 0, 1, 97, 4, 19, 45*CH, 247

    Sending this command to the Code doesn't even produce an ACK nor NAK, simply nothing happens, it ignores it. Same with the Encoder Channel Map. I am running your latest beta (with the bank cycle notification integrated) but this seems to have never worked before even… what's the key here???

    Also, I have integrated the 'Map all Bank Channels' command, seems though, since then (?), the encoders do not respond anymore to their mapping (like the initial issue of this thread), whereas led rings do receive and display data… is there a connection?

    thanks for your help, again!
    shgn



  • okay cool,

    cheers!
  • edited December 2014

    Moon,

    seems like I finally devised the correct technique to reliably map LEDs to the Code, however, since there is always some secret setting hiding beyond the obvious when it comes to the device's axioms of communication, one can never be sure about having sussed it.

    only since I set up the entire app from scratch and synchronized all LED Mappings, Encoder Mappings and Button Mappings did all of them work as expected! this means that not only are the encoders to be mapped after the rings, but actually, all mappings have to be sent as a group and ideally in the order one wishes. I only came across this because buttons mapped to the same note as other encoders lost their LED feedback to them. the order for rings, encoders AND buttons are therefore decisive for which LED is controlled by which message…
    is this true then??

    at least it seems to be true, since this works the individual mappings can be indexed and those indexes then stand for the priority of the LED feedback (high priority delayed in output) — if encoders are set to highest priority then LED rings sharing the CC LED assignment will be automatically set to 127 by the Code, and this is awesome for monitoring what's going on. 

    if there's anything else I need to know about sending sysex strings, do kindly inform me about the matter as for it could/would save me a bunch of time otherwise spent in riddle realm…

    cheers
    shgn


Sign In or Register to comment.