Code/CNTRL:R — set LED-Ring Behaviour in Max?

Shogun

I am currently working on a Max patch which enables me to determine the RGB-feedback on my controller from Ableton Live.

I would like to do the same for the LED-rings of the encoders (Code or CNTRL:R), i.e. have certain rings display walking rings for automated parameters, sends and volumes filling rings, eq mode for dry/wet and pan etc. as well as spread e.g. for filter resonances respectively — according to one's need and controlled by Max and not the Editor.

I know there is a way and people here who know the how, but I don't yet know which messages to send on which MIDI-channel (presumably 16) for individual rings to switch their LED-mode. For buttons this is easy because the velocity defines the color — but for CCs I wouldn't know what to do.

Help appreciated!

The patch will be something to absolutely relish for all Ableton/M4L users with Livid controllers.

Mark

You just send a CC using the ctlout object I think. The value of the CC determines the LED feedback.

Please share your patch when you're finished!

Shogun

hm… two things to mention here:

1) I use Max For Live, hence ctlout is something I cannot use at all — I have to use midiformat to send the compiled values to the output port (an mxj nk.midi output object that accesses MIDI ports outside of Ableton Live). ctlout sends the data into the unknown, unfortunately (in M4L, unlike Max 'standalone' which I do not have).

2) I have not much experience with Max yet, but afaik ctlout (just like noteout or -in) simply collects the controller (or note) data (number & value) with the midi channel so the LEDs know what to display. This affects the LED ring of course, but only its value, not its mode — I am all about changing the display mode of the ring, which has nothing to do with its actual value but with the way it handles it…

say all LED rings on the Code were set to 'walk' on the preset created in the editor. Now In Ableton I am controlling dry/wet balances with some of my encoders, and now I want to send a message to the Code which lets me change the chosen encoders' LED-ring feedback from 'walk' to 'eq' — there must be a solution to this, without sysex… does this make more sense now?

kind regards & thanks for replies.

Mark

I think sysex is the only way to change settings on the fly like that. Max standalone can send sysex, I'm not sure about max4live. What are the limitations of M4L?

Shogun

First off:

Q: why does it happen, that in the editor the entire LED rings (of all banks) are set to 0 as opposed to default 33, 34 etc. and even though the preset was saved with values other than 0 — this might clear up things here!

I am not sure about all the limitations, but by default M4L does not support external MIDI Ports and is basically only able to use the patch-device's in/out ports, this being merely good for sending MIDI data to Ableton tracks or control other devices within Ableton. I have however found a solution which makes all the external ports accessible, which is why a patch like this actually make sense in M4L because it otherwise would never work.

Peter has uploaded a video on MIDI handling of the CNTRL:R in Max6 recently, there he clearly states that 'the way an LED-ring draws' can be determined in the patch…

Part 3/4 discusses LED-feedback:

Having adapted the parts of the patch into M4L-compatibility, I can now change specific encoder modes (absolute/relative), the global encoder speed and local control for all buttons and encoders. Unfortunately imo, the encoder modes of 'absolute' and 'relative' are always linked to a change in the global encoder speed, so I need to conjure up an algorithm to change the encoder speed back to its previous state after making the assignments… this is doable though.

What DOESN'T work is the LED-ring display change, which is what this thread was originally about. I think this has something to do with the fact, that the encoder rings are mapped to 33, 34 etc. by default other than 1, 2… like its encoders and what's more: according to the editor my led rings are all mapped to 0 (what's this about? this must be the reason why the rings do not receive the info I send to them) — I've had this before and am not sure how it got solved. There will be a way to solve this (if you have a clue, let me know please!) and also the assignments of LED-display is controllable from Max for the controllers in the selected bank — this is now almost certain. just a tiny piece of info missing.

This table here was revealing, but didn't bring forth the desired change, probably for reasons mentioned above.

https://docs.google.com/spreadsheet/ccc?key=0AjLDw8_l-X4rdHZkZzAwSnhFWmVCXzlDVERtWWhoRHc#gid=2

Shogun

alright here we go, worked it out after all.

the issue had to do with the LED-ring mapping, which—if it is identical to the encoder's CC value—only changes the global encoder speed but not the ring display… if the LED-ring is mapped to something other than the encoder it belongs to it is able to receive ring display changes! Inside Ableton Live!

Q: What does this mean and why on earth would you even want this?

A: Imagine a Livid Editor inside Ableton Live where one, several or all buttons and notes can be mapped & customized in all varieties, saved in presets, easily recalled, even during a live session, automatable and much more convenient to apply your changes in than using the Editor. The implementation of shift buttons, momentary modes for toggle parameters, direct bank access and customized led feedback for any Livid controller is now officially possible. Yes!

I'll get down to building the effing patch right away.

see you at the festival of light.

amounra

Hey there, 

Monomodular lets you address individual LED rings without having to do all the math, so to speak.  It allows you to have 16 different banks (mods) all with their own stored values, and you can switch between them easily...you'd need to be using the Codec script I wrote.  These features are NOT well documented, but if you're interested, drop me a PM and I can get you started....

a

Shogun

Monomodular?

How??? I had no clue and yes, there seems to be no hint at it anywhere in the docs, but that's great & very useful for keeping overview and knowing what's where.

I haven't installed the latest Monomodular for Live9 yet — is it fully compatible and runs smoothly? if so, I will certainly embark on it and let you know how you can help! thanks for this. is b996 the latest?

though having said that, all in all I am piecing together a python-free m4l patch that enables me to introduce shift buttons for secondary functions in a bank, takeover mode for sliders and knobs (especially useful with banking), different led ring settings for each assignment if needed, encoder modes & speed, sequencer feedback, customized color-mappings for buttons (indispensable for the ohm in ableton), preset storage, resetting of parameters, local control for assignments without feedback etc. — let's see what the monomod-script has in store.

thanks for the hint, will get back at you!

amounra

b995 is the last release version that works with Live9, b996 is still a "work in progress"...it only supports Base and Push at the moment.

It sounds like you have things working pretty well already....you may want to stay the current path.  It's always better in my experience to have absolute control over your environment, which only happens when you've written all the control protocols yourself (the very reason I came up with Monomodular in the first place).  In any case, if you want to mess around with the Monomodular calls for Code, there is a patch in the mods folder called mod_help, and a subpatcher therein called [p codec] that has all the Code related stuff.  You can access the functions to try them out without opening the patch in the editor....you would need to be using the Codec script, and have the help mod selected while in modMode on the controller.

a