TK.

I haven't started with this yet, and won't find the time in the next two months, so you have my go Best Regards, Thorsten.

///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a pot has been moved ///////////////////////////////////////////////////////////////////////////// void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) { if( pin == 1 ) // J5.A1 { // send CC event for Joystick X axis MIOS_MIDI_TxBufferPut(0xb0); MIOS_MIDI_TxBufferPut(0x10); MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); return; } if( pin == 2 ) // J5.A2 { // send CC event for Joystick Y axis MIOS_MIDI_TxBufferPut(0xb0); MIOS_MIDI_TxBufferPut(0x11); MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); return; } // else continue with motorfader handling ... // ... // ... // ... } does it look less complicated or not? If yes: then it makes sense to wait for the MIOS C wrapper release... ;-) Best Regards, Thorsten.

Here a first insight into a C programming example: #include "cmios.h" //#include <pic18f452.h> ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS after startup to initialize the // application ///////////////////////////////////////////////////////////////////////////// void Init(void) { // define number of shift registers MIOS_SRIO_NumberSet(16); // update frequency of SRIO chain MIOS_SRIO_UpdateFrqSet(1); // ms } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS in the mainloop when nothing else is to do ///////////////////////////////////////////////////////////////////////////// void Tick(void) { } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when the display content should be // initialized. Thats the case during startup and after a temporary message // has been printed on the screen ///////////////////////////////////////////////////////////////////////////// void DISPLAY_Init(void) { // clear screen MIOS_LCD_Clear(); // print message MIOS_LCD_CursorSet(0x00); MIOS_LCD_PrintCString("Press Button"); } ///////////////////////////////////////////////////////////////////////////// // This function is called in the mainloop when no temporary message is shown // on screen. Print the realtime messages here ///////////////////////////////////////////////////////////////////////////// void DISPLAY_Tick(void) { } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a complete MIDI event has been received ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyReceivedEvnt(unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) { // print received MIDI event MIOS_LCD_Clear(); MIOS_LCD_PrintCString("Received:"); MIOS_LCD_CursorSet(0x40); MIOS_LCD_PrintHex2(evnt0); MIOS_LCD_PrintHex2(evnt1); MIOS_LCD_PrintHex2(evnt2); } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a MIDI event has been received // which has been specified in the MIOS_MPROC_EVENT_TABLE ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyFoundEvent(unsigned entry, unsigned char evnt0, unsigned char evnt1, unsigned char envt2) { } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a MIDI event has not been completly // received within 2 seconds ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyTimeout(void) { } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a MIDI byte has been received ///////////////////////////////////////////////////////////////////////////// void MPROC_NotifyReceivedByte(unsigned char byte) { } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when an button has been toggled // pin_value is 1 when button released, and 0 when button pressed ///////////////////////////////////////////////////////////////////////////// void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) { MIOS_LCD_Clear(); MIOS_LCD_PrintCString("DIN #"); MIOS_LCD_PrintBCD3(pin); MIOS_LCD_PrintCString(pin_value ? " off" : " on"); MIOS_LCD_CursorSet(0x40); switch( pin ) { case 0: MIOS_LCD_PrintCString("Sending a Note"); MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(pin); MIOS_MIDI_TxBufferPut(pin_value ? 0x00 : 0x7f); break; case 1: MIOS_LCD_PrintCString("Sending a CC"); MIOS_MIDI_TxBufferPut(0xb0); MIOS_MIDI_TxBufferPut(pin); MIOS_MIDI_TxBufferPut(pin_value ? 0x00 : 0x7f); break; case 2: MIOS_LCD_PrintCString("Sending SysEx"); MIOS_MIDI_TxBufferPut(0xf0); MIOS_MIDI_TxBufferPut(0x11); MIOS_MIDI_TxBufferPut(0x22); MIOS_MIDI_TxBufferPut(0x33); MIOS_MIDI_TxBufferPut(0x44); MIOS_MIDI_TxBufferPut(pin); MIOS_MIDI_TxBufferPut(pin_value ? 0x00 : 0x7f); MIOS_MIDI_TxBufferPut(0xf7); break; default: MIOS_LCD_PrintCString("No action"); } } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when an encoder has been moved // incrementer is positive when encoder has been turned clockwise, else // it is negative ///////////////////////////////////////////////////////////////////////////// void ENC_NotifyChange(unsigned char encoder, unsigned char incrementer) { } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a pot has been moved ///////////////////////////////////////////////////////////////////////////// void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) { } all MIOS functions are now accessible from C I've written a small script which builds workarounds into the generated assembler code. Some of them will be part of the next SDCC release. If anybody wants to beta-test the MIOS wrapper, just write me an email. Best Regards, Thorsten.

Hi Dan, sure, the USER_AIN_NotifyChange hook can be found in lc_mf.inc Although "_mf.inc" implies that this file is intented for motorfaders only, this does not mean that you wouldn't be able to react on any other analog control element from there. Best Regards, Thorsten.

Hallo, ja, sogar eine sehr effiziente. Du kannst Dir das http://www.ucapps.de/midibox/mk_syx.zip Script herunterladen, die midibox64.ini Datei im pic18f Verzeichnis nach Deinen wuenschen anpassen, und dann mit "perl mk_syx.pl midibox64.ini" ein neues Konfigurationsfile bauen. Unter "Pot Row 4" stehen bereits die MIDI Events fuer Volume auf Kanal 1-16. Sie sind momentan den Potis 49-64 zugewiesen. Aendere die Potinummern auf 1-16, und die der bisherigen auf 49-64 (jedes Poti darf nur einmal auftauchen) Gruss, Thorsten.

Good news: I'm in contact with Vangelis, the developer of the PIC16 SDCC module. Maybe we will find a good solution to improve the interaction with MIOS, and to optimize the assembler output :) Best Regards, Thorsten.

Hi Pearl, the encoder just only has to send PitchBender events at Channel 9 Best Regards, Thorsten.

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.