TK.

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.

That's a mistake at my side, I've to consider this flag in MBNG_MATRIX_DOUT_PinSet as well. Best Regards, Thorsten.

Some words from my side: I always found the capabilities of RTP-MIDI very attractive, but refused to implement it natively into MIOS32 because of the high amount of engineering effort for a proper implementation of the RTP and Bonjour protocol. Also the resource requirements (especially RAM and fast response time) are so high, that it was clearly something which can't run in parallel to a typical MIOS32 application like MIDIbox SEQ or MIDIbox NG -> definitely something that has to be offloaded to a second core. I was highly interested on the KissBox OEM after Benoit contacted me (actually because of a different project, but we quickly changed the topic ;-), he sent me a sample PCB, and in the last days we worked out a high performance communication protocol for MIOS32 based cores, which works stable. For those who are interested: the driver is implemented in mios32_spi_midi.c: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2Fcommon%2Fmios32_spi_midi.c The KissBox is connected to the core via J16. It shares the port with a SD Card (almost no disadvantage), and since there is no hardware conflict, it will be available for all MIOS32 applications in future. Note, that the KissBox OEM also supports an alternative firmware for UART based MIDI ports. This means, that you could upgrade other MIDI devices as well (e.g. MBHP_CORE based -> just connect the Rx/Tx lines to J11) In this case the connection will be slower (just the common MIDI baudrate), but the network based approach still has advantages. Main advantages (from my point of view): in distance to UART or USB based MIDI, a device can contact any other device over a single cable, and transmit with an extremely stable timing. E.g. after experimenting with KissBox I believe that RTP MIDI is the best way to distribute a MIDI clock to multiple computers (and MIDIboxes of course ;-) Better than OSC, especially on a WiFi connection due to guaranteed transmission in the expected order thanks to TCP/IP (instead of UDP) -> no danger for hanging notes! Seamless integration with MacOS, iOS but also Windows computers thanks to Tobias Erichsen's driver in distance to CopperLAN (we had a discussion on this in another thread), the RTP MIDI protocol isn't a closed source protocol which needs proprietary drivers Benoit hasn't mentioned this, but KissBox is ready for HD MIDI, and MIOS32 based devices will probably be the first ones which support the upcoming standard! :smile: Best Regards, Thorsten.

Hi Andy, I can confirm, that J3:RC1 and J3:RC2 are swapped on the V1 AINSER64 PCB due to a layout error. That's correct, and this is the way it should work. How long are the cables? Each cable shouldn't be longer than ca. 10..20 cm! Best Regards, Thorsten.

Step by Step... ;) Best Regards, Thorsten.

Yes, the data lines should be ok. I checked this against this interconnection diagram: http://www.ucapps.de/midibox_seq/mbseq_v4_interconnections_lpc17.pdf Best Regards, Thorsten.

Following version should fix the WT SysEx issue, please try it at your side: http://www.ucapps.de/mios/midibox_fm_v1_4h.zip Best Regards, Thorsten.

Just wanted to troubleshoot the MBFM firmware, but I've the same problem. I'm getting following error message under MacOS and Linux: Exception in thread "main" java.lang.UnsupportedClassVersionError: ui/MainWindow : Unsupported major.minor version 51.0 Version under MacOS: java version "1.6.0_65" Java? SE Runtime Environment (build 1.6.0_65-b14-462-11M4609) Java HotSpot? 64-Bit Server VM (build 20.65-b04-462, mixed mode) And under Linux (Ubuntu): java version "1.6.0_27" OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.12.04.2) OpenJDK Client VM (build 20.0-b12, mixed mode, sharing) Best Regards, Thorsten.

I agree with Hawkeye, that such a control surface unfortunately doesn't fit with the MBSEQ V4 concept. A new application has to be developed for this, e.g. based on this tutorial: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F017_sequencer%2F My sparetime is too limited for such side-projects (which I'm not used myself), but maybe somebody else with programming skills is interested? Best Regards, Thorsten.

Very nice! Could you guys please document this case built in the Wiki? I guess that the .svg files would also be interesting for other users! :) Best Regards, Thorsten.

yes, you are right. yes, very likely! What did you do with the PIC so that this happened? Actually PICs are very robust chips. E.g. if you would clamp the RC output to ground or +5V, nothing dangerous would happen... So, something else has caused this defect! Best Regards, Thorsten.