Midi gloves

[Bongolutz]

Hi there, i am knew to audafruit wearebels. I want to built a midi glove connected over wifi. At First step i want to inclued a 6doF to detect motion of the hand, four pressure Sensors in the Fingers.
Is ist possible with the Flora? Which Sensors can i use, what do i Need additional? And what do i Need for wifi with the Flora?
Thanks dir help and ideas.
Manuel

[adafruit_support_carter]

Is WiFi a requirement? That adds a level of complexity the Flora can't natively support.

Have you seen these guides?
https://learn.adafruit.com/midi-drum-glove
https://learn.adafruit.com/power-glove- ... controller

[Bongolutz]

Wifi Would be important. If flora doesn‘t support wifi directly, is it possible to use the Elements out of the feather serie?
Huzzah 32 esp
Woven conductive 20cm
Short flex. Sensor
Touch Sensor breakout cap 1188
Adafruit LSM6DSOX + LIS3MDL FeatherWing - Precision 9-DoF IMU
Is this all compatible to the huzzah 32?
Thanks for help, i am really knew to this.

[adafruit_support_carter]

Would bluetooth be an option?
https://learn.adafruit.com/bluetooth-le-midi-controller

The powerglove also uses BLE.

[Bongolutz]

If wifi is Not possible, of course i can use ble.
But if anyone has a solution for midi over wifi sens me your ideas!

[sid8580]

BLE MIDI is ok for some users, for some applications but I can say from personal experience that the latency is really hard to deal with. At its absolute best (your MCU doesn't slow it down and the code is efficient) the lowest latency BLE can operate per its own spec is 7ms, which is ~7 times slower than 5-pin serial MIDI, and in practice the latency is commonly between 20-100ms (really noticeable lag).

I'm not trying to poo-poo BLE since it is a handy way to communicate with a lot of devices that have it built in, and for some things it's just fine. Just be aware of these limitations and set your expectations accordingly... and if that isn't good enough, keep searching for better options (they exist).

[Bongolutz]

Hi Sid8580,

seems you have tried something like this before....thanks for the hint with the latency. In the end it will be important. But for the beginning i will try it out and see how close i will come to my idea. I know BLE isn't that fast. I thought about touch OSC ( is that faster?), thats why i wanted to implement wifi. In the end cables would be the fastest, but you said there are better options...what do you mean exactly? maybe you can give me another idea...
As you see i have ideas..the knowledge will follow...
greetings manuel

[kevinjwalters]

The Enhancia Neova MIDI ring claims:

Wireless Communication Less than 1ms latency 15 meter range

I had one for a few days in a box but it was a gift, sadly, so it's gone now :) I'm pretty sure it's not Bluetooth but shows that radio can be viable for low latency communication.

[sid8580]

(This turned out to be pretty long, sorry about that, but hope it helps)
In the end if you want the best of the best in terms of accurate & lag-free data, and want to spend minimal time building it, I think you'd better go wired ;) But yeah it's great to have a wireless option especially if you want to add dance or performance art elements to a musical performance. I included both options on my device - even if at the very least, for testing (test wired unless you're specifically testing the wireless communications, or you may end up chasing lots of problems that lie elsewhere!).

I thought wifi was a bad idea because I didn't want to implement a TCP/IP stack on my MCU, figured that would eat into my processor cycles too heavily and my design is already rather processor-intensive. BLE was too laggy. XBee and most other lightweight RF transceivers meant for controlling radio controlled vehicles and building automation just weren't fast enough, didn't have decent enough range, etc... until I found RFM69. It can transmit roughly 8 times faster than old serial MIDI and has a potential range of hundreds of meters, even kilometers with a good antenna - in a room, on a stage or any other conceivable performance venue, even with a minimal antenna you can easily hide in your design it's got much better range than BLE or wifi (I can run circles around my house and still hear those MIDI notes triggering inside!).

In other words RFM69 is cheap (you can get a pack of 4 transceivers for $20), and more than meets the bar of MIDI 1.0. MIDI on a bit-for-bit basis is easy to break down and send across an RFM69 link without a huge & complicated library. It connects and disconnects on a dime (with a button press), no long wait for complicated pairing or negotiation. In my design I wanted to avoid stuck notes and missed MIDI commands so it's set up to verify each command sent with a reply from my receiver module, and it takes 3ms (this includes the verification back to the controller). Considering RF transmissions aren't the only thing that takes time in my device(s), I think that's pretty good. I wanted response times to be under the threshold of human sensory detection so, goal achieved.

Now if you REQUIRE the level of detail OSC provides (or are communicating with a computer that speaks OSC and that is it), and can't get away with using MIDI 1.0 commands, might have to revisit wifi. I still wouldn't do that though. If you need complex control messages created from the glove data, consider outsourcing that work to a receiver module. You will need one anyway, if you plan on using your device without a computer in between (directly connected to an instrument via USB or serial MIDI). So you could let the receiver do the heavy lifting while keeping the wireless payload light between them (limited to sensor data). And still use it with a computer via USB.

Someone mentioned the Neova Ring, which is a good example of a device sending a sensor stream to a receiver unit (Neova Hub). The hub does all the thinking, the ring just streams sensor data. This is a good design model since it allows you to avoid making the wearable needlessly complicated.

It all depends on your endgame here. My goals involved standalone MIDI capable synths and CV, and I wanted to be able to control everything regardless of a computer intermediary, and I wanted to be able to reconfigure what I was sending via an onboard UI, where I could set up programmable macros. For better or worse, I've been working on this for 3 years now and though I'm happy with where I'm at today, I wish I'd considered using the receiver for the bulk of the processing earlier on. Best of luck!