Hi all,
I would like to control the on/off state of the 12 LEDs on my MIDIbox64e via MIDI messages. These LEDs don’t have anything to do with the buttons (as you would normally expect), but they are there to signal the state of external MIDI machines or software.
So the question is: what message do I need to send to my MIDIbox64e to toggle these LEDs, and what do I need to change in the mk_syx (if there is anything)?
Thanks a lot in advance, ilmenator
See this posting http://www.midibox.org/forum/index.php?topic=6039.0
Best Regards, Thorsten.
Thanks Thorsten,
at the moment it looks like this thread is going to be more appropriate for “Troubleshooting” than “Design Concepts”…
I’m afraid I need to tell a little more about the issues I am having here. I have to modify a Midibox which was built by someone else in his student’s project. The box is based on a Midibox64e, it has four motorfaders (touch sensors connected to SR1 of DINX4-1), 14 buttons (connected to SR2 and SR3 of DINX4-1), 12 LEDs (connected to SR1 and SR2 of DOUTX4-1) and two LCDs (2x40 and 2x20, only the first one is actually working - the second one will have to be made working by me someday…). No rotary encoders in the box. The buttons are configured to send MIDI note on messages when pressed and MIDI note off when released. The Faders send MIDI CC and move accordingly when these controllers are received.
Now, I tried to re-configure the system using Serge’s Midibox64e tool (‘‘vmidibox64e’’), but actually setting the SR #1 and #2 to ‘‘MIDI Status rec. for Entry #0-7’’ (and ‘’..#8-15’', resp.) in the DOUT Shiftregister Map dialogue like suggested in the posting above does not have any effect.
In mios_tables.inc, there were only 8 entries in the MIOS_MPROC_EVENT_TABLE, so I suspected this would be the problem. I changed the table to
MIOS_MPROC_EVENT_TABLE
;; entry 0x00-0x0f
MT_ENTRY 0xb0, 0x15
MT_ENTRY 0xb0, 0x16
MT_ENTRY 0xb0, 0x17
MT_ENTRY 0xb0, 0x18
MT_ENTRY 0xb0, 0x19
MT_ENTRY 0xb0, 0x1a
MT_ENTRY 0xb0, 0x1b
MT_ENTRY 0xb0, 0x1c
MT_ENTRY 0x90, 0x40
MT_ENTRY 0x90, 0x41
MT_ENTRY 0x90, 0x42
MT_ENTRY 0x90, 0x43
MT_ENTRY 0x90, 0x3c
MT_ENTRY 0x90, 0x3d
MT_ENTRY 0x90, 0x3e
MT_ENTRY 0x90, 0x3f
;; entry 0x10-0x1f
MT_ENTRY 0x90, 0x44
MT_ENTRY 0x90, 0x45
MT_ENTRY 0x90, 0x46
MT_ENTRY 0x90, 0x47
MT_EOT
MT_EOT
.....
…but this did not render any different results.
Then I compared the main.asm file of that project with the one contained in the midibox64e_v2_2 application for the original midibox64e. There are a number of differences, which I do not fully understand. I think it would be a bit rude to post them here, so I try to ask the question in a different way: what is the order in which the functions are called when there is a MIDI note on message at the MIDI in of the box (because this should be what triggers the LEDs ultimately, right?)? By knowing this, I could check if some relevant function or setting has been deleted/modified in comparison to the original Midibox64e application.
Thanks so much for your help, ilmenator
MIDI parsing starts at “MB64E_MIDI_Scan” in mb64_midi.inc, But I think, that this is the answer for which you are searching for: in mb64e_leds.inc, you will find the function “MB64E_LED_Update_InitLoop”, which contains the lookup table that branches to the appr. init routines depending on the LED MAP value. You could swap the “rgoto” statements.
Or another possibility: if you are doing edits on the mb64_presets.inc file anyhow, you could change the mapping there. Search for MB64E_Presets_LED_MAP - each byte contains one nibble of the 8bit map value, with “db 0x01, 0x00” you will select the first SR, with “db 0x01, 0x01” the second, etc
Best Regards, Thorsten.
Thanks,
actually I’m a bit lost with this information.
The mb64e_leds.inc files are identical in the original version and in mine. In mb64e_presets.inc, there are some minor differences which are attributed to the fact that I have motorfaders
MB64E_Presets_OffsetEncsRge4
ENCODER_ENTRY 0xb0, 0x15, 0x00, 0x64 ; motorfader 1
ENCODER_ENTRY 0xb0, 0x16, 0x00, 0x64 ; motorfader 2
ENCODER_ENTRY 0xb0, 0x17, 0x00, 0x64 ; motorfader 3
ENCODER_ENTRY 0xb0, 0x18, 0x00, 0x64 ; motorfader 4
ENCODER_ENTRY 0xb0, 0x19, 0x00, 0x64 ; motorfader 5
ENCODER_ENTRY 0xb0, 0x1a, 0x00, 0x64 ; motorfader 6
ENCODER_ENTRY 0xb0, 0x1b, 0x00, 0x64 ; motorfader 7
ENCODER_ENTRY 0xb0, 0x1c, 0x00, 0x64 ; motorfader 8
ENCODER_ENTRY 0xb8, 0x5e, 0x00, 0x7f
...
and that I want to send different notes, but all on the same MIDI channel:
MB64E_Presets_OffsetButtons
;; DIN/DOUT group 0
BUTTON_ENTRY 0x90, 0x3c, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x3d, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x3e, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x3f, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x40, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x41, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x42, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x43, 0x7f, 0x00
;; DIN/DOUT group 1
BUTTON_ENTRY 0x90, 0x44, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x45, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x46, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x47, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x48, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x49, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x4a, 0x7f, 0x00
BUTTON_ENTRY 0x90, 0x4b, 0x7f, 0x00
I guess that MB64E_Presets_LED_MAP is organized like MB64E_Presets_OffsetButtonValues:
MB64E_Presets_OffsetButtonValues
;; button:
;; 6543 3210
db b'00001111', b'00001111' ; 1st SR
db b'00001111', b'00001111' ; 2nd SR
db b'00001111', b'00001111' ; 3rd SR
db b'00001111', b'00001111' ; 4th SR
db b'00001111', b'00001111' ; 5th SR
db b'00001111', b'00001111' ; 6th SR
db b'00001111', b'00001111' ; 7th SR
db b'00001111', b'00001111' ; 8th SR
...
MB64E_Presets_LED_MAP
db 0x00, 0x00
db 0x00, 0x00
db 0x00, 0x00
db 0x00, 0x00
db 0x00, 0x00
db 0x00, 0x00
db 0x00, 0x00
db 0x00, 0x00
But what does it actually do? When a note on message comes in, say for example [tt]0x90, 0x3c, 0x7f[/tt], what happens in MB64E_Presets_LED_MAP? How would I have to tweak it so that the first LED in SR#1 lights up?
Thanks, ilmenator
…you have to write “db 0x01, 0x00” into the first line of …_LED_MAP
This means, that the events of the first 8 Button events are mapped to the DOUT register, which is selected with DEFAULT_DOUT_SR_PIN_01_08 (see main.asm)
If you want to control DOUT SR#1 instead of SR#5 (which is the default value), you have to change the settings in main.asm — LEDrings must be disabled, the SR numbers of DEFAULT_DOUT_SR_PIN_* needs to be modified
Best Regards, Thorsten.
Okay,
now I understand.
Actually, I am afraid the error is somewhere else.
I have changed main.asm like this:
#define DEFAULT_DOUT_SR_PIN_01_08 1
#define DEFAULT_DOUT_SR_PIN_09_16 2
#define DEFAULT_DOUT_SR_PIN_17_24 0
#define DEFAULT_DOUT_SR_PIN_25_32 0
...
and this
#define LEDRINGS_SR_ENC1_16_CATHODES_1 0 ; first shift register with cathodes of the first 16 LED rings
#define LEDRINGS_SR_ENC1_16_CATHODES_2 0 ; second shift register with cathodes of the first 16 LED rings
#define LEDRINGS_SR_ENC1_16_ANODES_1 0 ; first shift register with anodes of the first 16 LED rings
#define LEDRINGS_SR_ENC1_16_ANODES_2 0 ; second shift register with anodes of the first 16 LED rings
...
and I still get no LEDs on.
Is this a hardware fault? I don’t think so, because with another application all LEDs work.
Now, I compiled the setup_midibox_mf.asm example from the midibox64e_v2_2 application, and I have some strange behaviour even after changing the main parameters in .asm and .inc: I get the screen like i am supposed to after startup, but after 16x cursor blinking, the display gets kind of mad and in the upper line I see blocks which vary according to the fader position, in the lower line I see 0 or * depending on the state of the button. But the display is “blinking” very fast. All LEDs are on permanently… so they do work.
I am kind of lost here. I’m afraid that there is some portion of the code missing that should be there - which of the .inc files are relevant for toggling the LEDs in the way I would like to?
Regards, ilmenator
I know that it is no software error, so it can only be a configuration error. Or maybe you overwrote something important during your modifications? Did you change the mapping in main.asm or setup_*.asm? (if you are using a setup_* file, you need to do the change there!)
Or the upload was not successfull? (are you using MIOS Studio?)
My suggestion: download the application from my website again, do only the modifications which are required, and upload the new .hex with MIOS Studio
Best Regards, Thorsten.
P.S.: as mentioned above, mb64e_leds.inc controls the LEDs…
Thanks,
I’m getting closer. This time I only changed the setup_midibox_mf.asm. The result is, that the LCD behaviour is still as described, but the LEDs are not permanently on, but only when the button is pressed down. On release the LED goes off again.
As always, I used MIOS Studio, it is a very nice tool! During MIDI upload, the LCD is ‘‘normal’’ again.
I will dive again into this tomorrow - have to get up early :-.
Thanks a lot, ilmenator
Ok, the LEDs are controlable via button, now you can change the LED map (either with Serge’s editor, with the mk_syx tool, or by hand in mb64e_presets.inc)
LCD issues: did you take the golden AUAIMBCTC rule into account?
-> http://www.ucapps.de/mbhp/auaimbctc.pdf
Best Regards, Thorsten.
Hi there,
thank you for your input, actually the LEDs are controllable now, for the standard midibox64e_v2_2 app with the setup_midibox_mf my hardware receives the commands correctly. Now I only need to find the differences in the software that I have to deal with ;D !
The AUAIMBCTC rule (btw, what does THAT mean ???) is taken into account, yes. Of the eight possible faders, only four are connected (directly to J5), and the last 4 pins are grounded. Anything else I could check??
Thanks a LOT for your help! Regards, ilmenator
AUAIMBCTC
All unused analog inputs must be connected to ground (the last C is a writing error 
Other possible errors: a bad connection to the DINs, jittering analog values (improve wiring to the faders), or just a unwanted MIDI loopback with your host application (are you using the internal merger?)
Best Regards, Thorsten.
I still get this strange LCD behaviour. Strange enough, the display is okay for the first few seconds. To be more specific, the display cursor is blinking exactly 16 times, then the display starts to show 16 blocks in the upper row and 16 circles in the lower row. From that moment on the display starts to blink very fast…
There are 4 DIN modules connected to the core. On the first, SR#1 is used for the touch sensors of the faders. The third and the fourth DIN module are planned for encoders, which are currently not connected. I tried to set the number of encoders to zero by using the
#define DEFAULT_NUMBER_ENCS 0
statement in setup_midibox_mf.asm. But whenever the number is smaller than one the application does not start - I only get the sysex message [tt]F0 00 00 7E 40 00 01 F7[/tt] from the core, nothing else happens. How am I supposed to set the number of encoders present to zero? ************************************************* And I was not able to solve the other problem (toggling LEDs with MIDI note on/off messages), which is rather more important to me now - I don’t think they are related. To sum it up: toggling works in your [tt]midibox64e_v2_2[/tt] application, but not in mine. The
#define DEFAULT_DIN_SR_PIN_x
as well as
#define DEFAULT_DOUT_SR_PIN_
statements in [tt]setup_midibox_mf.asm[/tt] and [tt]main.asm[/tt] respectively are the same. The [tt]mb64e_leds.inc[/tt] files are identical for both. [tt]mb64e_presets.inc[/tt] is almost identical, except for a portion at the end of my file, which does not exist in yours:
org 0x07400 ; enc strings
MB64E_Presets_FLASH_Upper
MB64E_Presets_OffsetLabels
#define ENC_LABEL_MODE_HEX 0x40
#define ENC_LABEL_MODE_PM_HEX 0x41
#define ENC_LABEL_MODE_DEC 0x42
#define ENC_LABEL_MODE_PM_DEC 0x43
#define ENC_LABEL_MODE_HEX_B 0x60
#define ENC_LABEL_MODE_PM_HEX_B 0x61
#define ENC_LABEL_MODE_DEC_B 0x62
#define ENC_LABEL_MODE_PM_DEC_B 0x63
;; <---------------> mode
ENC_LABEL_ENTRY "Volume # 1 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume # 2 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume # 3 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume # 4 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume # 5 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume # 6 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume # 7 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume # 8 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume # 9 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume #10 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume #11 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume #12 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume #13 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume #14 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume #15 ", ENC_LABEL_MODE_DEC_B
ENC_LABEL_ENTRY "Volume #16 ", ENC_LABEL_MODE_DEC_B
...
I don’t think this actually matters, or does it? [tt]mb64e_midi.inc[/tt] is the second last file that has differences: while in the original application the [tt]MB64E_MIDI_NotifyReceivedEvent[/tt] looks like
MB64E_MIDI_NotifyReceivedEvent
;; branch to MIDI learn handler if enabled
IFSET MB_STAT, MB_STAT_LEARN_MODE, goto CS_M_LEARN_NotifyReceivedEvent
;; if RECEIVE_PC_FOR_BCHNGE flag is set, check if channel matches and switch bank in this case
SET_BSR MB64E_BASE
BIFCLR MB64E_CFG1, MB64E_CFG1_RECEIVE_PC_FOR_BCHNGE, BANKED, rgoto MB64E_MIDI_NotifyReceivedEventNP
MB64E_MIDI_NotifyReceivedEventPC
;; compare with expected program change for bank changes
movlw 0xc0 | ((DEFAULT_BANK_PRG_CHNG_CHANNEL-1) & 0xf)
xorwf MIOS_PARAMETER1, W
bnz MB64E_MIDI_NotifyReceivedEventNB
;; change bank
movf MIOS_PARAMETER2, W
call MB64E_BANK_Change
MB64E_MIDI_NotifyReceivedEventNB
;; compare with expected program change for patch changes
movlw 0xc0 | ((DEFAULT_PATCH_PRG_CHNG_CHANNEL-1) & 0xf)
xorwf MIOS_PARAMETER1, W
bnz MB64E_MIDI_NotifyReceivedEventNP
;; change patch
movf MIOS_PARAMETER2, W
call MB64E_PATCH_Change
MB64E_MIDI_NotifyReceivedEventNP
MB64E_MIDI_NotifyReceivedEvntNPC
;; branch to MIDI event scanner
rgoto MB64E_MIDI_Scan
in my application it is modified like this:
;; branch to MIDI learn handler if enabled
IFSET MB_STAT, MB_STAT_LEARN_MODE, goto CS_M_LEARN_NotifyReceivedEvent
;; if RECEIVE_PC_FOR_BCHNGE flag is set, check if channel matches and switch bank in this case
SET_BSR MB64E_BASE
BIFCLR MB64E_CFG1, MB64E_CFG1_RECEIVE_PC_FOR_BCHNGE, BANKED, rgoto MB64E_MIDI_NotifyReceivedEventNP
MB64E_MIDI_NotifyReceivedEventPC
;; compare with expected program change
movlw 0xc0 | ((DEFAULT_PROGRAM_CHNG_CHANNEL-1) & 0xf)
xorwf MIOS_PARAMETER1, W
bnz MB64E_MIDI_NotifyReceivedEventNP
;; change bank
movf MIOS_PARAMETER2, W
call MB64E_BANK_Change
MB64E_MIDI_NotifyReceivedEventNP
;; branch to MIDI event scanner
rgoto MB64E_MIDI_Scan
I wouldn’t suspect this change to be of any importance to the toggling LED problem either… The only other file with apparent differences is [tt]mios_tables.inc[/tt]. Mine looks like this:
MIOS_MPROC_EVENT_TABLE
;; entry 0x00-0x0f
MT_ENTRY 0xb0, 0x15 ;; Fader 1
MT_ENTRY 0xb0, 0x16
MT_ENTRY 0xb0, 0x17
MT_ENTRY 0xb0, 0x18
MT_ENTRY 0xb0, 0x19
MT_ENTRY 0xb0, 0x1a
MT_ENTRY 0xb0, 0x1b
MT_ENTRY 0xb0, 0x1c ;; Fader 8
MT_ENTRY 0x90, 0x3c
MT_ENTRY 0x90, 0x3d
MT_ENTRY 0x90, 0x3e
MT_ENTRY 0x90, 0x3f ;; Button8
MT_ENTRY 0x90, 0x40 ;; Button 1
MT_ENTRY 0x90, 0x41
MT_ENTRY 0x90, 0x42
MT_ENTRY 0x90, 0x43
;; entry 0x10-0x1f
MT_ENTRY 0x90, 0x44 ;; Button 9
MT_ENTRY 0x90, 0x45
MT_ENTRY 0x90, 0x46
MT_ENTRY 0x90, 0x47 ;; Button 12
MT_EOT ;; the last two buttons dont have LEDs!
MT_EOT
MT_EOT
MT_EOT
MT_EOT
MT_EOT
MT_EOT
MT_EOT
MT_EOT
MT_EOT
MT_EOT
MT_EOT
...
Also here I think there is nothing wrong!??
Actually, I am really out of clues… I compared the include files a number of times using a file compare tool, so I am rather sure that there are no differences. Is there anything else I should check? Any other functions which are involved in the process of toggling LEDs via MIDI note on/off messages? ???
Thanks, ilmenator
Yes, the app cannot handle with “DEFAULT_NUMBER_ENCS 0”, so this number must be greater than 0
I don’t understand, why you want to stick to an older version. I’ve no idea what could be wrong there, I don’t think that the changes you are showing me in the posting could cause the problem, but in general it would be less effort just to use the latest and greatest version.
If you want to find out, which changes have been made in the configuration, just compare your files against the original files of the older release - it’s still on the server.
In order to solve the “strange LCD behaviour” issue, I would propose to upload a test application like “ain64_din128_dout128_v2_0” - check if any digital or analog input delivers unstable signals (e.g., maybe the touch sensors?)
Best Regards, Thorsten.
Thanks Thorsten,
at least your answer shows me that there doesn’t seem to be any trivial solution which I am too dumb to see…
Why I stick to the version that I have?
Well, I use the Midibox for doing so-called “audio-visual subjective assessments” - the box serves as an input device for test subjects to enter their ratings when judging the quality of audio-visual (MPEG-4) scenes. That means that I need to show some messages on the display during these tests, and the functionality to do this is already implemented in the version that I have. I figured it would be easier to make my version toggle the LEDs than to make the official, latest and greatest version deal correctly with the sysex strings I transmit containing these messages.
Another point is that my version needs to modify the fader values, so the range is not 0-127 but 0-100. This is due to the fact that I need to offer such a scale for the rating - it is rather hard for test subjects to give exact ratings on a scale from 0-127… On the other hand, of course I want to use the whole fader track, so the upmost position is equal to 100. Again, I thought it was easier to make my version toggle the LEDs than implementing this functionality in the latest one.
The design of the Midibox as I have it now was a student’s project work, that’s why I am not completely familiar with the details. The code he modified is rather poorly documented, that is why I cannot easily adapt his changes to the newer version of Midibox64e.
This is an image of the box that I use for the assessments. Here it is configured for a so-called ‘‘Multi-Stimulus Test’’, hence test subjects have four faders to rate and compare four test items.
I guess I will need some more time to decide which way to go now. Thanks for your support.
Best regards, ilmenator
PS: I tried the ain64_din128_dout128_v2_0 application, and everything works as it is supposed to - I am just not sure whether the touch controls of the motorfaders actually are supposed to trigger the DINs. The Display does not say so. But even when touching the SR pins directly, the display does not show any action. Is this correct? They are connected like shown here: http://www.ucapps.de/mbhp/mbhp_din_touchsensors.pdf
Seems that you made the same experiences with students like me In the meantime, the students which I support have to program in C instead of assembly language, it turned out that the results are better re-usable in future projects, also the quality is better.
It’s very similar with the MB64E application - the focus was to get as much features as possible into a single app, and not to allow easy adaptions. The time it takes for me to describe how to change certain things, or how certain mechanisms have been implemented, is so extremely high, that I cannot really help here.
Especially if the code has already been modified - there could either be a resource conflict (which happens very often when more than one person works on a bad documented assembler project), or something important has been removed or changed (unintentionally)
On the other hand: when I read, which features are required for your (interesting) device, then I would say, that this can be written within one hour by using the MIOS C wrapper. There are some existing examples, which help:
Button handling: see http://www.ucapps.de/mios_c_send_din.html
LED handling: see http://www.ucapps.de/mios_c_set_dout.html
LCD handling: see http://www.ucapps.de/mios_c_lcd_out.html
Scaling (0-100) is described here: http://www.ucapps.de/mios_c_send_range.html
The motorfader handling is similar to this example: http://www.ucapps.de/mios_c_send_ain.html
I could create a new one especially for motorfaders if required
I tried the ain64_din128_dout128_v2_0 application, and everything works as it is supposed to - I am just not sure whether the touch controls of the motorfaders actually are supposed to trigger the DINs. The Display does not say so. But even when touching the SR pins directly, the display does not show any action. Is this correct?
Not really, in the ain64_din128_dout128_v2_0 application, a touch sensor should behave like a button (it should send Note On/Off events).
But I just have noticed, that the touch sensitivity is set to 0 by default (see main.h). This wasn’t a good idea, because this value disables the touch sensor pulse at J14. I will set it to 3 next time…
Best Regards, Thorsten.
Thanks for encouraging me to go the C way 
I have already peeked around the C Interface pages, and I will download the compiler suite tonight. I am not a C guru (but then, I am not an assembler guru either…), but I will give it a shot. It’s a pity I will not be able to toggle LEDs in the upcoming tests, but I will manage without them - and (hopefully) have a box which does what I need in the near future (and of which I know how it works, which might be more important than instantaneous success - hey, let’s get philosophical here ).
I was shortly thinking about writing my own [tt]USER_MPROC_NotifyFoundEvent[/tt] routine for toggling the LEDs, but it might be a better idea to do it from scratch in C.
Of course I would love to see a motorfader handling example in C - and I can imagine that I am not alone. The learning curve will be steep enough even with such an example provided…
With the touch sensitivity set to 3, touching the faders actually triggers the DINs.
Thanks a lot, ilmenator
I was shortly thinking about writing my own USER_MPROC_NotifyFoundEvent routine for toggling the LEDs, but it might be a better idea to do it from scratch in C.
I also think that this is the better way, because it will allow you to customize the app completely 
Please don’t forget to update your box to MIOS V1.8, otherwise the C application could crash
Of course I would love to see a motorfader handling example in C - and I can imagine that I am not alone. The learning curve will be steep enough even with such an example provided…
ok, you will find it here http://www.ucapps.de/mios_c_handle_mf.html
Sooner or later I will also add an example for accessing two LCDs
Best Regards, Thorsten.
This is sooo cool 8) !
Within virtually zero time I had the buttons, the faders (almost) and the LEDs doing what I wanted them to do. Now I still need to see for the fader value scaling and the customization of the LCD info displayed during the tests… Thanks!
Best regards, ilmenator