BlueMidi - MIDI over Bluetooth

[Mikkel Gravgaard]

Hi there,

I've created an app that makes it possible to send MIDI via Bluetooth LE. The app runs in the background and integrates with existing apps that use virtual MIDI.

You can check out a demo video here: http://bluemidi.net

I've created BlueMidi, since several developers and users I've talked to wasn't very satisfied with the way Network MIDI works.

I'm very interested to hear if BlueMidi works with your apps, and if you have any suggestions for improvements.

If you want a promo code, just message me here :-)

Looking forward to any feedback!

Cheers,

Mikkel

[rafael_ollero]

Hello Mikkel, very interesting, can you send me a promo code for test?
Thanks

[Warren Stringer]

Suggestion: the app is $1.99 - promo codes are a hassle - just buy it.

Question for the developer: this looks like touchOSC. It the UI composer similar? How is it different?

[Fabio Di Mauro]

Why don't Work between two iDevices?
Why you need a Mac?

---------------------
Fabio Di Mauro / @sinapsya
sina...@yahoo.it
www.overthreshold.com
---------------------
Graphic Depth / Studio di Grafica Pubblicitaria.
www.graphicdepth.it
fa...@graphicdepth.it
Facebook.com/graphicdepth
---------------------

[Kate Stone]

Hi,

I am creating printed midi controllers that I would like to connect to iOS and Mac devices via BLE. Could your app be used to do that? We already connect our print to iOS using BLE to control our own simple app and have also created some Dj decks with our own Dj app. However we are not app developers and just want our printed devices to connect to existing apps using some kind of standard. Is this something you could help us with?

I gave a talk earlier this year showing some of the devices at the end, it was kind of fun!

http://www.ted.com/talks/kate_stone_dj_decks_made_of_paper.html

Thanks,

Kate

[Mikkel Gravgaard]

Hi Kate,

I just checked out your talk, very cool indeed!

As I see it, in order to control existing apps, you could make an iOS (or Mac) app that can understand the protocol that your printed controllers use, and map this to MIDI signals. It would probably need some kind of user interface, so that the user can touch the printed controller and then tell the app how that gesture should map to a certain MIDI message.

Then the app would run in the background and translate from your protocol to MIDI, and any existing app should be able to receive this. It's a bit like how the BlueMidi Host works, without the user interface part.

Feed free to get in contact with me if you want to discuss it further :-)

Cheers,

Mikkel

mik...@gmail.com

[Mikkel Gravgaard]

A good question - maybe v2 will have device-to-device, as well as Mac-to-device!

[Mikkel Gravgaard]

(Sorry for the extremely late answer)

BlueMidi is just a background app - it works together with existing apps such as TouchOSC (which is used in the demo video, btw). 

[Tom White (MMA)]

FYI...

 

There will be an "Information and Discussion Session" about MIDI over Bluetooth at The NAMM Show (Anaheim, California, USA) on Sunday January 26. The session is hosted by the MIDI Manufacturers Association in order to determine whether it is appropriate and feasible for MMA to create an interoperable specification for MIDI over Bluetooth. Presentations will be made by Apple, Yamaha, and Miselu.

 

The session is open to anyone that is developing products that use MIDI, but you must request an invitation. Email in...@midi.org with your contact info if you would like an invitation and more details.

 

Thanks,

 

Tom White

MMA

www.midi.org

[Sebastian Dittmann]

I've sent a request.

> --
> You received this message because you are subscribed to the Google Groups "Open Music App Collaboration" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to open-music-app-colla...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Joshua Pollack]

Hello all!

I'll be talking about our (Miselu) implementation of MIDI over
Bluetooth low energy (BLE), primarily presenting some early (scripts
are still running as I type) research regarding its performance with
our iOS software The results include numeric characterizations (e.g.
mean and std. of latency, max capacity, error rate, &c) as well as
interpretations of the data. The outline is fairly direct -- what we
built, how I'm measuring its performance, and the numbers.

I'm really looking forward to sharing our research, and wanted to try
and collect some questions ahead of time while I still have a few
cycles to possibly think about them. Does anyone have any questions
or concerns relating to MIDI over BLE that they'd like to see answered
or discussed? Details about our testing framework? Specific edge
cases to examine?

Joshua

[Zoltán Jánosy]

Hi Joshua,

I am developing a MIDI over BLE solution for Fishman Transducers. I am very interested in your results. Unfortunately I cannot attend the meeting personally, but Paul Gallo from Fishman will be there.

I have already implemented a slave mode device -- using the Nordic nRF51822 devkit -- which has a legacy MIDI IN port, and forwards MIDI data to an iPad 4 running iOS 6.1.3. This implementation uses the protocol developed by Patrick Madden (author of the Apollo iOS app). What I am seeing is a large variation of the latency, everywhere between 11.8..42.6 ms (this is total latency from MIDI IN to audio out on the iPad, when running Apollo and SampleTank -- just for comparison, when a direct USB MIDI IN connection is used, the latency is around 5.1..8.6 ms). Do you see the same figures, or can it be a configuration/software problem in either our device of Apollo? It is really difficult to find out what causes the delay and especially the large variation.

I would be very much interested to see results in different configurations as well, e.g., latency in different directions (into and out of the iPad), and in particular, whether implementing a master mode device would help to reduce the latency. My reasoning for the large variation is that the iOS connection event scheduler is not optimized for low latency, but for low power, therefore the iPad will not connect at regular intervals, but whenever it has time. If the master would be our device, we could probably schedule connection events more often (and in particular, regularly). However, I'm not sure how well iOS works in slave mode.

My other concern is robustness. To achieve enough throughput one needs to use the notification mechanism of BLE, which is not guaranteed to deliver the messages (my understanding is that -- in its current state -- using read and write messages on iOS would result in a very poor throughput -- certainly this may change in the future). Therefore some kind of journaling is needed (like in Apple's RTP-MIDI implementation) to avoid hanging notes, or loosing critical state change information (like Program Change). Or, an entirely different approach is necessary, implementing a stateless MIDI protocol, where not the actual MIDI messages are transmitted, but the current state of a synthesizer is emulated by the sending device, and the complete state info is transmitted (e.g., *all* the currently active notes, pitch bend state, etc.). This would solve the "hanging notes" problem, but certainly it would generate a large overhead (unless we use some clever compression and FEC). Did your implementation consider these points?

Best regards,
Zoltan

[Joshua Pollack]

Zoltan,

Thanks for your insights and questions, very useful!

Some of your questions I think will be answered with the data I'm presenting, but I can give you a summary here as well.  Yes, those large variations in latency *roughly* match what I've seen in my testing (avg latency of 19ms, variation of +/- ~14ms), which uses a different chip (CC2540) as well as different firmware (of course).  As to the cause, the testing I'm doing tries to isolate and measure ONLY the BLE aspect (I'm not doing note-to-audio latency testing), and I see similar (although slightly better) numbers, so I suspect that's (the BLE transport) where it's coming from.

With regards to robustness, I agree that the notification mechanism at first glance might seem unreliable and hence need some form of journaling (such as RTP-MIDI, as you point out).  And, the results I've gathered certainly do not rule out the possibility of needing to implement something like that, and we might need to in the future.

However, in experimental tests with large (>100000) numbers of packets, I've observed a 0% error rate using notifications from device->iPad, provided the data rate is not unreasonable. (e.g. a data rate (assuming 3 byte MIDI packets) of 100hz or less).  This, plus successful results of "burst" tests makes me not TOO worried about needing a more complex journaling protocol, at least, not for now.

I agree with your reasoning regarding the connection interval on the iOS device, I think that's the source of the latency/jitter as well.  Making the device be "master" and the iPad be a "slave" is a very interesting idea, it had not occurred to us... and certainly worthy of more study and research!  Though I doubt I'll be able to do so before my flight in a few hours ;), I'll look into this for the future.  (probably after the conference)

Joshua

--

[Zoltán Jánosy]

Hi Joshua,

Thank you for your response. I'm really sorry I can't be there to discuss these points in more detail. Maybe you could make your slides available after the show...

I have a couple of questions and comments:

• How do you measure just the BLE stack latency?
• In our application (guitar player on stage) it is can happen that the player gets out of the range of the radio once in a while, which will cause dropped messages. Dropped notes (missing Note Ons) are less of a problem, but hanging notes (missing Note Offs) are big trouble. This may be less of an issue with a keyboard player, who is not moving.
• The Nordic BLE stack does not support currently master mode. However, I also have the CC2540 devkit, so I am planning to implement a master mode device using that chip.

Have a good flight, and let's keep in touch!

Best regards,
Zoltan

[Joshua Pollack]

Hi,

Yep, my plan is to make the slides and raw data public after the show, possibly some of the custom software used for the testing under the GPL as well (don't quote me on that last one though).

Measuring just the BLE stack latency is difficult, and I'm sure there are improvements (and possible pitfalls) to my method, but the general idea is to send the same data to an iPad over both MIDI (physical cable) and BLE.  Then, the difference in arrival times is measured.

Let me know what you find with the CC2540 with regards to master mode, it will probably be a few weeks before I have a chance to try this on our end.  Very interesting idea, though.

Thanks, and yes lets keep in touch!

Joshua

--

[Patrick Madden]

Hi Joshua!

I'm the Apollo developer, and have been working with Zoltan on the hardware end of things.  He's got the most accurate performance numbers, but with an iOS 6 host.  In my experiments, I'm getting much higher bandwidth between a pair of iOS 7 devices, than with mixed iOS 6 and iOS 7 -- so there's clearly some tweaks that Apple can do to improve performance.  If I've can carve out the time, I'll try to do a more detailed study.

I have not seen any packet loss, but in theory it could happen.  For dropped connections, I'll likely add in something that will trigger all-notes-off.  I'm hoping to avoid tracking all the active notes on all the channels, to keep the processing demands for the app low; I've tried to set things up so that incoming MIDI packets get handed off with minimum delay.

It would be great if we can converge on a common protocol for BLE MIDI.   The MIDI way is to be as interoperable as possible, and to minimize end user grief.  Let's keep in touch, and see how far we can go!

[Zoltán Jánosy]

Hi guys,

How was the MMA meeting going? I'm eager to hear some details.

Best regards,
Zoltan.

[Tom White (MMA)]

Hi Zoltan,

 

It was clear by the attendance (over 50 people) that many developers would like to have an interoperable way to do MIDI over Bluetooth.

 

Apple showed their current thinking about how it should be implemented, and explained why, but has not completed their study so did not make a formal proposal.

 

Miselu and Yamaha (as well as Apple) reported throughput and latency/jitter test results (which were roughly the same in all three cases) which suggested the level of performance that can be expected, and perhaps the need to manage expectations in the market.

 

At this point we (MMA) are waiting for Apple to make a proposal.

 

Regards,

 

Tom White

MMA

 

---

Sent: Wednesday, January 29, 2014 6:55 AM
Subject: Re: MIDI over Bluetooth

[Zoltán Jánosy]

Hi Tom,

Thank you for the summary. Are the slides available, or is there any documentation of "Apple's current thinking"?

Best regards,
Zoltan

[Tom White (MMA)]

I don't think Apple is ready to expose their thinking yet...

They only did that last week because there was a unique opportunity to do so (the NAMM Show) and a limited audience.

But I am sure they will share more info when they are ready.

 

- TW

---