MB64E removal of menu buttons to get those DINs back

[dengel]

Part 1

Because of this that I saw in the mb64e.ini file:

    # Additional 4 Buttons in the menu section - assigned to special functions
    17  =  FF 08 41  @OnOff   # SFB: select bank/group
    18  =  FF 08 40  @OnOff   # SFB: Select Parameter with encoder when hold
    19  =  FF 08 11  @OnOff   # SFB: Encoder in fast mode when hold
    20  =  FF 08 21  @OnOff   # SFB: Encoder in slow mode when hold

    # Navigation buttons, only available as MIDI triggers when they
    # have been disabled in main.asm
    21  =  90 7C 7F  @OnOff
    22  =  90 7D 7F  @OnOff
    23  =  90 7E 7F  @OnOff
    24  =  90 7F 7F  @OnOff

Below is my Main.asm code that I am using to hopefully eliminate the LCD menu options, since I need those DINs and This box is specially designed for Ableton - there are no shifted options whatsoever; every knob, button, or encoder has just one function, and really the LCD is just there to look cool and display the title of the knob I am turning at the time.

; DIN pin numbers of menu buttons
#if DEFAULT_ENC_DATAWHEEL == 0
  #define DEFAULT_DIN_MENU_EXEC		0	; menu exec button assigned to DIN pin #7
  #define DEFAULT_DIN_MENU_RIGHT	0	; menu right button assigned to DIN pin #6
  #define DEFAULT_DIN_MENU_LEFT		0	; menu left button assigned to DIN pin #5
  #define DEFAULT_DIN_MENU_SNAPSHOT	0	; menu snapshot button assigned to DIN pin #4
#else
  #define DEFAULT_DIN_MENU_EXEC		0	; menu exec button assigned to DIN pin #7
  #define DEFAULT_DIN_MENU_SNAPSHOT	0	; menu snapshot button assigned to DIN pin #4
  #define DEFAULT_DIN_MENU_RIGHT	0	; NOT USED - overlayed by datawheel
  #define DEFAULT_DIN_MENU_LEFT		0	; NOT USED - overlayed by datawheel
#endif

As well as setting these to 0:

; Some menus are providing the possibility to use 16 "general purpose" buttons
; for selecting a parameter - e.g. the Bank Select menu allows to directly change the
; Bank with these buttons. So long as you stay in this menu, the normal function of
; these buttons (triggering MIDI or SFB events) is disabled
; Define the two shift registers which are assigned to this function here:
; 0 disables the GP buttons (not recommented!)
#define DEFAULT_GP_DIN_SR0	0	; first GP DIN shift register assigned to SR#2
#define DEFAULT_GP_DIN_SR1	0	; second GP DIN shift register assigned to SR#3

; above these buttons LEDs should be mounted to visualize the selected parameter
; (e.g. to visualize the bank which corresponds with the buttons below)
; Define the two shift registers which are assigned to this function here:	
; 0 disables the GP LEDs (not recommented!)
#define DEFAULT_GP_DOUT_SR0	0	; first GP DOUT shift register assigned to SR#5
#define DEFAULT_GP_DOUT_SR1	0	; second GP DOUT shift register assigned to SR#6

As well as setting this option to 0, since I KNOW I will have both pots and encs:

; The morphing function uses addresses within the MIOS address range which are 
; reserved for the AIN handler. 
; NOTE: morphing is automatically disabled if analog pots/faders are connected
#define DEFAULT_MORPH_FUNCTION_ENABLED 0

And Finally these settings for AIN and Mux Support:

; Although MIDIbox64E has been designed for rotary encoders, it can also handle with
; up to 64 pots/faders or up to 8 motorfaders.
; Pots and faders are mapped to the "encoder" entries 64-128.
; Example: if group width is 16, and group 1 is selected, encoders are using
; entry 1-16, and pots are using entry 64-70
; NOTE: morphing is automatically disabled if analog pots/faders are connected
#define DEFAULT_NUMBER_AIN		8
;
; you could enable the multiplexers here to test this application
; with a MIDIbox64 based hardware
; if 0: no multiplexers (a *must* when MF module connected)
; if 1: use multiplexers
#define DEFAULT_ENABLE_AIN_MUX		1

Do the settings above make any sense?

PArt 2:

The funny thing is that when you DL the complete MB64 Application, I don't see the ini file in there at all, nor do I see any Sysex setup for it either. I think that what I might have to do is:

1.Take my customized MB64E.ini and create a new sysex file using Perl

2. Rename this Sysex file to "main.syx" and replace main.syx in the install folder

3. Convert my custom main.asm into main.hex using MPASM

4. Upload the Application

Does that sound right?

[TK.]

It's better to set the DEFAULT_DIN_MENU_* values to an invalid pin number >= 128

I don't understand part 2. The midibox64e.ini file is a configuration file, the resulting .syx contains the configuration data which can be sent to the MIDIbox64E firmware. You don't need to rename it, you only need to follow the steps which are described in the readme

The main.syx within the application package is a converted memory image of the application code (old and expired method to upload code, ignore it)

Best Regards, Thorsten.

[dengel]

Thanks, TK. I guess I am trying to figure out why there are so many files in the install directory, when with Mios Studio you just upload a hex file. and that's it. Iinstalled MPASM so that I could create a hex file from an ASM; I guess my biggest problem is that I don't understand how all these parts (the various INC files, ASM, SYSX, and HEX) files come together to make it work. Is it all pulled into a single hex file when you build it from and ASM? It's very confusing for someone whose programing knowledge is all in ASP and .Net. :(

[stryd_one]

It's very confusing for someone whose programing knowledge is all in ASP and .Net. :(

Don't worry, it makes sense after a while. And you'll learn more about your job when you begin to understand what the code beneath your code is doing :D

The ASM, INC, H, C etc files are basically a nice and neat way of separating the code into more easily managed parts. They all get compiled into a hex file, which is ready to be flashed to the PIC. We use a bootloader which requires a SysEx dump, so the hex file is converted to syx.

[dengel]

Oh, good - I figured that it might be similar to using objects in ASP, or SSi's in a web app to seperate code chunks - but since the whole deal is foreign, I couldn't be sure it worked in the same way.

[stryd_one]

One thing I often find causing me problems is that I lack faith in myself and my abilities... Often I *think* I know the answer to a question, so I ask, and find out that I was right all along, and worrying about nothing... Don't make my mistake, Be confident.... But careful! hehehe

[dengel]

Well, Thanks for the kind words. I've built the new Hex using my modified main.asm and mios_tables.inc using MPASM, and uploaded MB64E to the core. I am still frustrated by DINs that power up to 5v all the way through the chain, but at least it appears that the upload worked: instead of the ol' "Reverb" on my LCD I now see Int.1 1|CC# 7 [127]. Still not sure how to name these things so that they say things actually related to my app, but I think I will hold off on that until I build the box, and then work through it by twiddling a knob, seeing what shows up, and then tracking it down in one of the many include files. Then, I'll rebuild again and re-upload.

[stryd_one]

When I want to change something, I find that a real good start is to search the source for whatever I'm seeing and then reverese engineer how the code works. You end up learning lots while you hack... and I guarantee that what you see will have you clicking the paypal link up there :)