TK.

We've a problem here: the application can only open one file (because there is only a single read buffer). This was never a problem before, but now you found a case where it does matter. I've to consider to overwork the file handling to cover this case, but this will be a complicated change, and I won't have the time to do this in the next 3..4 weeks... :-/ Best Regards, Thorsten.

Yes Best Regards, Thorsten.

Did you try the "debug on" mode? It reports the function calls during an event is processed. It could help you to understand, under which circumstances the LED status is changed. Best Regards, Thorsten.

I remember that some people had the same issue with OLEDs because they don't support the 4bit mode properly. Fortunately the MBSID V2 application comes with an alternative LCD driver for 8bit mode. The driver can be selected with LCD type 7 in the PIC ID. Upload following application to change the ID: http://www.ucapps.de/tmp/device_id_00_lcd7.zip Thereafter upload the MBSID application again... For 8bit mode, D0, D1, D4, D5, D6 and D7 of the OLED display have been connected to J15:D0/D1/D4/D5/D6/D7 of the core (as usual) D2 and D3 have to be connected to PIC pin RE1 and RE2, which are available at J5:A6 and J5:A7 (see schematic: http://www.ucapps.de/mbhp/mbhp_core_v3.pdf) Best Regards, Thorsten.

Reichelt hat ein paar recht guenstige Knoepfe im Angebot, so wie bspw. diesen: http://www.reichelt.de/KNOPF-10-150E/3/index.html?&ACTION=3&LA=446&ARTICLE=73960 und diesen: http://www.reichelt.de/KNOPF-13-164E/3/index.html?&ACTION=3&LA=446&ARTICLE=73962 Allerdings haben die keine Markierung; die muesste man sich selbst draufmalen. Gruss, Thorsten.

For MBSEQ V3 the gates will be available at J5A and J5B, DIN start and stop at J10B 4 MIDI IOs are available at J11E For MBCV V2 gates and DIN signals are only accessible via DOUT shift registers (which also act as level shifters). I consider to add the same possibility for MBSEQ V4 (as an option). So: if you want to create something which is compatible with both applications, go for two DOUT shift registers (resp. use a MBHP_DIO_MATRIX module) Best Regards, Thorsten.

I'm always doing this whenever I update central code. It's completely automated at my side for all derivatives - therefore I'm surprised that it fails at your side! Maybe you've changed a file locally which is not in sync with the repository anymore? I would propose that you download the complete repository again (e.g. into a separate folder) and try it from there. However, I just have finalized the new universal LCD driver, again many changes in the MIOS32 base, and again the danger that you miss an update if you are doing local changes in MIOS32 sources! ;-) So - please try it again with a fresh download. And for the case that you are still not able to compile, here are the prebuilt binaries of the new bootloader: http://www.ucapps.de/mios32/mios32_bootloader_v1_014.zip Best Regards, Thorsten.

Yes, for PIC based applications you've to upload MIOS8 first, thereafter upload the application (MIDIO128) Best Regards, Thorsten.

You've to disable the datawheel encoder with: # SR Pin Type ENC_DATAWHEEL 0 0 DETENTED3 Or you've to assign it to different pins Best Regards, Thorsten.

Yes, no problem. Use this template for your C++ applications: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftemplates%2Fapp_skeleton_cpp%2F Here a typical application which applies object oriented C++ code (located under src/components): http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fprocessing%2Fmidibox_cv_v2%2F Best Regards, Thorsten.

The Discovery board on the MBHP_CORE_STM32F4 module has a Micro USB socket which could also be used for USB Host direction with a special adaptor. It's on my long term agenda to support this, but don't expect it before summer... ;) I will come back to your offer in February/March :) Best Regards, Thorsten.

Ok, added this chip to my Reichelt shopping basket (I will order by end of this month... ;)) Best Regards, Thorsten.

If more than 4 IIC_MIDI based IOs are desired, it makes sense to think about a redesigned version of the MBHP_IIC_MIDI module, which gets use of a microcontroller with more UARTs. E.g. the PIC18F25K22 comes in a small 28-pin DIP package, contains 4 UARTs and is available for 2.55 EUR at Reichelt: http://www.reichelt.de/PIC-18F25K22-ISP/3/index.html?&ACTION=3&LA=446&ARTICLE=109911 Then 4 chips could be connected to a single IIC port, makes up to 16 IOs Best Regards, Thorsten.

Ping Flood to a KissBox: sudo ping -f 192.168.0.253 PING 192.168.0.253 (192.168.0.253): 56 data bytes .^C --- 192.168.0.253 ping statistics --- 34515 packets transmitted, 34514 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.095/0.123/0.367/0.004 ms Ping Flood to a Raspberry Pi over the same Ethernet Cable (I had to enable DHCP, therefore the IP is different): sudo ping -f 192.168.3.3 PING 192.168.3.3 (192.168.3.3): 56 data bytes .^C --- 192.168.3.3 ping statistics --- 28206 packets transmitted, 28205 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.236/0.339/1.379/0.028 ms As you can see, the ping responsiveness of a Raspberry Pi jitters between 0.23 and 1.38 mS in my network, while KissBox only jitters around 0.09 and 0.37 mS Once I find the time, I could check the responsiveness of RTP MIDI running under Linux, but I don't expect good results, because a common Linux kernel is not a Realtime OS. There are RTOS versions, but then the big question: is the RTP MIDI driver compatible? Another potential issue: the access to IO ports is slow compared to microcontrollers. And the connectivity is very restricted. Especially because it seems that Raspberry Pi doesn't support SPI Slave mode (see also http://www.raspberrypi.org/phpBB3/viewtopic.php?&t=5125), and I guess that nobody developed a RTP MIDI <-> SPI bridge for Linux yet. SPI Slave is mandatory for the communication with another core, otherwise MIOS32 would have to take over the slave role, and this results into increased RAM consumption (to buffer data sent by the SPI master), and to an heavily increased CPU load since MIOS32 couldn't use the DMA for SPI transactions anymore! Result: poor performance of applications like MIDIbox SEQ and NG, and risk for MIDI data loss on a MIDIbox CV which prioritizes the ISR which handles CV outputs. However, it might be possible that other people already worked on the RTP MIDI <-> UART based MIDI topic in the past, so that the Raspberry Pi would be a good alternative solution for additional RTP MIDI nodes. But I doubt that it will ever beat the connectivity options of a KissBox OEM. Best Regards, Thorsten.

A connectivity example for the upcoming MBHP_CORE_STM32F4, two MBHP_MIDI_IO, Quad-IIC MIDI, MBHP_AOUT_NG and KissBox OEM board: Best Regards, Thorsten.

In distance to USB, Latency is no issue for RTP MIDI, because the protocol ensures a synchronized delivery thanks to the timestamps and latency compensation measures :) (I checked this with the scope) More details here: http://en.wikipedia.org/wiki/RTP_MIDI#Latency Best Regards, Thorsten.

I doublechecked with Benoit, and can confirm that the sessions can be routed to different "virtual cables", so that they are accessible as RTP1..RTP16 in MIOS32, and can be routed to individual MIDI ports (or used internally independent from each other. E.g. the most simple configuration would be something like: RTP1 ALL -> OUT1 ALL RTP2 ALL -> OUT2 ALL RTP3 ALL -> OUT3 ALL RTP4 ALL -> OUT4 ALL RTP5 ALL -> IIC1 ALL RTP6 ALL -> IIC2 ALL RTP7 ALL -> IIC3 ALL RTP8 ALL -> IIC4 ALL RTP9 ALL -> USB1 ALL RTP10 ALL -> USB2 ALL RTP11 ALL -> USB3 ALL RTP12 ALL -> USB4 ALL and then use RTP13..RTP16 for internal sources and destinations ;-) All MIOS32 applications which use the standard MIDI router will support this, such as MIDIbox SEQ V4, MIDIO128 V3, MIDIbox NG, MIDIbox CV2 In other words: one of many functions of your MIDIbox will be to act as a gateway to your (Wireless/Wireline) network, and you can connect multiple "common" MIDI devices to it with standard MIDI interface (or USB or CV or...) And one or more computers/tablets/phones can connect to this network as well, and communicate via the sessions. And if you've multiple MIDIboxes equipped with the KissBox OEM, they will be part of the sessions as well. No problem, the MIDI player/recorder can send to the RTP ports, and receive :smile: Best Regards, Thorsten.

Thank you very much, this was a bug^H^Hig help! :thumbsup: I integrated your changes and committed a new version to the SVN server. Best Regards, Thorsten.

I agree that the small size has advantages for projects like MIDIbox KB Best Regards, Thorsten.

Very good! :thumbsup: Best Regards, Thorsten.

Yes, the app_lcd/universal driver is still under construction: 1) I've to change the way how the extra pins are accessed for different boards, because all the #if/#elif options look like a big mess 2) I've to test all LCD types and connection variants and tune the timings for best performance. However, I've added a temporary solution for you so that you can try out a KS0108 based GLCD - I haven't tested it at my side (crossing fingers!) The CS pins should be available at J10B:D8 .. J10B:D11 now Best Regards, Thorsten.

Yes, 100% correct! Btw.: I received the STM32F4 PCB today, first results are promising (no error so far... of course, it has been layouted by SmashTV! :)) Best Regards, Thorsten.

MIOS32_SPI_MIDI supports up to 16 independent MIDI IO ports (like USB MIDI), which can be used internally in the application, or which could be forwarded to physical interfaces like UART MIDI or IIC_MIDI. However, Benoit has to answer on the supported maximum number of independent network ports and UART MIDI ports for the alternative firmware. Best Regards, Thorsten.

(I won't be able to support you on this topic the next days...) Best Regards, Thorsten.

If a computer is involved anyhow, you could use MIDIbox NG for the control surface and CV/gate outputs: http://www.ucapps.de/midibox_ng.html Best Regards, Thorsten.