MIDIbox goes RTP-MIDI...

[BEBDigitalAudio]

Hello everybody,

 

sorry for this very long interrupt, but I have been extremely busy with some projects which are finally online

 

My best wishes to all for this New year

 

Thorsten have made some extremely important changes to the bootloader related to RTP-MIDI support, and I have upgraded the MBHP user's manual with related informations, plus many other details coming from the MBHP users. I stronly recommend you to download the new manual and read carefully the changes.

 

Benoit

[Elektruck]

 Hello,

Last month I bought a PCB for the RTPMIDI_CORE_STM32F4 and an OEM Kissbox module from Benoit to experiment with.

 

I have some sync issues (hick ups) with Ableton and wanted to try if it would be better with this midi over ethernet stuff. I also really like the idea that I can reach my midibox stuff over ethernet with different PC's without switching cables. But I have some trouble getting this to work. 

 

The PCB finished OK, all LED's do what they suppose to do, I can reach my Kissbox module with the Kissbox editor. After setting up a session with the RTP-MIDI driver I was able to reach my STMF4 board over the ethernet with MIOS Studio and upload the project.hex file I created from the mios32_spi_midi app from the SVN Repository.

 

But I still see only the virtual midiport I created with the RTP-MIDI driver and I don't know how to acces the MIDI In/Out ports on the RTPMIDI_CORE_STM32F4 PCB.

In the mios32_spi_midi directory there is a mios32_config.h file and this seems the place to activate the ports but there's something strange:

 

// how many SPI MIDI ports are available?
// if 0: interface disabled (default)
// other allowed values: 1..8
#define MIOS32_SPI_MIDI_NUM_PORTS 4

// enable 4 USB MIDI ports
#define MIOS32_USB_MIDI_NUM_PORTS 4

 

It seems that both SPI MIDI and USB MIDI ports are all activated (4)

Why don't I see them anywhere?

and why it says that the interface is disabled by default (0) while there's a 4 behind NUM_PORTS?

[BEBDigitalAudio]

Hello,

 

I am not sure to understand what you want to do, so tell me if I am wrong. You would like to see the four MIDI ports (IN and OUT) over RTP-MIDI (like getting a kind of RTP-MIDI interface with four ports?) directly over RTP-MIDI?

 

If it's the case, the current firmware is not intended to work directly in this way. The RTP-MIDI interface is an "autonomous" MIDI interface, like the USB one and like the four DIN ports. In other terms, you have six MIDI ports, without correlation between them (if you prefer, what happens on one port has no direct effect on any other port)

 

If you want to get data from RTP-MIDI and forward them to a DIN port, you have to tell it to MIOS. In other terms, you have to write a "routing" software. MIOS will not route directly MIDI data from one port to another one (whatever the port type by the way)

 

As far as I remember, the demo code written by Thorsten was doing that on one port (I do not have the source code in front of me, I can check later if you want). I think it was getting everything from RTP-MIDI and send it to DIN port 1, and vice versa.

 

Benoit

Edited June 7, 2015 by BEBDigitalAudio

[Elektruck]

You would like to see the four MIDI ports (IN and OUT) over RTP-MIDI (like getting a kind of RTP-MIDI interface with four ports?) directly over RTP-MIDI?

 

 

Yes, that's how I imagined it would/could work, like the gm5x5x5 modules, only over ethernet instead of usb. 

But I also can imagine that it isn't that simple. I've quite some difficulty to understand all those digital/programming stuff. If I read it I understand not half of it, and I found out that I learn most by just starting to play with it. That's why I purchased your board, but maybe it's just too high level for me.

 

If it's the case, the current firmware is not intended to work directly in this way. The RTP-MIDI interface is an "autonomous" MIDI interface, like the USB one and like the four DIN ports. In other terms, you have six MIDI ports, without correlation between them (if you prefer, what happens on one port has no direct effect on any other port)

 

If you want to get data from RTP-MIDI and forward them to a DIN port, you have to tell it to MIOS. In other terms, you have to write a "routing" software. MIOS will not route directly MIDI data from one port to another one (whatever the port type by the way)

 

As far as I remember, the demo code written by Thorsten was doing that on one port (I do not have the source code in front of me, I can check later if you want). I think it was getting everything from RTP-MIDI and send it to DIN port 1, and vice versa.

 

Benoit

 

Ok, this I understand, so I uploaded the SPI MIDI Test app (I guess that's the demo code you mention), but if I send midi to the RTP-MIDI nothing happens on any of the onboard MIDI sockets.

 

I just started to read the MIOS32 Tutorial Code Examples, the first two are about sending midi packages and parsing them from one port to another. It seems a good starting point, but I don't know how to implement RTP-MIDI.

As I said, maybe it's a too high level for me, should I wait for a RTP-MIDI router app. But if it's do-able with some hints I'll like to try it myself.

 

Cheers,

Roel

[TK.]

*IMPORTANT*: you've to enable the "spi_midi" switch in the bootloader as described here:

http://www.ucapps.de/mios32_bootstrap_newbies.html

Without this option MIOS32 won't start the communication with the KissBox OEM!

 

 

 

The MIDI routing is done in APP_MIDI_NotifyPackage(), currently you will find following code:

 

void APP_MIDI_NotifyPackage(mios32_midi_port_t port, mios32_midi_package_t midi_package)
{
  switch( port & 0xf0 ) {
  case SPIM0: {
    MIOS32_MIDI_SendDebugMessage("SPIM%d: %08x", port & 0x0f, midi_package.ALL);

    if( midi_package.type == 1 ) {
      // -> kissbox messages are sent to terminal
      TERMINAL_KissboxReceiveMsgPackage(midi_package);
    } else {
      // -> all other messages are forwarded to the USB port
      MIOS32_MIDI_SendPackage(USB0 + (port & 0x0f), midi_package);
    }
  } break;

  default:
    if( midi_package.type >= 8 && midi_package.type <= 0xe ) {
      MIOS32_MIDI_SendPackage(SPIM0 + (port & 0x0f), midi_package);
    }
  }
}

which means:

whenever MIDI messages are received from SPIM0..SPIM15, a debug message will be print out, and the MIDI message will be forwarded to USB0..USB15

 

whenever MIDI messages are received from any other port, such as USB or UART, they are forwarded to the SPI

 

So, the MIDI1..4 -> SPI forwarding should already work

In order to forward SPI to MIDI1..4, just replace USB0 by UART0 -> done

 

However, if there is a functional problem with the KissBox OEM, Benoit has to help you on the troubleshooting; MIOS32 just handles the SPI transfer, but the more complicated part is at the KissBox OEM side.

 

Best Regards, Thorsten.

[Elektruck]

Hi !

I did indeed enable the "spi_midi" switch in the bootloader.

I didn't check the midi in ports, only the midi outs. And yeah, the first 2 midi in ports worked indeed! But the other two don't seem to do anything?!

After replacing USB0 by UART0, and compiling a new hex file, also the first midi out port worked! But the other three don't seem to do anything?!

 

Now I've got new stuff to check, I'm a big step further, but any suggestions about the not working midi ports are welcome.

Thanx!

[BEBDigitalAudio]

Hello Roel,

 

you should first check that the MIDI ports are working at electrical leve, even if the probability to have a failure here is very low (it's just a buffer connected to UART 2 and 3, nothing magic). At least , this will remove one cause of problems (and avoid to concentrate first on complex tests with SPI)

The easiest thing to do is to write a simple piece of code which sends the same MIDI message to all ports (without involving the communication with SPI to RTP-MIDI)

Maybe just write something which takes data from MIDI 1 input which sends the incoming data to MIDI 1, 2, 3, 4 outputs. Connect a master keyboard or anything else and check that you get MIDI on the four MIDI outputs.

 

To be honnest, I remember that I had to fight at the beginning with MIDI OUT 3 & 4, because I could not find the correct configuration to declare (on my MBHP, I had OUT 1 & 2 working immediately, but 3&4 remained inactive). I remembet that I had to change something in my program to let MIDI OUT 3&4 working, but I can't remember what. I will check in my notes.

 

Benoit

[Zam]

Hi All

I just order a RTMP card from Benoit, expecting doing nice things with it

I just have a question, as it's not clear to me right now.

Are midi ports, from and to, the RTPM card directly accessible from NG code with .NGC commande ?

--> ports=0000000011110000

are this third 4 digit "reserved, don't use it !" the ones used for this purpose ?

Or do I have to use USB, midi or OSC  (ports=1111111100001111) and route them to/from RTPM at mios side ?

Best

Zam

 

[Zam]

Hi

I'm playing with my new core/rtmp since yesterday.

Everything seem to work somehow, I'm able to connect to the core with MIOS studio through RJ45 (with some text bug when typing "help"...)

also updating ngc make the connection lost.

I'm able to send midi data to the rtpm card from computer over network (red led blink), and while setting MIOS router i'm able to send back data from usb to network

BUT i don't get the point to have NGC events sending/receiving midi data over RTPM ???

How can I chose SPI midi port in place of USB, OSC or 5pin midi ?

Best

Zam

 

[BEBDigitalAudio]

19 hours ago, Zam said:

How can I chose SPI midi port in place of USB, OSC or 5pin midi ?

Hi Zam,

the choice between USB, DIN MIDI and RTP-MIDI (via SPI) is just by selecting another index (it's something like SPIM0, I can't remember exactly without some source code in front of me)

Thorsten has provided also a kind of basic demo program in the source code tree, where you see the RTP-MIDI OEM acting as MIDI THRU. The rest of the code is exactly the same as for other interfaces. The only trick you have to know is that you must activate the RTP-MIDI in MIOS when you install it for the first time (using the monitor - but I think you have done it)

Tell me if you can't manage to do it with the previous advice, I will look in the source code I use when I will be back home

Benoit

[Zam]

Hello Benoit

Tks for help

I ask the question here in place of direct email, thinking it can help other in the future

 

So I think I start to undersand... I have to change the MIOS code and recompile the app to have access to SPI port

I'm just unable/unknowgable to do it

I first thinking SPI midi port will be available directly with MB_NG code and .NGC configuration, as we already have a "port=" parameter where we can chose 4usb, 4din and 4osc port and as there is 4 unassigned digit in this parameter I was hoping it's for SPImidi, but no

 

I activate SPI midi at bootloader side and check the MIOS midi router, loop work fine to and from SPI<-->USB, so I believe everything is fine at hardware

 

And a kissbox side question, is that normal that I get communication error with kissbox editor when trying to setup the second midi I/O (5006) ?

 

So it will be great to have a MIDIbox NG 1.036 with direct SPImidi available as port=0000000010000000 in NGC/NGR config file.

 

Best

Zam

 

 

 

[BEBDigitalAudio]

Hi Zam,

I am not sure of what you mean by "recompiling the code". I am not a specialist of MB_NG and the NGC, but I am a bit surprized that it does not take into account the SPI communication by default. The MIOS is fully transparent to RTP-MIDI communication, the MBHP can even be updated through the network (as MIOS Studio sees the RTP-MIDI interface as a normal one - which is the case by the way. RTP-MIDI is fully standard MIDI, after all )

Technically, the RTP-MIDI communication is available via SPIM0 handler. The code is exactly the same as with UART and USB MIDI ports, except that it shall be routed to SPIM0 rather than UART0, UART1, UART2

So, if the MB-NG does not use SPIM0, then yes, you should recompile it (I think there are many MB-NG specialists here who can help you with that and maybe recompile it for you)

About the second question... I assume you are using the Mac version of the KissBox Editor, and then you see an endpoint located on port 5006. I have to say that it's a bug of the Mac version of the KissBox Editor (arrgh, yes, there is a bug ). The RTP-MIDI OEM has only one endpoint (which supports multiple sessions in parallel), but the Editor displays a non-existing one. That's why it does not work.

For the last point, (the NG1.036), it's something for my friend Thorsten... Only him can tell if he will do it or not

Benoit

[Zam]

Hello Benoit

 

I just reply to your email

From my last w-e test, I confirm MIOS and the RTPM card communicate together, I can monitor all the midi I/O port with MIOS studio, and I see SPI coming in and going out (using the MIOS router), I just can't config a button nor a led to send/receive from the midi SPI, I think I miss something at MB_NG side but don't know what.

 

Ok good to know for the bug, It will save me time to try reaching this endpoint :)

 

Best

Zam

[Zam]

Ok... I just perform more test

I'm able to send/receive midi data (note) when pressing button with script at .NGR file and SPI1 port target (in place of USB1)

like this for exemple:

----------------------------------------------------
if ^section == 1

  if BUTTON:5 == 1
   change LED:3 127
   change LED:6 0
   send NoteOn SPI1 1 0x4a 127
   send NoteOn SPI1 1 0x18 127
   send NoteOn SPI1 1 0x18 0
   send NoteOn SPI1 1 0x4a 0
   change BUTTON:6 2
  endif

  if BUTTON:5 == 2
   change LED:3 0
   change LED:6 0
   send NoteOn SPI1 1 0x4a 127
   send NoteOn SPI1 1 0x18 127
   send NoteOn SPI1 1 0x18 0
   send NoteOn SPI1 1 0x4a 0
   change BUTTON:6 2
  endif

 exit
endif

-----------------------------------------------

I still not understand the SPI port choice at .NGC ?!?

 

Best

Zam

 

Edited May 11, 2016 by Zam

[BEBDigitalAudio]

Aaaaahh, I think I understand now... As a C programmer, array index starting at 0 is natural for me. The RTP-MIDI port is SPIM0 in MIOS32 (like first USB is USB0) in MIOS source code. But I think that NGC has a "human" approach, where first is "1", not "0".

That may explain what you see. Any NGC expert who can confirm ?

Edited May 12, 2016 by BEBDigitalAudio

[Zam]

Hello Benoit

yes .NGC (config) and .NGR (script) for MB_NG are "upper level" more human as you say :)

so when you define an event at .NGC it's like this:

event_button id=1 type=CC CC=1 chn=1 ports=10000000000000

will send CC1 over port USB1 first midi channel when first button in the srio chain is pressed

the ports= parameter is like this (from the manual):

Quote

Expects a 16bit binary value (0|1) to select the MIDI ports over which the event should send and receive:

• the first 4 digits enable/disable USB1..USB4
• the next 4 digits enable/disable MIDI1..MIDI4
• the next 4 digits are reserved, don't use!
• the last 4 digits enable/disable OSC1..OSC4

Example: following binary value (which is the default value)

ports=1000100000001000

will enable USB1, MIDI1 (IN1 and OUT1) and OSC1, and following binary:

ports=0000110000000000

will only enable MIDI1 and MIDI2

there is no definition for SPI port... (I try the reserved ones)

 

but at .NGR which is script that can be launched from .NGC like this:

event_button id=1 type=meta meta=runsection:1

I can use the SPI port to send midi like this:
 

if ^section==1

send CC SPI1 1 1 127

endif

exit

and my button will send CC1 ch1 value 127 over SPI1 (SPIMO) when pressed

this actually work, but I can't use script for all button, led and fader (Ain +Aout) I have.

 

I'm lost, It make non sense to have the SPI port actually working and not available from .NGC event configuration file

I'm sure it's nothing, and I'm just missing an easy point.

 

Best

Zam

 

Edited May 12, 2016 by Zam

[Zam]

Hi

I have now success using the RTP midi with my MIDIbox

There is one thing puzzling me. When trying to emulate two Mackie control at two different midi ports, SPI1 and SPI2

When I open let say 2 sessions with the midi setting (OSX) and configure different ports at MB_NG for two events AINSER (sending data from MIDIbox to DAW):

EVENT_AINSER  id= 1  hw_id=1  ain_mode=direct  type=PitchBend  chn= 1  range=map120  value=0 ports=00000000000000001000  #(for SPI1)
EVENT_AINSER  id= 2  hw_id=2  ain_mode=direct  type=PitchBend  chn= 2  range=map120  value=0 ports=00000000000000000100  #(for SPI2)

both event send midi data to both session 1 and session 2. In my use case 4 fader are moving at DAW (1, 9 and 2, 10 with two MCU configuration) when I move the fader connected to Ain

But if I setup different ports for two event CV (receiving data from DAW to MIDIBox)):

EVENT_CV  id=1  type=PitchBend  chn=1  range=map130  value=0 ports=00000000000000001000 #(for SPI1)
EVENT_CV  id=2  type=PitchBend  chn=2  range=map130  value=0 ports=00000000000000000100 #(for SPI2)

everything is fine, DAW fader 1 change only CV 1 (fader 1 move and not fader 9) and DAW fader 9 only change CV2 (fader 10 and not fader 2)

 

To simplify, all SPI midi ports going out from midibox through KissBox are merged to every session opened.

But it work fine the other way, one session send data from computer = one SPI port receive data at midibox

All router node at .NGC are set to 0...

I there some router at the KissBox ??? that merge everything in one way only ?

 

Best

Zam

 

 

 

 

 

[BEBDigitalAudio]

Hi Zam,

you are making a very confusion between endpoints and sessions (this is a common mistake in RTP-MIDI world. Some are even playing with that to try to fool people, isn't it Hugo? ). The confusion comes also from Apple's driver which mixes the names between endpoint and session). When you see that you create a session in Apple's driver, in fact you create a endpoint, not a session. Session will come later

A endpoint represents a MIDI path between the RTP-MIDI network and the application. Basically, this is where you will see the MIDI IN and MIDI OUT streams. In RTP-MIDI, an endpoint is represented by a UDP port, most of the time it's port 5004.

The KissBox OEM board supports one endpoint (while the MIDI2TR or CM-MIDI interfaces has 2, if you look to KissBox website). if you take the Behringer X-Control, it also has one RTP-MIDI endpoint.

The sessions are also MIDI paths, but this time between two endpoints. For example, when you click on Connect button on the Apple's RTP-MIDI control panel, you tell the local endpoint to connect with a remote endpoint. The RTP-MIDI protocol uses the session mechanism for that.

Let's make a practical comparison with phones : the phone in your house is an endpoint, with an input (in which you speak) and an output (from which you listen). The telephone in your neighbour's house is also an endpoint. When you call your neighbour, you dial his number and this establishes a session through the telephone network between the two phones. When you hang up the phone, you close the session. In most cases, a telephone can only manage one session (only one person can call you at a time). But you have certainly already use telephones for a group discussion. In that case, you can hear multiple people talking to you (even if you still have only one loudspeaker). When you speak in the microphone, all people in the call will hear you. You can not decide to speak to only one person.

That's exactly the same thing with the KissBox RTP-MIDI OEM board. it has one endpoint, and this endpoint can accept up to 16 sessions in parallel. And each session is a MIDI stream, with the 16 possible MIDI channels (the sessions have nothing to see with the MIDI channels, it's just an accident that you have 16 of each). In other terms, the RTP-MIDI OEM can discuss with up to 16 remote devices. But when two devices send MIDI data on channel 1, you can not distinguish who sent what, because they all appear on MIDI Channel 1. This mechanism is called MIDI Merging, and you get the same result when you use a MIDI Merger device.

In the other way, when you send something via a session, all remote participants connected to this endpoint will receive the same data, exactly like a MIDI THRU box.

Technically, the KissBox OEM is able to report the session number on which it receives MIDI data from a remote partner. So you could identify the remote partner. However, this has not been implemented in MIOS nor in KissBox firmware for now. I discussed a little bit about that with Thorsten, but we never implemented it. Now, it may be the good time to implement it finally, if you really need this. But we have to check with Thorsten if the control software will be able to deal with that.

Sorry for the long text, but I wanted to be as accurate as possible. if something is still not clear, don't hesitate to come back to me

Benoit

[Zam]

Hi benoit

Thanks for your time and explanation.

I think I mainly get it, except I use wrong terminology

So to be sure I understand well I will reformulate/quote what I see at my system with correct definition you give.

On 18/6/2016 at 8:50 PM, Zam said:

To simplify, all SPI midi ports going out from midibox through (spi midi) KissBox (endpoint) are merged to the two computer endpoint I create, with a Y like two session "wire".

Then I still have a problem here...

18 hours ago, BEBDigitalAudio said:

In the other way, when you send something via a session, all remote participants connected to this endpoint will receive the same data, exactly like a MIDI THRU box.

Why then the KissBox (endpoint) is able to separate data comming from two endpoint through two session, and forward them to two different SPI port for MIOS ?

 

18 hours ago, BEBDigitalAudio said:

Technically, the KissBox OEM is able to report the session number on which it receives MIDI data from a remote partner. So you could identify the remote partner. However, this has not been implemented in MIOS nor in KissBox firmware for now. I discussed a little bit about that with Thorsten, but we never implemented it. Now, it may be the good time to implement it finally, if you really need this. But we have to check with Thorsten if the control software will be able to deal with that.

OK, not sure If that's what I need, I better explain what I want to achieve.

 

I'm using MCU protocole to drive 16 physical fader at MB_NG side.

Protocol need one midi port for each 8 fader, using ch1 for most data BUT channel 1 to 8 pitchbend for 14 bit fader position data.

So I need two midi port each using 8 chn to perform this.

 

The targeted design is to have n core, each one for 8 fader,

Cores connected together (via SPI midi ?)

Master core have RTPM card, handle first 8 fader, and just act as router for other core from/to RTPM separate session, which have separate endpoint at other side so DAW can see n MCU device.

 

Best

Zam

 

 

 

[BEBDigitalAudio]

Hi Zam,

I am very sorry, I completely jumped over your post and I just realized today that you were expecting an answer. I will take a look to that today and answer as quick as possible.

(To be honnest, the last two months have been an incredible race for me, because of this : http://www.imodular-synth.com)

And if you take a look on bottom right of main page, you will see that this is also MIDIBox compatible

 

[Zam]

Hi Benoit

No problem, I'm also in a middle of consuming work (studio relocation...)

Nice new box you create ! What is the precision of the analog in/out ? are they able to handle DC signal?

Best

Zam

[Zam]

Hi

I'm back on this...

I think what I want to achieve request 4 session with 4 endpoint at kissbok dialling with 4 SPI midi at midibox side...

Best

Zam

 

 

[BEBDigitalAudio]

On 04/01/2017 at 10:22 PM, Zam said:

Hi

I'm back on this...

I think what I want to achieve request 4 session with 4 endpoint at kissbok dialling with 4 SPI midi at midibox side...

Best

Zam

 

 

Hi Zam,

sorry, I completely forgot to answer to this post.

You don't need 4 SPI to do that, nor you would need 4 endpoints. It would be possible to do that using the CableID to identify the session partner. Don't forget that a single endpoint in the KissBox can support multiple sessions in parallel. I would need to update the software to report the session partner using the CableID, but this is feasible (I already talked about this option with Thorsten a long time ago, but we never went further)

Sharing the same endpoint between various session is the key to save a lot of memory (something that Hugo106 did not seem to understand when he said that there was not enough memory in the OEM CPU )

[Zam]

52 minutes ago, BEBDigitalAudio said:

Hi Zam,

sorry, I completely forgot to answer to this post.

You don't need 4 SPI to do that, nor you would need 4 endpoints. It would be possible to do that using the CableID to identify the session partner. Don't forget that a single endpoint in the KissBox can support multiple sessions in parallel. I would need to update the software to report the session partner using the CableID, but this is feasible (I already talked about this option with Thorsten a long time ago, but we never went further)

Sharing the same endpoint between various session is the key to save a lot of memory (something that Hugo106 did not seem to understand when he said that there was not enough memory in the OEM CPU )

Hello Benoit

Thanks for reply.

Not sure I understand everything right now, but if it allow to have at least 4 independent session (not merged like now) it will be great

I know the analogy is not correct, but for my use case it should be like the USB cable which allow 4 midi port definition (16ch each ones).

I need to send/receive 32 pitch bend, 8 per ports chan 1 to 8.

If I'm the only one that need this it's little annoying to ask for it...

Best

Zam

[azhar]

On 1/14/2014 at 11:53 PM, BEBDigitalAudio said:

Things are not so simple with RTP-MIDI. The way it works is very different from classical MIDI approach with the IN/OUT/THRU.

 

First, you can perfectly build a setup where you have a single KissBox board on one side, and computers on the other. The KissBox modules can talk to each other, but also to computers. So it's not necessary two modules needed (apart if you want to make a MIDIBox talking to another MIDIBox over the network)

 

Second point : the particularity with RTP-MIDI is that it is based on the concept of session. A session represents a MIDI IN/OUT pair on application side. The difference with "classical" MIDI is that a single session handler can be connected to multiple session handlers in parallel (it's not KissBox specific, this is part of RTP-MIDI itself)

I will try to explain it simply : imagine that you have four RTP-MIDI devices on the network (A, B, C, D). When you want to exchange MIDI data, you need first to open a session (this is part of the firmware or the driver in case of the computer. You do not see it really, it's done transparently).

Let's say that A, B and C open a session with D (inside D sofware, there are "physically" four sessions then, it's not the same session shared between all participants). What is sent by A, B and C is sent automatically to the application, after ebing merged. In the other direction, what is send by application to D is sent automatically to A, B and C. In other terms, with RTP-MIDI, you do not need mergers and splitters, they are implicitely part of the protocol.

But B can also be connected virtually to C for example, etc...

This is called virtual patchbay

 

The current KissBox firmware supports 8 sessions in parallel so 8 devices (which can be computers, not only other KissBox CPU) can talk with a single MIOS application at the same time. The protocol we use on SPI allows up to 16 cables, so basically we can assume that a single RTP-MIDI node represents 16 MIDI cables at the same time (each of them with 16 MIDI channels of course)

 

The protocol we use on SPI uses the notion of Cable Number, which allows to identify the session sender. So, simply said, at a given moment, the MIOS application can see up to 8 devices, while there is only one physically connected....

 

Yes, I know, it's a bit hard to understand since there are many new concepts under RTP-MIDI. If you want, you can take a look on the download page of KissBox website, there are documents which explain more in detail how the configuration process works and what are the possibilities.

 

Sorry if I am not very clear, I work on RTP-MIDI since 2006, and many things are very clear for me, but not necessarily for newcomers in RTP-MIDI.

If you think that something needs to be explained more in detail, please ask, I will do my best to explain things simply.

 

Benoit

choose files... Click to choose files

On 1/13/2014 at 5:38 PM, BEBDigitalAudio said:

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

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 )

 

 

I am hard to print pcb with the schema is correct there are some components pngganti like lf 33 I replace with lm3940 low drop regulator but I do not menggunan The KissBox RTP-MIDI OEM board but usb midi not detected dila in pairs in stm32f4 brakout ver221 with rtp midi readi this follows schenaticnya