Jump to content

MIDIbox goes RTP-MIDI...


BEBDigitalAudio
 Share

Recommended Posts

So i don't think he will be implementing it in natively MIOS.

I think you may have misunderstood me. The GM5 is just a USB to MIDI bridge chip - it's not really even a MidiBox project (it doesn't run MidiBox firmware). MIOS32 has enough MIDI ports to be able to function similar to a GM5 (LIKE not AS), but with some MIDI routing built in as a nice bonus. So, I guess to avoid further confusion, I'm not talking about a GM5. I'm talking about a MidiBox-powered MIDI interface with USB/OSC/RTP/DIN bridge capabilities.

Correct me if I am wrong, but the whole point of the KissBox RTP board is so that can be offloaded from MIOS? Thus, adding RTP capability is possible by having MIOS talk to the KissBox, which handles all the other stuff.

So in other words, as I understand it, a MIOS-powered MIDI interface with USB bridge can already be done (that's partly what MIDIO128 is and there is a direct MIDI Router MIOS app if I'm not mistaken) so adding RTP would extend the capability allowing for a super MIDI router. With some application modifications being required for all that to work, obviously.

Link to comment
Share on other sites

m00dawg - interesting approach, but would prolly require some serious hacking, and a full tcp/ip stack with tcp sessions (not udp fire-and-forget packets).

 

Also, according to TK., it would suck up too many resources, not allowing for a smooth running SEQ V4 anymore, for example.

So offloading to another core is a great idea, especially as the core is already ready to use, and the hard work has been done!

 

The only potential problem I see, is that the add-on core is rather expensive, but the market forces will show, if it is accepted :-)

 

Many greets,

Peter

Link to comment
Share on other sites

m00dawg - interesting approach, but would prolly require some serious hacking, and a full tcp/ip stack with tcp sessions (not udp fire-and-forget packets).

 

Also, according to TK., it would suck up too many resources, not allowing for a smooth running SEQ V4 anymore, for example.

So offloading to another core is a great idea, especially as the core is already ready to use, and the hard work has been done!

 

The only potential problem I see, is that the add-on core is rather expensive, but the market forces will show, if it is accepted :-)

Haha maybe it's me missing the boat, but isn't the point of the add-on card we're talking about to offload all the heavy lifting from MIOS? Seemed like TK's last response confirmed SEQ4 will work with the add-on? I guess if the conversation has shifted away from using a 3rd party card that might be different but from TK's explanation of it, at least on LPC_CORE it will use the SPI (SD Card) interface?

Link to comment
Share on other sites

moodawg - ok, confusion here :-)

 

I thought you were proposing to implement the full RTP functionality on the same MIOS32 core as the SEQ (and using the ethernet port of the LPC17 for example) - that would not work.

Using the existing KissBox add-on core (connected via SPI) would work, of course and add MIDI RTP support to all new MIDIboxes.

 

To save some $$$, someone with lots of time at hand could implement the RTP MIDI protocol on a cheaper add-on core, connected identically via SPI.

 

Many greets,

Peter

Link to comment
Share on other sites

Yeah I saw that too, but I wasn't sure practically what that means in terms of MidiBox. Will, say, MIDIO128 compensate when playing back MIDI data and forwarding it on? If so, that's awesome! The only other issue is live playing, where those tricks wouldn't be available (according to the wiki page)? I mean, live playing something is already imperfectly human so minor latency isn't a huge deal necessarily. Still curious how that compares to DIN MIDI (or USB). I would expect it to be very good if it didn't share a network with anything else and decent switching hardware was used.

Link to comment
Share on other sites

Wow I would love a Kissbox in my seqV4!

Me and a friend of mine have a non-profit company (Elektruck) and we use RTP-midi for a couple of years now,  works great. The Elektruck is an old citybus wich we transformed in a mobile digital music workshop. We have 8 little basic studios in it, just tables with a computer with ableton, midikeyboard, micro and 2 headphones. Each spot/studio can handle 2 kids, so 16 in total, and we drive to schools and festivals to do electronic music workshops, making remixes, ringtones etc. 

We use rtp-midi to synchronize all computers and it works like a charm. I was really stuck by the ease of use of rtp-midi. I'm not such a computer nerd, network geek, programmer etc, and I'm always struggling with this stuff, OK,.. I like the struggling. But installing this rtp-midi on our system worked immediately, great to see showing up all those computers in the same session, hit play and all computers following. BTW we only use this on festivals where we like to organize spontenious jamsessions.

Anyway, just to say I see this as a great development in midibox-world.

 

Cheers,

Roel

Edited by Elektruck
Link to comment
Share on other sites

Hello eveybody,

 

once again, please accept my apologies for not being able to answer you all more quickly, but I am really busy with the preparation of the NAMM, and I was not expecting so many questions from the forum.

 

I will try to clarify a few things, in order to answer some of the questions I have read here:

 

First, I really understand your concerns about the price. Believe me, the KissBox CPU are quite expensive to manufacture. The main reason is that we used a very powerful processor, because we intend to do with this CPU much, much more than "simply" sending/receiving MIDI (I can't yet reveal what we will show to the NAMM, but believe me, it's using a lot of CPU power). And this processor is quite expensive. But it deserves the price we pay for it.

Moreover, as I explained in one of the first messages here, the boards must be assembled using automated machine, it can't be done by hand (we can't sell the board as a kit), and we are doing the assembly in a factory in Belgium, for quality and ethical reasons. So we have to pay our supplier for that.

And we are also making limited volume series, so the price of the components is still quite high.

 

Now, I admit that the price is high compared to other MIDI interfaces. So I would like to enumerate here the points on which RTP-MIDI is bringing "something more"

- toplogy free setup (USB and MIDI 1.0 are only point to point)

- practically unlimited distance between each node (an Ethernet cable is 100m max, but each time you add a switch, you can add a new cable)

- very high bandwidth compared to MIDI 1.0. This point is important for applications like MIOS based ones, because we can take benefit of an higher speed between the network module and the "main" processor.

- up to 16 endpoints in one KissBox OEM module. The equivalent of 16 MIDI interfaces.

- distributed patchbay concept (routing is not done by cables like with USB or MIDI1.0, but simply by telling "Device X should connect to device Y". And it can be changed at any moment without needing to remove any cable

- session management, clock synchronization

- etc... (I risk to appear as the "RTP-MIDI sales guy" if I continue like this :shifty: )

 

To be clear, RTP-MIDI can not compete in terms of price with a simple USB MIDI interface, if you intend just to replace a USB one by a RTP-MIDI. The volumes are still too low for that, and the hardware is still quite complex compared to USB one.

But if you are in one the cases I described just before, RTP-MIDI starts to become interesting (and is even the most competitive solution in some cases)

 

Last point I wanted to answer: some of you asked "how do we connect regular synths to RTP-MIDI?". It's a bit hard for me to answer to that here, I do not want to appear as promoting the KissBox catalog here...

But the standard MIDI interfaces are one of our business. They are designed to interface directly with exisiting MIDI devices. We also have the RTP-X module, which is designed to be integrated into existing hardware (MIDI2TR is mounted outside, RTP-X is mounted on an OEM inside machines). And we will show a new member of the family at NAMM... :santa:

Link to comment
Share on other sites

But RTP-X requires an RTP-OEM module in the first place, because it is only an addon, right? Which means it will add even more costs?

 

I'd really like to see a low-cost version of this - without the fancy "much, much more than sending/receiving MIDI" features that we will eventually see implemented on your current hardware.

Edited by ilmenator
Link to comment
Share on other sites

But RTP-X requires an RTP-OEM module in the first place, because it is only an addon, right? Which means it will add even more costs?

Yes

 

To be complete, here are the possible variations with the OEM board:

- RTP-MIDI OEM with SPI software (the solution used for MIOS) : high speed I/O over 16 virtual "cables" with SPI, but requires specific software on host, to handle the SPI protocol and the speed (that's what Thorsten did)

- RTP-MIDI OEM alone with RTP-X firmware : standard serial protocol (31.25 kbps) using LVTTL signal (3.3V). Limited to one MIDI port on host side (the MIDI2TR in the KissBox catalog requires a specific firmware and hardware to handle the two MIDI ports)

- RTP-MIDI OEM with RTP-X addon (and RTP-X firmware) : standard serial protocol using current loops. Limited to one MIDI port on host side. The RTP-X is designed for direct integration in CME master keyboards, but it can be used in any MIDI device (soldering is required to connect the expansion connector of the RTP-X to the original MIDI hardware)

 

Benoit

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

Dear All

 

First I want to thank Benoit for making available this RTP-OEM module to the MIDIbox community in small quantities.

Additional credits go to Thorsten as usual for his enthusiasm making RTP-MIDI available to us as I/O option on MIOS32 projects in near future.

 

Some personal opinions regarding the discussion on the price of the RTP-OEM module:

  • 90-100 Euros seems not to be a snap for the MIDIBox community.
    But you will get a fully compliant RTP-MIDI frontend, which can be easily accessed by any user application.
    It took me one week of my holidays several years ago just to understand the specified mechanisms of this powerful transport protocol.
     
  • I thought: “Well, I understand how to implement the base protocol without the journaling mechanism on a MIOS32 based controllerâ€.
    The problems arose as soon as I thought about the implementation of the proposed Session Initiation Protocol (SIP).
    The RTP-MIDI specs touch this issue only briefly in its implementation notes and refers to the SIP specs.
     
  • Which company actually use SIP for RTP-MIDI for connectivity? -> None!
     
  • How did Apple, the most known implementer of RTP-MIDI, initiate a RTP-MIDI session? -> No Idea!
    I was not in the mood to use Etherreal  aka. Wireshark to spy out the Session start and close mechanism, apart from digging through the Bonjour stuff.

So, I will be very happy to get a module which keeps me away from such network issues.

I understand that Benoit resp. Kissbox could not give away this for prime/material costs taking in account the huge amount of SW for RTP-MIDI implementation

Imho 90-100 Euros is still a bargain for such a device with this functionality including Session Initiation, RTP-MIDI and Journaling.

 

Questions:

  1. Thorsten mentioned that TCP/IP is used as lower layer transport protocol.
    Afaik RTP-MIDI uses UDP with the journaling mechanism for resilence and robustness.
    All PC-Hosts (PC/Apple) implement RTP-MIDI communication over IP via UDP.
    What is actually used?
     
  2. Benoit/Kissbox talks in their RTP-MIDI OEM board announcement (http://www.kissbox.nl/products_oem.html)  about “Up to 8 RTP-MIDI sessions in parallel†resp. 8 MIDI I/O pairs.
    Thorsten’s Post #24 mentions:
    “…and can confirm that the sessions can be routed to different "virtual cables", so that they are accessible as RTP1..RTP16…â€
    Are these RTP1..RTP16 connections unidirectional, so two of them are needed per Session?

Best regards,

Jo

Edited by nlate
Link to comment
Share on other sites

  1. Benoit/Kissbox talks in their RTP-MIDI OEM board announcement (http://www.kissbox.n...oducts_oem.html)  about “Up to 8 RTP-MIDI sessions in parallel†resp. 8 MIDI I/O pairs.

    Thorsten’s Post #24 mentions:

    “…and can confirm that the sessions can be routed to different "virtual cables", so that they are accessible as RTP1..RTP16…â€

    Are these RTP1..RTP16 connections unidirectional, so two of them are needed per Session?

Ooooooooppsss, big typo error on our website. It's not 8 RTP-MIDI sessions, but 16 !!!!

Thanks to you, nlate :smile:

 

And thank you globally for your comment.

 

To answer your two questions now :

 

- RTP-MIDI is implemented over UDP in all cases (Apple, KissBox, Tobias Erichsen, etc...). It's true that the RFC document says that TCP can also be used, but as far as I know, nobody is using it

- as I said just before, the OEM software supports 16 sessions in parallel (which means that up to 16 different RTP-MIDI nodes can connect at the same time to the OEM CPU). A session is equivalent to 1 MIDI IN and 1 MIDI OUT, thus you have then 16 MIDI IN and 16 MIDI OUT over the same link

 

Benoit

Link to comment
Share on other sites

It seems that my concerns about the cost of the OEM board is perceived as unfair criticism by some - that's why I'd like to explain why I think that the KissBox OEM is (edit: maybe) not a solution that fits my usecase. For others it might be the perfect solution.

 

I have about 25+ years of experience with good old MIDI. I say this to justify that I have collected a good number of MIDI gadgets over this time. That's why I am in the process of designing a huge, modular, programmable MIDI patchbay, partly based on MIDIbox. However, with Benoit and TK introducing KissBox OEM integration into MIDIbox land, I discovered that RTP-MIDI has potentially solved the same problem already that I am working on: making sure that MIDI signals sent out by a certain device reach another device in the "network". Using RTP-MIDI, one would simply not need a hardware patchbay, because it is inherently there already.

 

However, all the nice gear I have is not RTP-MIDI-ready. If I wanted to continue to use that "legacy" gear in an RTP-MIDI based setup, then I need to find a way of translating traditional MIDI into RTP-MIDI. I don't need additional features that my legacy MIDI gear doesn't understand anyways. I don't necessarily need this to be MIDIbox based either, but I'd surely love to because it is a platform I am quite familiar with. Let's say I want to integrate about 50-60 legacy MIDI devices. So far, this seems to be a costly endeavor using KissBox OEM boards at 100,- per each (edit: 8 16) devices for the RTP part alone (add MIDIbox hardware to that)... Benoit said they chose a microcontroller that has many more features - so I conclude there must be cheaper ways to achieve what I want. I do believe there is even a market for my usecase :smile: .

 

It also looks to me a bit like a hen-egg problem: RTP-MIDI will have a hard time taking off if there is not enough momentum. It's going to be hard to sell that technology if there are not enough compatible devices. But then again, manufacturers will only jump the train if there is demand from customers (us). I sincerely hope that NAMM will be a success for KissBox and RTP-MIDI.

 

Edit: Benoit corrected a typo, so that actually halves the cost and reduces my concerns significantly! Now I only need to find out where to connect a third IIC chain for the remaining 4 MIDI I/Os. Could PA8 and PA9 (IIC3 on STM32F4) be made available for such a task? Adding to a total of 16 physical MIDI I/O ports on the MIDIbox (4 UART based via J11E, 12 IIC-based via 3 IIC chains with 4 I/Os each)? Nothing but the router functionality has to run on the core...

Edited by ilmenator
Link to comment
Share on other sites

Hi *,

 

I am a bit shocked at the whining about price - it is a huge value for what it does. 

 

This is a big lvl up for those of us who need this feature set without an unreliable stack of kludges.

 

In my world pro gear costs pro money whether built or bought.  Obviously people forget what the MIDIbox feature set would cost if it were not a labor of love.

 

Thank you Benoit for opening the door for us to play with and create the state of the art.

 

Best regards

 

Tim

Link to comment
Share on other sites

 Now I only need to find out where to connect a third IIC chain for the remaining 4 MIDI I/Os. Could PA8 and PA9 (IIC3 on STM32F4) be made available for such a task? Adding to a total of 16 physical MIDI I/O ports on the MIDIbox (4 UART based via J11E, 12 IIC-based via 3 IIC chains with 4 I/Os each)? Nothing but the router functionality has to run on the core...

 

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.

Link to comment
Share on other sites

Haha TK, awesome!

Total tangent but another idea for this - is it possible to make a USB to RTP bridge using KissBox stuffs? Being able to use USB powered devices /without/ needing a full blown computer would be great for our live performances. MIDIO128 is my plan for largely removing the DAW, but means I have to use DIN MIDI devices. I can deal, but it limits some control surfaces and things.

I know the next gen CORE won't have USB host mode, but if another device did that could talk to CORE, that'd be awesome!

Link to comment
Share on other sites

It would be great if it would be possible to create some low cost bridge between gm5 (yes, there it is again m00dawg :wink: ) and a kissbox module. But i guess the bridge device would need some routing capabilities i guess. So it would be not so easy.

Edited by Shuriken
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...