BEBDigitalAudio
-
Posts
124 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by BEBDigitalAudio
-
-
Sorry for the long silence, but I am awfully busy with a big project involving RTP-MIDI... :rolleyes:
A new batch of CPU is being manufactured, we have already reserved a part of them for those interested in the MIDIBox/RTP-MIDI project (I could not answer to all of you who wrote a private message about the next availability of OEM boards, that's why I post a global message here). If the supplier keeps his promises, the boards will be ready for end of April.
Meanwhile, I hope that I will have finished to code upgrade discussed with Thorsten, so the boards will be delivered with this new firmware
-
Some news from the project...
Thorsten and me are working on an enhancement in the firmware, which will allow the MIDIBox CPU to "talk" with the RTP-MIDI module (for now, the KissBox board acts as a "transceiver" : everything being received from the MIDIBox CPU is considered as MIDI and forwarded to the network, and vice versa)
We are adding a complementary protocol (based on a SYSEX format) which will allow the MIOS to identify for example the remote IP address and port used by a session partner. Data exchanged over the protocol are not transmitted over the network.
A last for word (especially for Hugo106, not reachable in private message :question: ) : as explained, you can perfectly use the same local UDP port for thousands of different partners. For example, all web servers in the world are using port 80 for HTTP. All clients (Firefox, Safari, etc...) use the same port (and that's logic, otherwise, you would be unable to know to which port you need to talk), it's the job of the server to identify which sender's IP address has been used to send a packet. So there is "physically" only one port opened, and this does not limit the number of potential clients.
-
Apparently somebody started with the SID Emu:http://www.xcore.com/projects/sid-emulator-startkit
Great!!!
On my side, I started a group on the XCore for synthesizer implementation (I was working on a OPL3 port at this moment... never finished :no: )
This may give me the envy to return to my code and finish the OPL3...
-
Hello Hugo,
a session (in terms of RTP-MIDI) is just a set of informations about the partner (basically : the IP address of the remote device, the ports it uses, the session state (since there is a state machine for Apple protocol), and some other informations like the remote clock value (for clock synchronization). So it uses only a few words of memory for each session.
I think you are making a confusion with socket buffers, which are allocated on a socket basis (one socket = one set of buffers for RX and TX ). In the case of RTP-MIDI, we just need one socket for Session messages, and one socket for the Data messages. So we do not need a lot of memory to keep track of each session.
And to make things more clear : the reason we have limited to 16 sessions is simply because there is a four bits field in the protocol we use on the SPI, which are used to identify which session (or which remote partner if you prefer) is exchanging the informations in the message being received. And four bits gives 16 identifiers... hence the 16 sessions we are supporting.
Benoit
-
Hmmmm, weird
I tried to reload the file on the server, just in case. I made a test right now, it works for me. Can you check if it works for you too ?
-
And as promised, documentation is now available on the website, for those of you being curious of the secrets.
(This may even help to prevent the weird comments we have seen on some forums, by people making funny assumptions about our design :rofl: )
-
Hi Monokinetic,
thanks for reporting the typo... I will spank the guy in charge of the website :rolleyes: (ooops it's me)
As promised I will release the official firmware on the website probably today (I want to do that before the weekend), Thorsten will probably perform a final check.
The documentation will also be available for those of you who want to adapt the integration in MIOS to their own needs.
Benoit
-
And I forgot to tell you that the document explaining integration will be released publicly today or tomorrow, so you will see how to connect both modules with a flat cable (and how the protocol works)
-
And here we are finally !!!
First of all, sorry for being away from the forum for 2 weeks, but we are running like crazy at KissBox since I came back from NAMM (crisis? What crisis? :rolleyes: )
Thorsten and me managed to get a reliable communication at 10Mbps speed between the MIDIBox module and the KissBox one. We just need to make a last check, concerning the synchronization of the two boards (in case you reset the MIDIBox without resetting the KissBox or vice-versa), but this should be done very soon (I will send the updated firmware today.
We had also to face a funny problem with Apple's Ethernet adapter on Thunderbolt, which decided to work only when it wanted to... But the problem was finally in the Mac, not in the MIDIBox nor the KissBox :shifty:
So, finally, we are now able to deliver the first "MIDIBox ready" CPU board with the best possible performances. In the coming days, I will announce here how you can get the KissBox OEM CPU under "MIDIBox special conditions", we are finalizing this
Benoit
-
I am back from NAMM... and back to MIDIBox forum :smile:
By the way, I have been very surprized to see how RTP-MIDI is known now (many people already heard about it, and it seems that many projects involving it are on the way). It's also good to see how people are reacting when they know it's an open protocol. There is a clear feeling of rejection of anything proprietary. I can tell that a lot of news about RTP-MIDI will arrive this year on many new platforms (especially Android/Java)... and also new products from various manufacturers.
Back to our MIDIBox implementation, I am now working on an enhanced version of the firmware which should be able to work much faster than the current one. I should be able to send it to Thorsten in the coming days, I will let him announce when the tests will be done on his side.
I will also add the cable index support in this version, this may be very useful for any USB related projects
Benoit
-
- 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
- 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.
-
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
-
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:
-
Looking at the picture above it must be a per-piece price, and I'm quite shocked. Given that you need at least two of these (or similar) units, that amounts to a significant sum for a minimal setup... I'd love to be corrected, though!
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
-
On behalf of some of the US MIDIboxers I would like to apologize in advance for your trip to the US.
Any US MIDIBoxer planning to visit the NAMM is welcome by advance on our booth.
No need to apologize: I simply *love* to come to US (and to the NAMM in particular) :smile:
-
Just a small comment on what Thorsten saud just before : it's true that the KissBox CPU also allows to use the "classical" UART at 31.25kbps, but this uses a different software. The SPI firmware does not support this mode.
Note that the SPI firmware is a special one, and it is restricted to the OEM version.
By the way, I would like to apologize in advance for the time it may take for me to answer requests on this forum. I go to the NAMM next week (we have a booth here), and this takes most of my time.
Moreover, I wanted to make a special and dedicated version of the KissBox Editor for the RTP configuration (the standard KissBox Editor supports the complete range of our products, and it may be too complex to use for the MIOS application)
So I will probably be able to release the official SPI firmware and the related KissBox Editor only in the first week of February, when I come back from USA. Thank you all for your understanding
Benoit
-
Thank you all for these first comments (Thorsten did a great job too)
Now to answer your different questions:
Whats the Price of that RTP-MIDI OEM board?Everything depends on the size of the bulk. For now, we estimate the price between 90 and 100 euros for a bulk of 50 pieces
And will there be a DIY version, similar to what we have for the GM5?I suppose you mean the possibility of assembling the KissBox CPU yourself?
Then the answer is no. The problem is mainly around the main processor which is a leadless package with a 0.5mm pitch (sorry, but this chip only exists in this format). Moreover, the chip has a grounding pad underneath, which requires reflow soldering (in an oven if you prefer), and this is a SMD board....
So only automated placement is possible
Makes me wonder about MidiBox to MidiBox communication as well in cases where USB isn't ideal.Yes, this is perfectly possible with RTP-MIDI. You can easily make peer to peer communication.
You can also use very easily RTP-MIDI with iOS and Android devices, since RTP-MIDI is running over a standard IP stack.
By the way, in the specific case of iOS, you have to know that RTP-MIDI is a part of it (you do not need to install any driver or update anything). That means that any RTP-MIDI device can be reached over WiFi by any MIDI application running on iPad/iPhone/iPod (it appears as a standard MIDI interface) You do not need to connect any USB module to the iPad, so you can keep its wireless status
And, last but not least, RTP-MIDI is able to merge and split MIDI streams automatically. That means that if you "connect" two or more source devices to the same destination device, the receiving one merges all MIDI streams automatically. And in the other direction, a single RTP-MIDI connected to multiple ones automatically splits data to all destination (like a THRU box)
-
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: )
-
One SID per core with one MIDI channel per core... Mmmmmm :smile:
And if anybody else needs help to jump in the XMOS train, I can help (I know very well the train driver)
Benoit
-
It does not only look good, it's a *very* good idea.
By the way, the XS1 is not really a DSP, it more a microcontroller with serious DSP capabilities (it has a 32x32 multiplier with MAC instruction which is extremely good, but most of the instruction set is more oriented to general processing rather than signal processing)
Now, the idea of this board is excellent, because the XS1 are painful to use by amateurs. It has a ground pad under the chip which must be soldered, and this requires oven soldering...
I am discussing with Thorsten since a long time about the idea to port the MIOS on XS1, but we were blocking on the soldering problem. Now, it seems to be solved... and MIOS may exist very soon on the XMOS target.
MIDIbox goes RTP-MIDI...
in Design Concepts
Posted
Hi Jo,
yes, here are the latest news : a new batch of boards is leaving the factory today, so they are now available for sales.
Concerning the price, let me check today with my business partner if we keep or change the price (we have made a slightly bigger production this time, so the price can be readjusted)
Benoit