TK.

Hi Titan, years before I used the CNY17-II which is also an optocoupler without darlington stage. Unfortunately it didn't work with all MIDI interfaces, therefore I switched to 6N138. Maybe the optocoupler is too slow, or - and this would be good news for you - R6 (1.2k) isn't ideal. Just try different values from 220 Ohm to 10k. If you don't have them in house, consider that resistors can be chained or wired in parallel to vary the resistance. Best Regards, Thorsten.

Hi Jul, thats because of a memory issue. It will work again once I find the time to implement an alternative way to store large text arrays. I'm planning to do this in an additional, external bankstick. This will have the advantage that even more text messages can be saved which will improve the user interface. Best Regards, Thorsten.

Hi Marcel, I found a lot of marketing paroles, but a detailed description about the functions and the user interface is unfortunately missing. I definitely need them to estimate which features can also flew into the MIDIbox SEQ :-) It will be difficult to combine a Zyklus-like processing engine with the MBSEQ engine, since I guess that the data handling is very different . E.g., the way how the MBSEQ stores and morphs arpeggio textures is unique today and gives its very own results - I don't want to remove such concepts which have been optimized in the last years... Therefore it will possibly result into an alternative application for the MIDIbox SEQ hardware (good news for MIDIbox SEQ users: it will be possible to switch between the two sequencers within 10 seconds by uploading the appr. .syx file), so that no existing feature get lost. But before I have to get an exact image about how Zyklus is working. So, keep me informed :) Best Regards, Thorsten.

Hi, SDCC has a special "pic16" module, and pic16 means "16 bit architecture" here - thats the PIC18F family However, rumors told me that there will be some improvements in the future which will allow to interact with MIOS without big performance loss. Best Regards, Thorsten.

Thanks Jim! Nice to hear that programming MIOS makes fun :) Some words to USER_Timer: this is an interrupt service routine, which means that it breaks your main program. Therefore you've to take care that the LCD driver doesn't use the same resources (data registers, IO ports) like the routines which are called from USER_Tick or similar. This would be the case if a BankStick is connected, or an extension like the AOUT module (connected to J10) Another problem is, that an "ISR" has to be processed within ca. 300-600 uS, otherwise it could happen that an incoming MIDI byte gets lost (the MIDI In driver cannot interrupt another ISR). Therefore I would suggest to use the timer only for setting a flag which requests a display update. The display output itself can still be handled from the USER_DISPLAY_Tick hook. Best solution: SM_Notify_Toggle sets DISPLAY_UPDATE_REQ,0 (bit #0) on a button change USER_Timer: sets bit #1 if bit #0 is set and thereafter clears bit #0 USER_DISPLAY_Tick: prints the button message if bit #1 set and thereafter clears bit #1 An additional possibility to minimize the latency would be the print only a small number of characters (all others which never change could be print from USER_DISPLAY_Init) Best Regards, Thorsten.

No, J6 is an output port, so no problem. Which Events are send exactly? Channel 6 would mean that something is wrong with the 6th pot of a 16-pot row (assumed that you're running the MIDIbox with the default setup). It's very easy to determine which pots are affected. The first row sends reverb by default, the second chorus depth, the third cutoff, the fourth volume. Best Regards, Thorsten.

Steinberg Houston has a lot of imperfections (see http://www.triac.freeserve.co.uk/houston/), so why not throwing out the electronic parts and replacing it by MBHP modules? ;-) Best Regards, Thorsten.

Yes, with the MIDImon it should work anyhow, but please note that the MIDIbox SEQ doesn't work with MTC, but with the common MIDI clock, and nothing is better than to derive the informations directly from the internal parameters, no? ;-) So, an additional LED digit display for the song position is possible in this format: SSS.PP where SSS stands for the song position (1-256) and PP for the position of the current selected track (note that each track has it's own position counter). Alternatively you could use a single digit for quarter-note. BPM: 3 additional digits, but definitely only possible for master mode. For slave mode you would have to use the midimon (which derives the BPM from the received clock ticks - integration into MIDIbox SEQ is not possible) I've added these functions to the ToDo list - low priority, because from my impression it's not really useful, but just only a cosmetic feature. Best Regards, Thorsten.

Triggered from the midiboxchat today I evalued the SDCC, an open source C compiler which is available under http://sdcc.sourceforge.net. I programmed a so called "wrapper" which maps some of the MIOS functions to the C world, so that they are accessible as common C functions: extern void MIOS_LCD_Clear(void); extern void MIOS_LCD_CursorSet(char pos); extern void MIOS_LCD_PrintChar(char c); extern void MIOS_LCD_PrintString(char *str); extern void MIOS_LCD_PrintPreconfString(char *str); Two MIOS hooks directly branched to the C program: USER_Init extern _CMIOS_Init goto _CMIOS_Init USER_DISPLAY_Init extern _CMIOS_DISPLAY_Init goto _CMIOS_DISPLAY_Init so that following C code was possible: void CMIOS_Init(void) { } void CMIOS_DISPLAY_Init(void) { MIOS_LCD_Clear(); MIOS_LCD_CursorSet(0x00); MIOS_LCD_PrintChar('1'); MIOS_LCD_PrintChar('2'); MIOS_LCD_PrintChar('3'); } This was working and the resulting assembler code looked exactly like I would program it in assembler. Then I tried to output a string: static char[] = {12, 0x00, "Hello World!"} void CMIOS_DISPLAY_Init(void) { MIOS_LCD_Clear(); MIOS_LCD_PrintString(hello_world); } But the static string above produced a table with following entries _hello_world db 0x0c, 0x00, 0xa8 It seems that the compiler feels confused about a mix of constant values and characters Next try: void CMIOS_DISPLAY_Init(void) { MIOS_LCD_Clear(); MIOS_LCD_CursorSet(0x00); MIOS_LCD_PrintPreconfString("Hello World!"); } but no luck: the compiler crashed with a signal error - bad, it seems that the PIC18F module hasn't been programmed properly enough. Last try: void CMIOS_DISPLAY_Init(void) { int i; MIOS_LCD_Clear(); MIOS_LCD_CursorSet(0x00); for(i=0; i<3; ++i) { MIOS_LCD_PrintChar('A' + xx); } } This produced so much assembler code that it was definitely clear to me that SDCC is the wrong way to program a powerfull application: ;#LINE 7; main.c void CMIOS_DISPLAY_Init(void) MOVFF FSR2L, POSTDEC1 MOVFF FSR1L, FSR2L MOVFF r0x10, POSTDEC1 MOVFF r0x11, POSTDEC1 ;#LINE 11; main.c MIOS_LCD_Clear(); CALL _MIOS_LCD_Clear ;#LINE 12; main.c MIOS_LCD_CursorSet(0x00); MOVLW 0x00 CALL _MIOS_LCD_CursorSet ;#LINE 14; main.c for(i=0; i<3; ++i) CLRF r0x10 _00109_DS_: MOVLW 0x03 SUBWF r0x10, W BTFSC STATUS,0 GOTO _00113_DS_ ;#LINE 16; main.c MIOS_LCD_PrintChar('A' + i); MOVLW 0x41 ADDWF r0x10, W MOVWF r0x11 MOVF r0x11, W CALL _MIOS_LCD_PrintChar ;#LINE 14; main.c for(i=0; i<3; ++i) INCF r0x10, F GOTO _00109_DS_ _00113_DS_: MOVFF PREINC1, r0x11 MOVFF PREINC1, r0x10 ;;genEndFunction: _G.nRegsSaved upon exit from function: 0 MOVFF PREINC1, FSR2L RETURN Just to compare it with handwritten assembler code: _CMIOS_DISPLAY_Init: ;; stack handling excluded here call MIOS_LCD_Clear movlw 0x00 call MIOS_LCD_CursorSet clrf r0x10 _CMIOS_DISPLAY_Init_Loop: movlw 0x41 addwf rx010, W call MIOS_LCD_PrintChar incf rx010, F movlw 0x03-1 cpfsgt rx010 bra _CMIOS_DISPLAY_Init_Loop ;; stack handling excluded here return Conclusion: the SDCC crashes sometimes and will therefore be hard to use for people who just want to write some lines of code without knowing about those quirks the code optimization is far from perfection, it seems that the compiler doesn't know about all those nice new PIC18F instructions which help to make the code shorter the compiler produces too much code, therefore the applications cannot include so much features anymore the compiler allocates all three pointers (FSR0-FSR2), therefore some code changes will be required in MIOS which will slow down the system (especially on interrupts) who knows which problems I haven't seen yet... I'm not sure if currently the C approach is worth the effort... Best Regards, Thorsten.

Hi Robin, don't give up! I know that it isn't so easy to understand the implementation since the code is very compact and spreaded over different files. For MIDIbox SEQ it wasn't my intention to write a simple example, but to bring as much as possible features into the endproduct. Would you like to write a review about these books in the MIDIbox Wiki? (http://wiki.midibox.org) - I think that for other people it could be helpful to know if these books give enough informations to work on MIOS applications. You are right, the table is called "SEQ_IO_TABLE_DIN" and located in "mios_tables.inc" - I will correct this comment in the next release. The equation at the right side creates a constant ("literal") value. exactly! The first 3 bits are addressing the pins of the shift register correct. "GP" means "general purpose" buttons, they have different functions depending on the menu which is currently active. Most code of the GP buttons/LEDs can be found in seq_gp.inc and in various cs_m_*.inc files GP is possibly not so interesting for your use case. Especially interesting could be the track and the layer buttons, since these are very special "radio buttons". Description about the behaviour: Best Regards, Thorsten.

Hi Chriss, it shouldn't be a big problem to integrate the driver also into the MB64E application. I will take this into account for the next release. Other planned features for MB64 and MB64E: support for two 2x40 LCDs and an alternative option which saves 128 snapshots into a single BankStick instead of 16 (8) complete setups. This will be especially useful for saving sound patches of a single synthesizer Best Regards, Thorsten.

Hi Dragon, yes, you are right, thats a compatibility issue (I didn't know about that...) - it will work when you copy the files from the mios_v1_7/migration directory into the MIDIbox TC directory and rebuild the project If this is too complicated, then just wait until the midibox_tc_v1_7 has been uploaded. In the meantime you could try the MIDIbox64E, which is much more powerfull :) Best Regards, Thorsten.

Hi, you must burn the bootstrap loader you must upload MIOS thereafter you can upload the application Everything would be so simple if you just would follow the instructions at http://www.ucapps.de/mios_bootstrap.html... ;-) Best Regards, Thorsten.

Hallo, eigentlich ist alles im Tutorial erklaert (http://www.ucapps.de/midibox64e_tutorial_en.html), siehe unteren Absatz. Es gibt sogar zwei Konfigurationsbeispiele fuer Reaktor - wie man FruityLoops einstellen muss, weiss ich natuerlich nicht. Wenn der Synthi seine Monentanwerte versenden kann, dann wird die MB64E die "virtuellen Potipositionen" dementsprechend aktualisieren. Dadurch werden Parameterspruenge vermieden. Eine bitte: wenn Du es geschaft hast, FL richtig zu konfigurieren, dann trage Deine Erkenntnisse bitte in das Wiki ein (http://wiki.midibox.org -> HowTo configure a Hostapplication for MIDIbox), damit es andere Leute einfacher haben. Du bist ja nicht der erste, der mit FL arbeitet, aber solange sich niemand die Zeit nimmt, die Konfiguration zu beschrieben, wird diese Frage immer wieder gestellt. Tue es mir zuliebe! ;-) Gruss, Thorsten.

You could also program a Meta event which just switches the bank directly, e.g.: movf MIDI_EVNT_VALUE, W bz MB64_META_10_ButtonDepressed decf MIDI_EVNT_VALUE, W call MB64_BANK_Change MB64_META_10_ButtonDepressed return switches to the bank which is specified in the 3rd byte of the button event (01-7F) Best Regards, Thorsten.

Sorry, I've no idea why this shouldn't work :-/ Anybody else? Best Regards, Thorsten.

Hi, the first "goto" will be overwritten by the first-level bootstrap loader, so that the PIC branches to 0x7c00 after reset. If this bootstrap loader doesn't get a SysEx command within 2 seconds, it will branch to 0x0004 (the second goto) Best Regards, Thorsten.

Hi, replace 0xb0 by 0xb1 for channel 1, 0xb2 for channel 2, ... 0xbf for channel 16 You could also specify the channel with the Meta Event, e.g. if you replace "movlw 0xb0" by "movf MIDI_EVNT_VALUE, W", "andlw 0x0f", "iorlw 0xb0" the specified button value (should be within 00 and 0F) will be added Best Regards, Thorsten.

Hi Jim, if the branch to MIDI_EVNT_Send is at the end of your function, the you should either use the "goto", or a "call" (like now) and thereafter a return. Don't forget the return or goto, otherwise undefined code (or the function below) could be executed at the end To the MIDI_EVNT0 problem: I noticed that the eight bit of the first byte is always masked out in the MIDIO_OUT_ENTRY macro (...(event_on_0)&0x7f...). This has some special reasons, but they don't matter in your case. You've two possibilities: 1) change the macro: MIDIO_OUT_ENTRY MACRO event_on_0, event_on_1, event_on_2, event_off_0, event_off_1, event_off_2 db event_on_0, event_on_1, event_on_2, event_off_0, event_off_1, event_off_2 ENDM 2) or set the eighth bit before this value will be sent out: bsf MIDI_EVNT0, 7 ;; set 8th bit (indicates a status byte) The reason why sm_example2 doesn't support the LCD is just that I wanted to achieve the highest performance. A display update on every button change would cost ca. 200-300 uS, it depends on your display and the number of characters... The DISPLAY_UPDATE_REQ flag is just a good method to prevent additional updates if some buttons are pressed at the same time (only the last button change will be visible on screen). There are methods to save performance (e.g. printing out one character only on every display tick), but I wanted to make this example so uncomplicated as possible ;-) You could copy&paste "USER_DISPLAY_Init" and "USER_DISPLAY_Tick" of the sm_example1 for debugging Best Regards, Thorsten.

Hi Robin, if the modules are already built, I would suggest the use of one core only for the 8x8 diode matrix (just use the sm_example2, nothing has to be changed), and the other core for the rest. This has the advantage that the button matrix will be scanned under best conditions (lowest latency). Yes, please update to MIOS V1.7, it always makes sense to use the most recent version (although in this case one hardware change is required: see update info page) Best Regards, Thorsten.

Hi Robin, maybe the button handler of MIDIbox SEQ is a good example, how dependencies between buttons and LEDs can be realized. See seq_buttons.inc and seq_leds.inc Best Regards, Thorsten.

Hi, could you please explain why you are assuming that it doesn't work? You wrote that you haven't connected a display, so maybe you just have misinterpreted the behaviour? Note that this SFB function has to be assigned to the same button(s) in every bank, otherwise you won't be able to switch back or to another bank once a bank without this SFB has been selected. Best Regards, Thorsten.

Hi, if MIOS responses on this SysEx request, it's definitely running. So, I guess that you either used the wrong ID in the PIC ID field (it should be 0000000000000000 in your case --- just all zeroes --- use the change_id application if you are not sure), or you must have a wiring/short circuit problem. Best Regards, Thorsten.

To 2: in this case not, the host expects common incremental/decremental events. So, you can use the same rotary encoder like for the V-Pots, but a bigger knob (datawheel) should be prefered Best Regards, Thorsten.

Um die Sache zum Abschluss zu bringen: die Ursache fuer das nicht Funktionierens des MIDI Ports war ein falscher Widerstand: statt mit einem 5.6k Ohm war das Core Modul mit einem 5.6 Ohm Widerstand bestueckt. Dieser niedrige Widerstand hat nicht nur dazu gefuehrt, dass der Arbeitspunkt des Optokopplers zu niedrig eingestellt war, und aus diesem Grund keine MIDI Daten uebermittelt wurden, sondern er hat den 6N138 komplett zerschossen. Im Debug HowTo stehen nun zusaetzliche Hinweise: Gruss, Thorsten.