Search the Community

Hello to all MIDIBox forum members, I am proud to announce that, thanks to Thorsten work, the last version of MIOS is now RTP-MIDI ready :rolleyes: If you do not know what is RTP-MIDI, you can take a look there : http://en.wikipedia.org/wiki/RTP_MIDI (In two words, RTP-MIDI is transporting MIDI over IP networks, to take benefit from high speed from Ethernet, plus other new functionnalities like automatic merging/splitting). RTP-MIDI is completely license free, natively supported by Apple in OS-X and iOS, and there is a free driver for Windows too. It's also Plug&Play thanks to the use of Bonjour. The concept is based on the use of the KissBox RTP-MIDI OEM board (http://www.kissbox.nl/products_oem.html), which translates the RTP-MIDI protocol into an high speed SPI based protocol (the protocol being simply the one used for USB transfers) Of course, final users will not need to write their own RTP-MIDI application in the KissBox CPU board, I have written this part (Thorsten included the host part and tested it for the MIDIBox applications) The first version is in beta state, we are now looking to optimize it, especially the SPI speed. We will demonstrate the board at NAMM in Anaheim in two weeks, if you want to see it operating (we are located at booth 1088 in Hall E, for those who want to visit us) If you have any comment or question, they are of course welcome Benoit (PS : yes, I am from KissBox, in case you are asking yourself :shifty: )

Hello all, I wanted to inform the MB fourm members using the RTP-MIDI OEM that a small issue has been found with the RTP-MIDI driver in 10.8, 10.9 and partly 10.10. This issue is not critical at all but it can give you a lot of stress to try to find the root cause :hyper: The symptom is simple : under some circumstances, the MIDI communication starts only after 10 to 30 seconds after the session has been opened. The Apple driver indicates that everything is fine, but you see the first MIDI data some time after the session is opened (the MIDI data are not delayed, the MIDI communication really starts after this period, so no MIDI data being received or exchanged meanwhile) Here is a decription of the problem: The RTP-MIDI OEM board can be a session initiator and a session listener. In other terms, it can be invited by the Mac and it can also invite the Mac. When the Mac is the session initiator (meaning that you use the "MIDI Network Control Panel"), everything is fine: when you click on Connect button, you are able to exchange MIDI data with the KissBox OEM in the next second. When the OEM module becomes session intiator (meaning you have entered the Mac address in the KissBox Editor as a destination for the session), you will see that the Mac is being invited and accepts the invitation just after the OEM module is powered, but you are unable to exchange any MIDI data for a period around 10 seconds (I have even seen some exceptionnal cases where it was taking 30 seconds). The Apple Control Panel also becomes quite unresponsive during this time, giving you the feeling that the driver is crashed. We have found the origin of the problem and we have a solution for it :sweat: The root cause is a different behaviour in the clock synchronization period when the Mac is session initiator or when it is invited. When the Mac is initiator, it starts a synchronization sequence immediately after the session is opened, and the KissBox OEM is able to synchronize with this first message. When the Mac is invited, it gets the same synchronization sequence, but from the OEM module this time. For a strange reason, the Apple driver waits until it gets something like 15 or 20 messages from the OEM until it starts accepting MIDI data. During this period, on 10.8 and 10.9 machines, the Control Panel seems stuck (in fact, it works again as soon as there are enough CK messages received) Do not ask me why the Apple driver acts like this... This problem does not happen with the Windows rtpMIDI driver. I have modified the synchronization sequence of the OEM, to make sure it sends enough CK messages in a short time to "unlock" the driver. This change is implemented in V2.2 of the OEM firmware. I will release it on the KissBox website probably today or tomorrow Benoit