TK.

Looks good Best Regards, Thorsten.

It's strange that Windows asks you to reboot the PC, this never happened at my side with USB MIDI devices (regardless if GM5 or my own USB projects are used). But I must also say, that I typically test the devices under WinXP and Win7 only, no Vista (are you using Vista?) It's normal that the GM5 status LEDs only is lit as long as the USB MIDI driver hasn't connected to the core - thereafter the LED turns off. It seems that your Windows connects very fast - thats ok! The MIDI IN/OUT LEDs are flickering randomly at power-on, this also seems to be ok... In order to ensure that the problem isn't related to your synth: could you please try a loopback test? (e.g. with MIOS Studio) Try it also with the GM5 windows driver, just to exclude that any other driver on your PC modified the original USB MIDI driver Microsoft (e.g. some people noticed this with a Logitech Webcam driver) Best Regards, Thorsten.

Sweet DIY project! Congratulations! :) Best Regards, Thorsten.

Nice - this will be a no-brainer! :) (especially since the delay parameter is already mapped to allow insertion of new values between existing values) Best Regards, Thorsten.

ST provides a very useful documentation for these functions: STM32F10x reference manual: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf Chapter 9: General Purpose and alternative-function IOs The functions and parameters are documented in the source code: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fdrivers%2FSTM32F10x%2Fv3.3.0%2FSTM32F10x_StdPeriph_Driver%2Finc%2Fstm32f10x_gpio.h http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fdrivers%2FSTM32F10x%2Fv3.3.0%2FSTM32F10x_StdPeriph_Driver%2Fsrc%2Fstm32f10x_gpio.c Best Regards, Thorsten.

Cool! :) I merged the topics and moved the article to MIOS Programming This means that the same pin number is passed for different multiplexer groups, is this ok for you? It could make sense to forward the mux variable to the function which handles the buttons (if required), e.g. if you want to send Note events over different channels. Best Regards, Thorsten.

I'm glad that it's (almost) working! And thanks for the beers! :) Yes, the DIN buffer copy routine has a typical copy&paste error - it copies mios32_srio_* variables, although app.c uses local variables called srio_* Update is here: http://www.ucapps.de/tmp/fast_srio_scan_v0_3.zip Changes: before muxctr is incremented, I store the previous counter value in a temporary variable: u8 prev_muxctr = muxctr; if ( ++muxctr >= 4 ) { muxctr = 0; } [/code] DIN buffer copy and change detection: [code] // copy/or buffered DIN values/changed flags of previous scan int i; for(i=0; i<MIOS32_SRIO_NUM_SR; ++i) { srio_din_changed[prev_muxctr][i] |= srio_din[prev_muxctr][i] ^ srio_din_buffer[prev_muxctr][i]; srio_din[prev_muxctr][i] = srio_din_buffer[prev_muxctr][i]; } I've no explanation why J5 input #11 doesn't work - did you replace the "#if 0" by "#if 1" to enable the if condition? #if 1 if (MIOS32_BOARD_J5_PinGet(11) == 0) { //test for mode 1 MIOS32_BOARD_J5_PinSet(muxctr + 4 , 1); //jm set keyboard mux pin on mode 1 } #endif [/code] Best Regards, Thorsten.

Ok, it's clear now. So, I added the DIN handling: http://www.ucapps.de/tmp/fast_srio_scan_v0_2.zip Thats the last change I've planned to make - I haven't checked if DIN values are handled correctly, but as mentioned: it's just a demo for possible optimizations. 8 SRs are scanned in ca. 8..9 uS. The period is slightly jittering by ca. 1 uS, but this should be acceptable. It never takes longer than 10 uS The DIN_Handler calls APP_DIN_NotifyToggle with following parameters: u32 pin = MIOS32_SRIO_NUM_SR*8*mux + 8*sr + sr_pin; u32 pin_value = (srio_din[mux][sr] & (1 << sr_pin)) ? 1 : 0; APP_DIN_NotifyToggle(pin, pin_value); [/code] You have to decode the pin number again in this hook, or alternatively define another hook (if this is easier for you) which has the mux number as additional parameter. DOUT pins have to be set/cleared by writing directly into the srio_dout[mux][sr] array. Hope it works! Best Regards, Thorsten.

Hm... maybe it's better to give you a half-ready demo for discussion, because some points are not clear to me. You will find the sources under http://www.ucapps.de/tmp/fast_srio_scan_v0_1.zip Optimizations: instead of patching code into original MIOS32 routines, I started to copy the relevant SRIO/DIN/DOUT parts into app.c - typically this gives more freedom and a better oversight (use MIOS32 code only as a template) the SRIO_Handler prepares the next SRIO transfer, when it's finished the DMA IRQ will call SRIO_Handler again -> it's triggered periodically the RC pin is only toggled once between the transfers - thats a trick! While it captures new DIN values, it also captures the DOUT values at the same moment. I optimized some bits of mios32_spi.c, please update the repository gap between SRIO transfers: only ca. 5 uS anymore (but will be a bit longer once DIN values are stored before next transfer) SPI pins configured for Push-Pull with *strong* drivers (should be faster than weak drivers) J5 pin accesses now done directly via SFR write operations (less readable code, but in total the SRIO_Handler runs ca. 2 uS faster) prepared TASK_DIN_Handler which is running in background and which will check for pin changes in an endless loop. It can be interrupted by higher-prio MIOS32 tasks. Using a task instead of an interrupt routine makes much more sense here, as MIDI transfers could be blocking (e.g. if UART fifo is full) - maybe you already noticed this effect - interrupts should be executed as fast as possible and they shouldn't block for more than 10 uS (maximum 100 uS) Although the DIN handling (check for pin changes) hasn't been implemented yet (I can do this once the approach is clear), I guess that the typical scan speed for 4*8 SRs will be ca. 200 uS if SRs are clocked with 16x prescaler Now my question: why do you need such a high scan speed, although you are only using a common UART to send MIDI values? Sending a MIDI event which consists of 3 bytes takes 960 uS, by using running status optimization (channel number doesn't change) 640 uS So, does it really make sense to scan faster? Due to the reduced MIDI speed (as long as you are not using USB) you wouldn't notice an effect. Or wouldn't it make more sense to slow down SRIO for more robustness, and/or use common MIOS32 access functions (e.g. for J5) to make the source code more readable? Best Regards, Thorsten.

I'm going to write a demo application for you and already optimized a lot of things. More infos in ca. 30 minutes Best Regards, Thorsten.

thats true if you are the only person who maintains the project. From my experience it won't work once somebody else (e.g. a programming newbie) tries out some modifications, it could cost him multiple hours to debug this, or he just gives up. In newer projects (e.g. MBSID V2.. which actually isn't so new anymore) I'm using such page checks as well, and throw an #error message on overlaps, but usually I try to avoid such dependencies whenever possible with the drawback that it will cost some additional cycles. However, I don't want to say that you should use a different (more time consuming) method now, I only want to explain why I'm a bit more careful meanwhile. Additional CPU cycles will be compensated by less support effort. ;) Best Regards, Thorsten.

Thanks for the work! Although I've currently too much other interests, it's nice to see the progress. IIC MIDI isn't identical to USB MIDI, it's just similar to USB MIDI and gives us some freedom for extensions ;-) The advantage of a state machine: if it's already there, it's easy to add commands with more than 3 bytes. If it's clear that more than 3 bytes will never be transfered per command, you could also use 0x1 (which is reserved according to the USB MIDI spec) This is the result of reused code from an old PIC16F project that I wrote more than 10 years ago, and a newer project that I wrote on a PIC18F The capabilities of a PIC16F are very limited, e.g. there is no tblrd* command which would allow to directly read from flash. But I wanted to use the same tables like on my MBHP_USB_MIDI_PIC project. Alternatively we could use lookup tables similar to this one: MIDI_MTC_NextExpectedByte andlw 0x07 addwf PCL, F retlw 0xf0 retlw 0x7f retlw 0x7f retlw 0x01 retlw 0x01 retlw 0x00 ; dummy retlw 0x00 ; dummy retlw 0x00 ; dummy [/code] which works much faster. But it has the disadvantage that it has to be ensured that the code is located within a 256 byte page (which mostly results into more cluttered sources), and that it will only run on a PIC16F this way. For PIC18F a similar approach is possible with a trick, but it would consume more cycles than a tblrd* So, it was a difficult decision to find a good compromise, and at the day I wrote the firmware I thought it would be better to make it better portable to PIC18F derivatives as I wasn't sure if PIC16F will be sufficient. Best Regards, Thorsten.

The MB808 is pure assembly code and doesn't require a C compiler. In order to build a new .hex file on a Windows PC, you have to install gputils and MinGW (as a Unix replacement to execute the Makefile) On a Mac or Linux PC, you only have to install gputils. Then go into the application directory and type make -> done It should even be possible to create .hex files without the Makefile mechanism (so that you don't need MinGW), just execute the commands directly in a command shell or from a .bat file: gpasm -p p18f4620 -I./src -I ./include/asm -I ./include/share -I ./modules/app_lcd/dummy -I ./modules/iic_midi -I ./modules/aout setup_808_mbseqv3_hardware.asm gpasm -p p18f4620 -I./src -I ./include/asm -I ./include/share -I ./modules/app_lcd/dummy -I ./modules/iic_midi -I ./modules/aout setup_808_mbseqv3_tk.asm gpasm -p p18f4620 -I./src -I ./include/asm -I ./include/share -I ./modules/app_lcd/dummy -I ./modules/iic_midi -I ./modules/aout setup_808_tk.asm gpasm -p p18f4620 -I./src -I ./include/asm -I ./include/share -I ./modules/app_lcd/dummy -I ./modules/iic_midi -I ./modules/aout setup_808_default.asm gpasm -p p18f4620 -I./src -I ./include/asm -I ./include/share -I ./modules/app_lcd/dummy -I ./modules/iic_midi -I ./modules/aout setup_808_with_swingpot.asm [/code] thats all! MPLAB isn't supported, and I don't see the need for this (too cumbersome and error prone) Best Regards, Thorsten.

Der Taster wuerde problemlos funktionieren, doch ich halte ihn fuer ueberteuert, und er nimmt vielleicht auch zuviel Flaeche ein. Mein persoenlicher Favorit ist diese Loesung: Diese Taster/LED Kombination ist auch nicht schlecht: http://www.omron.com/ecb/products/pdf/en-b3w-9.pdf Doch das sind natuerlich keine Edelstahl Taster... Gruss, Thorsten.

Btw.: there is a hidden feature in the MIOS32 implementation: inside the MIOS terminal, type "!" followed by any characters, they will be directly sent to SpeakJet This could be a helpful for finding nice phrases before they are hardcoded into the application (the function is located in terminal.c) See the SpeakJet datasheet for available codes. I remember that there was a dictionary for SpeakJet codes somewhere in the web, you could integrate it into the app as well Best Regards, Thorsten.

Update: the issue will be fixed in Beta42: ui_selected_group = (u8)encoder / 4; // if no track selected in current group anymore, search another (valid) group if( (ui_selected_tracks >> (4*ui_selected_group)) == 0 ) { u8 group; for(group=0; group<SEQ_CORE_NUM_GROUPS; ++group) { if( ((ui_selected_tracks >> (4*group) & 0xf)) != 0 ) { ui_selected_group = group; break; } } } [/code] Best Regards, Thorsten.

I really like the desktop case! MBFM could have looked like this years before w/o my 19" rack fetish at this time... blogged :) Best Regards, Thorsten.

Hi Jmayes, I guess that the interrupt routine consumes too many CPU cycles, so that there isn't enough time to handle other threads, such as USB. But there is much room for optimisation - could you please attach you project in a .zip file, so that I can have a look? (please type "make cleanall" before to remove the binaries) Best Regards, Thorsten.

I can confirm that SpeakJet sometimes behaves very unstable, this is a big limitation of this chip which makes it useless for a real synthesizer. (see also other opinions in this long thread) Thats also the reason why I proposed that it would be better to run the speak synth internally (to get rid of SpeakJet), because the LPC17 microcontroller has more than enough processing power to handle this, and it would open new options. Best Regards, Thorsten.

:) Yes, this is how the algorithm is working. If I wouldn't handle it this way, Track 1 would stay selected even if you want to select another track exclusively I don't want to change this, as the page is essential for people who want to quickly select between tracks in different groups (single-selections) Thanks for giving me the right order of selections! I was able to reproduce the problem. I guess that it's related to the SEQ_UI_CheckSelections() function: ///////////////////////////////////////////////////////////////////////////// // Should be regulary called to check if the layer/instrument/step selection // is valid for the current track // At least executed before button/encoder and LCD function calls ///////////////////////////////////////////////////////////////////////////// s32 SEQ_UI_CheckSelections(void) { if( ((ui_selected_tracks >> (4*ui_selected_group)) & 0xf) == 0 ) ui_selected_tracks = 1 << (4*ui_selected_group); u8 visible_track = SEQ_UI_VisibleTrackGet(); if( ui_selected_instrument >= SEQ_PAR_NumInstrumentsGet(visible_track) ) ui_selected_instrument = 0; if( ui_selected_par_layer >= SEQ_PAR_NumLayersGet(visible_track) ) ui_selected_par_layer = 0; if( ui_selected_trg_layer >= SEQ_TRG_NumLayersGet(visible_track) ) ui_selected_trg_layer = 0; if( ui_selected_step >= SEQ_TRG_NumStepsGet(visible_track) ) ui_selected_step = 0; if( ui_selected_step_view >= (SEQ_TRG_NumStepsGet(visible_track)/16) ) { ui_selected_step_view = 0; ui_selected_step %= 16; } if( ui_selected_step < (16*ui_selected_step_view) || ui_selected_step >= (16*(ui_selected_step_view+1)) ) ui_selected_step_view = ui_selected_step / 16; return 0; // no error } [/code] The first check ensures, that for the case that no tracks are selected in the current group (anymore), the first track of the group will be automatically selected. In MBSEQ V3 this missing check was leading to confusion (somebody thought his sequencer crashed since no values could be changed in the edit page anymore). I will improve the track selection, so that a valid group is determined for the scenario that you gave me! Best Regards, Thorsten.

Thanks! Btw.: Beta42 will provide some new awesome features which haven't been suggested yet! :ahappy: Best Regards, Thorsten.

Hi, I updated the project setup; try it again Best Regards, Thorsten.

Under MacOS you have to install MMJ because the original Java driver supported by Apple doesn't support SysEx: http://www.humatic.de/htools/mmj.htm Best Regards, Thorsten.

It works at my side. Best Regards, Thorsten.

Welcome back! :) I would propose to use Reed Relays instead (see also this picture: http://www.ucapps.de/mbhp/mbhp_doutx1_reed_relays.jpg - the relays are connected to a shift register here, but could also be directly connected to PIC pins of course) Current consumption is low, and no additional components are required. Available at Reichelt (SIL 7271-D 5V) for 1.40 EUR The demo application can be found under: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fasm%2Fj5_dout%2F A precompiled binary is available under: http://www.ucapps.de/mios_download.html (search for j5_dout) Note that a J5 driver is available which would allow you to access J5 pins from C code as well: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fj5_io%2F And here the example which explains how to access any pin from C: http://www.ucapps.de/mios_c_pic_pin.html Best Regards, Thorsten.