TK.

MIOS Studio 2.4.6 is available now Changes: allow upload when core based MIDI merger enabled abort upload after 16 retries if the MIDI IN connection of a PIC is not working (no additional retries) Best Regards, Thorsten.

Yes, MBLC accesses the LCD in 8bit mode. Be careful with the pinout: very likely it's identical to common LCDs, if you would try one "wrong" connection, you could fry the LCD! Although users haven't reported problems with the MIOS8 LCD driver in the last years, it can't be excluded that your LCDs behave a bit different to the standard. Therefore it would be interesting, if the alternative CLCD driver causes a change: see http://www.ucapps.de/mios_download.html, search for "lcd7_clcd_v2a.zip", just download the precompiled .hex to test it. If it doesn't work, power-off the core, wait for 3 seconds, power-on again to ensure that your LCD starts under reset conditions. Does this help? Best Regards, Thorsten.

Do you mean "Voltcraft 275" or 175? I'm asking, because when I google for the '275, I only get your posting as the first hit - for the '175 I get the datasheet: http://www.produktinfo.conrad.com/datenblaetter/100000-124999/124457-an-01-ml-VC175_DIGITAL_MULTIMETER_de_en_fr_nl.pdf The datasheet says, that the accuracy is 0.8% reading + 8 steps (which is pretty high). So, in worst case, instead of 2.000V the actual voltage could be 2.016V or 1.984V +/- 8 steps (so, 2.024 or 1.976) You can compensate this error a bit, if you would measure two or even three calibration points. Change the gain until 1V *and* 4V are close to the target value Then measure 2V -> result? If this doesn't help, it might be better to tune the oscillator of your synth with a reference sine tone. Best Regards, Thorsten.

Do you mean the last SysEx string? It's not a merging error, but a message to the MIOS Terminal. f0 00 00 7e 32 00 0d 40 5b 4d 49 4f 53 33 32 5f 4d 49 44 49 5f 52 65 63 65 69 76 65 5f 48 61 6e 64 6c 65 72 5d 20 54 69 6d 65 6f 75 74 20 6f 6e 20 70 6f 72 74 20 30 78 32 31 0a 00 f7 stands for: Port 0x21 stands for IN2 It could be, that this happens since currently short messages from the IN side generate long messages at the OUT side (bottleneck issue), so that a MIDI IN buffer overrun could happen depending on the amount of messages which are received in a given timeframe. This can be avoided by sending messages only to a MIDI port which is faster than the IN port. In other words: if you would explicitly define ports=1000000000000000 in the EVENT_* statements, so that messages are only forwarded to USB1 (and not to OUT1 and OSC1 in addition, which is done by default...), the timeout error shouldn't happen anymore, because USB is *much* faster than traditional MIDI! :smile: Best Regards, Thorsten.

Hi Tim, ok, it looks like the MIDI transfer between PC and PIC is not working, because the PIC doesn't respond on incoming commands. So, there is either a problem with the MIDI OUT port of your PC, or with the MIDI IN of the MBHP_CORE module. Here the troubleshooting guide which helps to find the root cause: http://www.ucapps.de/howto_debug_midi.html It's a bug in MIOS Studio, that it says that the upload was successfull in this case! I will improve the message (and I think that the best way would be to output the link to this troubleshooting page ;-)) Best Regards, Thorsten.

Hi Robin, as long as the LCD is serviced from a lower priority task, there is no danger for interferences. It's guaranteed that the scan task gets the same compute time like before. That's actually the big advantage when a realtime operating system (FreeRTOS) is used. :) The most simple way how to program this would be the usage of the APP_Background hook E.g. from http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Fblm%2Fapp.c ///////////////////////////////////////////////////////////////////////////// // This task is running endless in background ///////////////////////////////////////////////////////////////////////////// void APP_Background(void) { // init LCD MIOS32_LCD_Clear(); // endless loop: print status information on LCD while( 1 ) { // toggle the state of all LEDs (allows to measure the execution speed with a scope) MIOS32_BOARD_LED_Set(0xffffffff, ~MIOS32_BOARD_LED_Get()); // print text on LCD screen MIOS32_LCD_CursorSet(0, 0); MIOS32_LCD_PrintFormattedString("DIN Pin #%3d %c", last_din_pin, last_din_value ? 'o' : '*'); // print text on LCD screen MIOS32_LCD_CursorSet(0, 1); MIOS32_LCD_PrintFormattedString("DOUT Pin #%3d %c", last_dout_pin, last_dout_value ? 'o' : '*'); } } Best Regards, Thorsten.

Unfortunately some SDIO pins conflict with the Audio-DAC, so that it can't be used on the STM32F4DISCOVERY board. Or do you know a workaround? Best Regards, Thorsten.

Some news from STM32F4: I started with the schematic and assigned the pins. The upcoming breakout board (layouted by SmashTV) will provide sockets for: - USB (via the on-board Micro-Socket) - 4 MIDI INs and 4 MIDI OUTs (note: the MIDI IOs will require a separate PCB, more about this topic later...) - 3 SPIs, each one with 2 CS lines. Two SPIs at 5V, one at 3.3V (for SD Card) - 8 analog inputs - 2 LCD ports - 2 IIC - 1 CAN - 8 IOs (J10) - (on-board) Stereo Audio DAC Note: some of the current pin assignments will be changed based on the new schematic in the next days. Everybody who already built the HW has to adapt some connections (e.g. for the SD Card) accordingly. I will publish the schematic once I tested all connections, and once I'm sure that they are final. Best Regards, Thorsten.

I second this! For chiptunes the usage of simple sounds with different timbres for the instrument lines is essential, otherwise the mix won't work. In order to simplify the usage of multi-engine patches, I would propose to assign each instrument to a dedicated oscillator. This can be done in the CFG menu, item "VAs" - change it to O1 for the first instrument (I1), O2 for I2, O3 for I3, etc... Mono mode should be enabled as well (if you prefer Poly, then it's another story: you could assign it to the left or right SID) Advantage: now it's also easier to assign filters to oscillators which are directly assigned to the instruments. E.g. enable the left SID filter only for O1 (played with I1), and the right SID filter to O4 (played with I4) - now you can control the filter with ENV and LFOs and WT without conflicts. Last but not least the MIDI configuration: in the ensemble, you could assign each instrument to a dedicated MIDI channel. But sometimes it's better to use keyboard zones on the same channel instead. E.g. if you want to play a melody line with three different timbres (-> instruments), then just assign the instruments to different zones in the ensemble INS menu (SpL and SpU item), and transpose the zones so that they play in the desired octave range. -> now you can play the instruments from a single "piano roll" in your DAW. Best Regards, Thorsten.

Hi Tim, something is wrong here, the upload shouldn't take more than 20 seconds... and not 20 minutes! Could you please show the complete MIDI IN log? (just right-click on the MIDI IN monitor panel, select copy, and then paste the log into this posting) Best Regards, Thorsten.

Hi, the USB MIDI spec only refers to bulk transfers, there is no explanation why this transfer method has been preferred instead of interrupt or isochronous transfers. I can only assume, that interrupt transfers might result into more overhead if large data dumps (such as SysEx) has to be transferred. The USB 2 spec recommends interrupt transfers only for small amount of data. Anyhow, if you don't follow the USB MIDI spec, you would have to implement your own USB MIDI driver, and this seems to be a challenge, otherwise open source drivers (e.g. better than the really bad M$ implementation) would already exist. I guess you mean that jitter is an issue, and not the latency. I tested the latency and jitter some time ago under Windows with a special benchmark: http://ww2.miditest.earthvegaconnection.com Latency was ca. 2.7 mS, jitter ca. 0.3 mS Best Regards, Thorsten.

Currently not. It also can't import SysEx patches from a .mid file. You could send the patch directly from SD Card, but this function doesn't work together with songs. yes, just select the "Tempo" action; it allows to specify the BPM and a ramp time Best Regards, Thorsten.

Aside from a software issue (another application sends to the MIDI port in parallel to MIOS Studio), this could also be related to a power issue on the MBHP_CORE module. Check the voltage between the Vss/Vdd pins, it should be 5V. If it's less than 4.5V, the core will be reseted and will send the upload request again (period...) Best Regards, Thorsten.

Ich habe nochmal etwas in der applikation und im buflcd Treiber geaendert, jetzt sollte es nicht mehr crashen -> repository updaten! Sobald die MBNG auch das spezielle Protokoll fuer die Audio-Meter unterstuetzt, wird die MBLC Applikation verschwinden, weil sie redundant ist und von mir auch nicht mehr verwendet wird (was Du anhand der Crashes bereits feststellen konntest...) Die Meter muessen evtl. in lc_hwcfg.c konfiguriert werden (-> lc_hwcfg_ledrings) Nebenbei angemerkt: sobald die MBNG Applikation komplett ist, werde ich eine andere Hardware-Konfiguration empfehlen, mit der die Meter-LEDs an separate Shift Register angeschlossen werden, so dass aus der ineffektiven 16x16 LED Matrix zwei 8x16 Matrizen werden. Dadurch werden dann sowohl die LED Ringe, als auch die Meter wesentlich heller. Gruss, Thorsten.

That's strange! I've to check this, because the order shouldn't matter Best Regards, Thorsten.

I added it to the wishlist. This features requires a rework of the MIDI remote configuration (probably has to be moved into the options page) yes, HCSD should work, the firmware has dedicated routines for such SD Cards Best Regards, Thorsten.

For the case that it helps: no problem, the PIC can't toggle the pins in less than 100 nS Best Regards, Thorsten.

Well, the question is: why did you disable the forwarding? Without this forwarding, the DOUT pins can only be controlled via MIDI Best Regards, Thorsten.

Ok from my side - these are exactly the projects that I like to support! :) I will also post the videos in the midibox.org blog once I'm back home. It could inspire other people. Best Regards, Thorsten.

I overworked the "bootloader installation" page, it should now clearly describe what has to be done at your side. :) -> http://www.ucapps.de/mios_bootstrap_experts.html Best Regards, Thorsten.

I can confirm, that the Diamex PICKIT2 clone is working under Windows and MacOS (and probably also under Linux). :) Therefore I overworked the bootloader installation page: http://www.ucapps.de/mios_bootstrap_experts.html Best Regards, Thorsten.

Hi, in theory it should be possible with MIDIbox KB: http://www.ucapps.de/midibox_kb.html But in order to confirm this, I would have to see the schematic. Do you have access to the file? (It seems to be password protected) Best Regards, Thorsten.

Ich habe das Problem gefunden - svn hat mir einen Streich gespielt, und die Aenderungen in src/mios32_config.h und src/lc_lcd.c nicht auf den Server geladen. Probiere bitte nochmal einen Update aus, danach sollte es funktionieren. Gruss, Thorsten.

Hi Lino, I can check this, but would need the exact EVENT definition that you are using to reproduce the issue. Best Regards, Thorsten.

Finally! :) Best Regards, Thorsten.