MIDI Demo - use interrupt EP instead of Bulk

[galaviel]

Hello All,

Just finished browsing the MIDI demo.

I am considering building something similar to megadrum.info, i.e.
electronic
drum trigger to midi converter.

Obviously latency is at the utmost importance here as you are playing
real-time and need the MIDI delivered to the PC with minimum latency,
otherwise it would
not feel real.

I see that the MIDI demo is using BULK rather than INTERRUPT; what
would it take to convert it to using Interrupt? (actually only one
Endpoint is needed: IN).

Obviously the EP descriptors will have to change to use
EP_TYPE_INTERRUPT, and also PollingIntervalMS would have to be
specified.

Are any other changes required? or would the generic functions called
from midi.c, SendMIDINoteChange(), have to be changed too ? meaning,
are
the functions Endpoint_IsReadWriteAllowed(), Endpoint_Write_Byte(),
Endpoint_ClearIN() work on interrupt as well as BULK?

Many thanks in advance,
any insight on this topic would be highly appreciated :)

Gal.

[galaviel]

I'm answering myself ...

The answer seems to be Yes.

changing the endpoint from BULK to INTERRUPT and setting the interval
to 1 seems to work OK.

MIDI is received on the Windows XP (using MIDI-OX midi input monitor)
the same way as the
vanilla LUFA demo which uses BULK. Obviously I could not tell any
speed difference, both are
really fast (no other devices are connected to the bus).

I guess BULK vs. Interrupt is not really logically important to MIDI;
the data is the same.

Gal.

[Dean Camera]

Gal,

Sorry I wasn't able to reply in time.

What you have might well work, but the USB MIDI specification requires
BULK type endpoints, and thus the driver might refuse to enumerate
MIDI devices with INTERRUPT type endpoints instead. You said it all
appears to be working, however note that many OSes cache the device
descriptors, so that if the Device Descriptor remains the same, the
rest of the descriptors aren't re-read. To really test whether you can
change out the endpoint types, increment the Device Descriptor's
ReleaseNumber element by one and re-test, which will force the
descriptors to be re-parsed by the host.

If you find out it doesn't work after that don't worry - BULK should
be plenty-good for your application and you'll only notice degradation
when the bus is *very* busy, such as an extended read from an attached
fast flash disk on the same bus. Most PCs have several root controller
hubs, so as long as your MIDI device is on a separate root hub to the
other devices keeping the bus busy, you'll be fine even then.

To answer the other portion of your original question; no, you do not
need to make other changes other than to change the endpoint type in
the Endpoint_ConfigureEndpoint() call in MIDI.c (note that this will
only work with the LowLevel MIDI device demo, as the internal MIDI
class driver is fixed to always using BULK endpoints). I've designed
the LUFA endpoint/pipe APIs in such a way that the type of the
endpoint or pipe doesn't matter when using the API functions, unless
you are using a function specifically for a particular endpoint/pipe
type.

Cheers!
- Dean

[galaviel]

Hi Dean,

Thanks again for your elaborate reply :)

> To really test whether you can
> change out the endpoint types, increment the Device Descriptor's
> ReleaseNumber element by one and re-test, which will force the
> descriptors to be re-parsed by the host.

Done it , seems to work OK (Windows XP SP2, haven't checked on Linux
or Mac).
Thanks for pointing out that USB Spec required MIDI endpoints to be
BULK rather than INTERRUPT,
this alone might cause me to keep it BULK (stay compliant ... ).

> To answer the other portion of your original question; no, you do not
> need to make other changes

Ok good to know I've got it covered.

> the Endpoint_ConfigureEndpoint() call in MIDI.c (note that this will
> only work with the LowLevel MIDI device demo, as the internal MIDI
> class driver is fixed to always using BULK endpoints).

What's the internal class driver? are you reffering to host-side
driver for e.g. Windows?

Again many many for your excellent reply :)

Gal.

[Dean Camera]

Gal,

> What's the internal class driver? are you reffering to host-side
> driver for e.g. Windows?

The Class drivers are a relatively new addition to the LUFA codebase,
and demos for them can be found in the Demos/ClassDriver/ directory of
the latest release. Basically, they are a bunch of optional driver
code for the standard USB classes, but integrated directly into the
LUFA library core.

In older demos, the LUFA library exposed a set of low level USB APIs,
which the user could then use to implement the USB classes (MIDI, CDC,
Mass Storage, etc.) that they desired into their application. However,
when all the user wanted was to make a device with one or more of the
standard classes, this caused a lot of duplicated code to be written.

To combat this, I've written a small set of standard USB class
drivers, for both USB device and host modes, which take care of all
the low level USB code for you, and expose a set of higher level APIs
specific to that class. You'll see in the demos how that works - you
define a context structure of the class you want to use, fill out its
configuration parameters, and then pass it to the appropriate class
driver APIs as needed. It makes your user code much easier to read,
much shorter, allows for bug fixes to the class driver and library to
propagate to all user code at once, reduces the number of changes
needed between LUFA upgrades and allow you to focus your application
code solely on your actual application rather than the USB
functionality.

In your case, the Demos/Device/ClassDriver/MIDI demo shows off the
LUFA MIDI Device Class driver. Compare it to the one in Demos/Device/
LowLevel/MIDI and see how much cleaner and easier to read it is :).

> Again many many for your excellent reply :)

No problem! Good luck with your project!

- Dean

[glamp...@gmail.com]

Dear Dean and Gal

I just stumbled across this thread - thanks to you both for the insights. And thanks to Dean for a wonderful open-source gift to the world!

I, too, would like to build an embedded controller for a MIDI percussion instrument. Gal: did you have much/any success? Dean: do you know of others who have done so? I would love to discuss this first-hand with someone!

I have built a few projects on the AtMega32U4, including a weather station, Christmas flashy lights and various counters. For the weather station, it was serial-over-USB. Do you think this same chip is recommendable for MIDI, or is there perhaps one which would perform better in this application? For percussion, it won't really be more than 4 simultaneous note-on messages (but maybe allow 5 or six for any cephalopod-types) - as Gal says: the real issue is latency.

I bought and built up two megadrum.info boards and the latency is satisfactorily low. For a live drum feel, I like to keep percussion response lower than 6ms and I managed to get the megadrum down to 3ms for single strikes and 5ms for when the kit is very busy. This board is an AtMega16 - the old one with the huge, gnarly package, so I suspect it would be fine? (but what do I know? I'm just a trombonist...)

With the greatest respect and gratitude for the helping hands

Gareth