TK.

Just to point up that this is no software problem: every MIDIbox SID user who has connected one or more MBSID slaves uses the MIDIbox Link Best Regards, Thorsten.

is this really a question concerning MIOS programming?` However, I think that you've some kind of ground loop in your circuit which provokes the additional jitter. A better power wiring with a central ground point (prevent long chains) can help. You can still work with two PSUs if you want... In thie case don't connect the grounds of J11 connectors together... if this still doesn't help, and you are not able to find the reason, then try it with optocouplers and ensure that there is no ground connection between the boxes. Best Regards, Thorsten.

however, seems that it makes sense to integrate the same AUTO_ID feature like in the MIDIbox SID, because it seems that this seperation (which sometimes makes sense) is too confusing for users Best Regards, Thorsten.

There must still something be wrong with your hardware. As PayC wrote, he noticed similar obscurities with his 24AA256... maybe you should try different cable lengths or so... thats all what I can say to this topic. Have you also tried a "MIOS BankStick 32k" Request and Send with SysExBox? Best Regards, Thorsten.

Zum MIDIfilter: die PIC18F Loesung sieht ganz einfach aus, denn MIOS hat ja alles an Bord. Du benoetigst lediglich das Small Skeleton, und muss dann halt im USER_MPROC_NotifyReceivedEvent Hook den Code zum weiterleiten der MIDI Events reinschreiben. Natuerlich laeuft das dann auch mit einem voll bestueckten Core Modul... es ist halt eine ganz normale MIOS Applikation. Gruss, Thorsten.

yes, but totally unsupported, since it's unfinished and I don't plan to add more into this direction since the implementation is very hardware specific (in other words: I don't want to program individual solutions for you guys which I would never use by myself...) Check the MIDIbox64 SysEx Implementation doc, search for MIDI remote, and think about the possibility to send these sysex commands via meta events... Best Regards, Thorsten.

yes, but totally unsupported, since it's unfinished and I don't plan to add more into this direction since the implementation is very hardware specific (in other words: I don't want to program individual solutions for you guys which I would never use by myself...) Check the MIDIbox64 SysEx Implementation doc, search for MIDI remote, and think about the possibility to send these sysex commands via meta events... Best Regards, Thorsten.

if you've enabled "Send Program Change on Bank Changes", yes At the receiver site "Receive Program Change for Bank Change" should be enabled. no, you can do this change in your .ini file, or with Serge's Editor the diagram above shows a concept which can be used by other programmers if they want to control multiple midiboxes from a single control surface. This is not implemented in MIDIbox64. If you need this, then you have to program this by yourself. Best Regards, Thorsten.

if you've enabled "Send Program Change on Bank Changes", yes At the receiver site "Receive Program Change for Bank Change" should be enabled. no, you can do this change in your .ini file, or with Serge's Editor the diagram above shows a concept which can be used by other programmers if they want to control multiple midiboxes from a single control surface. This is not implemented in MIDIbox64. If you need this, then you have to program this by yourself. Best Regards, Thorsten.

Hi Kapser, in order to disable the menu navigation buttons, you have to modify the numbers behind "#define DEFAULT_DIN_MENU_*" to > 64, e.g. #if DEFAULT_ENC_DATAWHEEL == -1 #define DEFAULT_DIN_MENU_EXEC 64 #define DEFAULT_DIN_MENU_RIGHT 65 #define DEFAULT_DIN_MENU_LEFT 66 #define DEFAULT_DIN_MENU_SNAPSHOT 67 #else For your special functions you need to program some additional code (and it isn't that easy if you haven't worked with PIC assembler yet) Best Regards, Thorsten.

strange. in IFGEQ I would replace W by ACCESS, but this isn't the reason (both constants are 0) You could add following code: movlw 0xf0 ;; for debugging call MIOS_MIDI_TxBufferPut movf MB_BANK, W andlw 0x7f call MIOS_MIDI_TxBufferPut movff MIDI_EVNT_VALUE, WREG andlw 0x7f call MIOS_MIDI_TxBufferPut movlw 0xf7 call MIOS_MIDI_TxBufferPut before the last block, and movlw 0xf0 ;; for debugging call MIOS_MIDI_TxBufferPut movf MB_BANK, W andlw 0x7f call MIOS_MIDI_TxBufferPut movlw 0xf7 call MIOS_MIDI_TxBufferPut before the return for debugging Best Regards, Thorsten.

Hi, very nice solution! It doesn't take care for the LEDs, but if this doesn't matter I think you are happy :) Filtering the shift button - you could add: ;; exit on event from button ID = 0x10 movf MIOS_PARAMETER1, W xorlw 0x10 skpnz return at the beginning of the MB64E_BUTTON_GP function Best Regards, Thorsten.

Hi Wonder, it looks strange, really strange. Following test would be interesting: don't write out the characters on LCD, but send them to the MIDI interface. Write: movlw 0xf0 call MIOS_MIDI_TxBufferPut at the top, replace all calls to MIOS_LCD_PrintChar by MIOS_MIDI_TxBufferPut, and Add: movlw 0xf7 call MIOS_MIDI_TxBufferPut at the end. Start MIDI-Ox and check the SysEx messages which are sent by your core. They should contain exactly the character codes which are in your BankStick. If not, the problem could be your LCD, but just try it first. Sending MIDI messages for debugging is a really useful - I'm doing this very often for logging and analyzing data :) the checksum is missing, therefore the error code The core doesn't hang, but it will be reset after a 02 upload request, thats the normal behaviour. Best Regards, Thorsten.

Hi, finally all applications of Serge are ported to the MIOS versions of MIDIbox64 and MIDIbox64E. The SysEx tool got also some minor updates: http://www.midibox.org/mios_tools/sysexbox_18f_v1_1c.zip http://www.midibox.org/mios_tools/vmidibox64_18f_v1_0b.zip http://www.midibox.org/mios_tools/vmidibox64e_18f_v1_0c.zip Note: there is a known imperfection when requesting a configuration bank from MB64/MB64E - if the merger mode is toggled (e.g. from "Merger On" to "Merger Off"), the MIDI protocol will violated during the download, and vmidibox will report an invalid sysex block.I will fix this in the firmware, so that the protocol won't be violated anymore in this corner case. Best Regards, Thorsten.

I hope so! :-) I must admit that I haven't worked on the C wrapper anymore after the night I wrote it ;-) So your error reports are really welcome :) Currently I'm working on vmidibox64 and vmidibox64e (C++ fun under windows), hope that I will find some time thereafter to finalize the wrapper BestRegards, Thorsten.

When I find the time... Best Regards, Thorsten.

Hi Alex, thats only a small routine in USER_DIN_NotifyToggle is required which forwards the toggle events of your buttons to the MIDI processor of MIDIbox SID. But: are you sure that you've a dedicated line for each button of your piano, or are the buttons organiced in a matrix? Best Regards, Thorsten.

Hi Pilo, thanks for the input. I cannot explain while your variant should work better (since MIOS_PARAMETER1 is overwritten), but I will try this out with my MBLC hardware and bring the fixed code into the first official release. Best Regards, Thorsten.

Hi, the current implementations of MB64/MB64E/MBMF are doing exactly for what you are searching for: each bank contains the whole setup, so not only the "snapshot" of all knob/button values, but also the MIDI events, pot names, pot/button modes, etc... This means that each BankStick can save 16 (MB64) or 8 (MB64E/MBMF) complete setups An option for the next release is planned which saves the whole setup only once, and which uses the rest of the BankStick to store 128 snapshots. But this will only be an option which will be disabled by default (so, don't worry ;-)) Best Regards, Thorsten.

Hallo Oli, nein, programmiertechnisch kann man da leider nichts tun. Die 10k linear sind pflicht, ansonsten kann der Analog-Digital-Umsetzer des PICs die Potiposition nicht sauber erkennen. Werte <10k bis zu 1k sind erlaubt, werte >10k nicht. Gruss, Thorsten.

Hi Robin, for MIOS a BankStick is just a data storage, it doesn't take care for the data which is saved in the EEPROM. Therefore MIOS cannot tell you if you've 32 extra banks or not, it can only tell you if the second and third BankStick is accessible or not. The easiest way to do this is to request the BankStick content of BankStick #2 and #3 with the SysExBox tool. If MIOS transmit 32 blocks, the BankSticks are connected correctly, if MIOS returns an error code, then check your circuit. For the MIDIbox64 application each BankStick contains 16 banks. This application is programmed in a way that you don't need to select the BankStick, you only need to select bank 17-32 for BankStick #2, 33-48 for BankStick #3, etc... This means also that you are already able to copy data between multiple BankSticks Best Regards, Thorsten.

I've tested the software with the same interface (latest m-audio drivers) a MIOS program/EEPROM/BankStick download request always reboots the MIDIbox after all blocks have been sent. The reboot is required, since the data encoding algorithm needs some memory which is normaly reserved for the application. You are writing that this happens after some time. This indicates that all blocks are sent (32k BankStick e.g. 32 blocks) The midisport 2x2 is a multiclient capable interface, this means that you can open sysexbox and midi-ox at the same time. Please do this and check if MIDI-Ox receives all the blocks. Are you using the v1.0c release of sysexbox? Older versions used a smaller MIDI In buffer which can cause problems (seems that this depends on the Windows version...) Best Regards, Thorsten.

it's absolutely isolated from MIOS as well as from the application, and especially doesn't execute any other code which could be changed during the upload --- this would be fatal! Best Regards, Thorsten.

P.S.: if you don't mean the MIOS BankStick Request, but the MIDIbox64E Bank Request: no, there is no perl script for this, but vmidibox64e will get the same SysEx transfer functions, and this appliation already supports the possibility to export a .ini file Best Regards, Thorsten.

yes, because MIOS is so intelligent that it only erases/reprograms flash and EEPROM pages which have been changed. If there are only a small number of changes, the procedure runs through much faster. nice to hear :) which MIDI interface are you using? it would be interesting if other people notice the same problems. thats strange, because it's the same type of data... (also the data block size is the same) yes, you can do this with the syx2asm.pl script, which can be found in the tools/ directory of the MIOS package. Best Regards, Thorsten.