Hi. This maybe of interest to this thread. According to this guide (p9) the pad colours can be customised by RGB values using sysex. https://cdn.inmusicbrands.com/…/APC%20mini%20mk2%20… ‘RGB pad colors can be customized using SysEx commands. This message is sent to the device to set one or several of the unit’s RGB LEDs to a specific color. The color is created by sending three 8-bit color values for each color component (Red, Blue and Green). Standard MIDI only supports 7-bit messages, so each color in the RGB Color Lighting message will be expressed using MSB/LSB.’ What that all means in practice is way above my head but I am thinking of creating a translation where I take the usual ch/note/velocity info and change what colour it outputs using sysex. Basically customising the colours to my own liking. I just don’t know how to intepret the sysex documentation into practice.

Yes, I saw that in the manual. In reality this is probably over most people’s heads and I’m not really sure how good the color resolution is of the LED’s. Total of 16383 of each red, green and blue values would be a lot to ask for for a low cost LED. My guess is that the LSB’s are not going to show much difference and maybe just 2-4 high order bits of the MSB’s will. I can show an example if you really want to explore this further. Steve Caldwell Bome Customer Care Also available for paid consulting services: bome@sniz.biz

I am interested. I wonder if it would be complicated to do a test project where Akai faders simply change all the rgb values to test how the pads LEDs actually render colours. That could also help me unpack what the sysex would actually look like too. But I confess it is way over my head as to where to start and how complicated it could be. I’ve never actually created a sysex message though I’ve been using MIDI since the 80s. Obviously accept it won’t be the full resolution of 8bits, but rounded to match values, but hey, we do 128 midi values to 255 DMX all the time, don’t we? :slight_smile: My ultimate goal will be to convert DMX RGB to pad LEDs RGB.

Hi, please show the below example. I use the first 6 faders to designate MSB and LSB values for red, green and blue. Faders 1 and 2 hold red MSB and LSB Faders 3 and 4 hold green MSB and LSB Faders 5 and 6 hold blue MSB and LSB I use global variable gb to hold the value of red, gc to hold the value of green and gd holds the value of blue. In Preset 0 (Init) translator 2 (0.2). I set the initial values. I also set the target note (LED) number. Translator 1.1 handles all of the fader manipulation and note values. I determine by fader which color to manipulate within the rules. Warning… they are likely too complex for most users to understand at first but essentially I have to only update a portion of gb, gc, or gd since faders handle only 128 values and as I said earlier using MSB and LSB values together you get 16384. As it turns out, it appears that only bit 0 of the MSB is used by the APC-MINI MK2 so essentially it recognizes only values of 0-255 with the MSB only being a 0 or 1. I didn’t find this out until after I completed and tested the project. Translator 1.0 output is ‘Perform’ with the parameters of: Note Number Red Value Green Value Blue Value Translator 1.1 takes these values and the splits them of to send a raw MIDI message using System Exclusive (SysEx) I use aliases as in my case I’m using named virtual ports instead of the actual device but I did test it with the actual device. You will need to point them to your actual controller. [image] You can learn more about aliases from this tutorial . Also I set up my device management at the preset level. For more information about device selection, see this tutorial . If you open the MT Pro log window, you can see more information on what is happening. apc-mini-mk2-color-control.bmtp (4.0 KB) Happy learning! Steve Caldwell Bome Customer Care Also available for paid consulting services: bome@sniz.biz

Hi Steve, Wow. Thanks. This is very interesting and helpful and pretty dang cool. [image] SteveC: It appears that only bit 0 of the MSB is used by the APC-MINI MK2 so essentially it recognizes only values of 0-255 with the MSB only being a 0 or 1. I didn’t find this out until after I completed and tested the project. This is how it seems on application as well. The MSB is essentially toggling the LSB between the lower range and upper ranges of brightness. Even values=lower - Odd values=upper. I’m going to attempt to put each colour on a single fader, albeit with lower resolution. If I can do that, then it will be fairly straight forward to control the pad colours via DMX over ArtNet. I’m attempting to deconstruct your maths and in doing so, learning lots. Thanks Steve.

Hi Steve, I tried to modify to use just one CC(fader) per color. Using this basic math. If CC value (qq) =<63 MSB = 0 LSB = qq*2 (ie lower range 0-126) If qq >63 MSB = 1 LSB = pp*2-127 (ie upper range 1-127) My math is good but the execution in the preset is terible :(. I realise, as I expected, I’m in way over my head. apc-mini-mk2-RGBcolor-control_singlefader.bmtp (3.8 KB) Though I will persist. Any advice is appreciated though.

Hi, You cannot send a MIDI value out more than 127 which is why they break it up in 2 bytes. Anything higher than 127 indicates a control byte. Best to just deal with MSB always 1 and use values 0-127 for the color values. Of course since DMX allows for 8 bits (value up to 256) so there will need to be some way to convert to 8 bits on your DMX lighting system. Steve Caldwell Bome Customer Care Also available for paid consulting services: bome@sniz.biz

I change the project as follows MSB and LSB are always the same value. We put them both based on the value of incoming LSB Since even numbered LSB always turn the LED off, I made the output always put out odd numbers except for 0 when we truly want that color off The above were handled in the rules and output of translator 1.1 New Rules: // fix red pp=pp>>7 tt=pp%2 if pp==0 then skip next rule if tt==0 then pp=pp+1 // fix green qq=qq>>7 tt=qq%2 if qq==0 then skip next rule if tt==0 then qq=qq+1 // fix blue rr=rr>>7 tt=rr%2 if rr==0 then skip next rule if tt==0 then rr=rr+1 On output I put out LSB value for both MSB and LSB Output Sysex // Header F0 47 7f 4f 24 // Number of bytes MSB 00 // Number of bytes LSB 08 // Start Pad oo // end pad oo //red msb pp //red lsb pp // green msb qq // green lsb qq // blue msb rr // blue lsb rr // Footer F7 On the input of 1.0, I mapped the faders so that the first 3 faders would handle the color mapping. This is a kludge so that I didn’t have to modify the rules below which were hardcoded to certain incoming fader values. Rules if pp<48 then exit rules, skip Outgoing Action if pp>50 then exit rules, skip Outgoing Action // Kludge added So that consecutive faders work // First 3 faders to match rules below rr=pp if pp==49 then rr=50 if pp==50 then rr=52 pp=rr The rest of the rules below that, I didn’t touch. Now the first fader handles red intensity, the second fader green intensity and the third fader blue intensity. apc-mini-mk2–single fader-color-control.bmtp (4.2 KB) In reality we could simplify by changing the whole translators to follow similar logic and remove a lot of rules that are no longer applicable. I just don’t want to go there right now. :wink: Steve Caldwell Bome Customer Care Also available for paid consulting services: bome@sniz.biz

And then I decide to just create a more simplified version. It still baffles me why even numbered values turn the LED color off and I have to use only odd numbered values. To me it looks like the manual is not 100% accurate. apc-mini-mk2–single fader-color-control-simplified.bmtp (2.9 KB) Steve Caldwell Bome Customer Care Also available for paid consulting services: bome@sniz.biz

This one is even better. I basically double the value of the incoming message. Since the max value is 254, I add 1 to that to get the full scale. This is done in translator 1.0 if pp<48 then exit rules, skip Outgoing Action if pp>50 then exit rules, skip Outgoing Action // scale it tt=qq qq=qq*2 if qq==254 then qq=qq+1 Log "Scaled value is %qq% Original value is %tt%" if pp==48 then gb=qq if pp==49 then gc=qq if pp==50 then gd=qq Label "done" ww=ga // perform paramters // ww is note number // gb is red value // gc is green value // gd is blue value Then I break apart into MSB LSB in translator 1.1 // from page 9 of the APC MINI MK2 Communications Protocol if zz!=0 then Log "Log note %oo% red=%pp% green=%qq% blue=%rr%" // fix red uu=pp>>7 pp=pp&127 // fix green ss=qq>>7 qq=qq&127 // fix blue tt=rr>>7 rr=rr&127 The document is accurate, it was just my brain that was off :wink: apc-mini-mk2–single fader-color-control-simplified-better.bmtp (2.9 KB) Steve Caldwell Bome Customer Care Also available for paid consulting services: bome@sniz.biz

Hi. I’m just catching up on these and away from my system to load this up but keen to do so. My thoughts on next step are to map running CC#s to running Note Numbers (Akai Pad)/R, G & B. (with initial offsets) |CC#1 | ww (note) 1 | Red (0) |CC#2 | ww (note) 1 | Green (1) |CC#3 | ww (note) 1 | Blue (2) |CC#4 | ww (note) 2 | Red (0) |CC#5 | ww (note) 2 | Green (1) |CC#6 | ww (note) 2 | Blue (2) …etc the math for the numeric base would be pp (CC#) ww= 'ceil(pp/3)` (note number) Colour= **pp mod 3** (0=gb(red), 1=gc(green), 0=gd(blue) where ceil is the ceiling function that rounds up to the nearest integer. where mod is the modulus operator that finds the remainder after division. Is that type of math possible in BOME? I have various means of converting DMX (ArtNet/SACN) Channels to MIDI CC, so if the above could be achieved in a single pass-through it would be straightforward to control all of the LEDs from a lighting controller or software. Each pad=1 Fixture (Generic RGB). That would open up a world possibility for keeping the pad colours in sync with the console… any console.

Bome Forum

Sending LED colors to APC-MINI MK2 using System Exclusive (SysEx)

Bome Products

show post in topic

Home
Categories
Guidelines
Terms of Service
Privacy Policy

Powered by Discourse, best viewed with JavaScript enabled

Go to bome.com

Contact Imprint Privacy Statement Terms & Conditions