Teensy 3.6 USB MIDI host development status

PaulStoffregen · Feb 5, 2018

You could try capturing the communication while sending a small number of well known MIDI events. Maybe start with just note-on and note-off?

JKIM · Feb 5, 2018

I took some quick Beagle captures of MIDI incoming from the TB-3, it looks like pretty standard USB MIDI, although there is a second message following the standard message (for NOTE ON/OFF at least).

PaulStoffregen · Feb 5, 2018

That does indeed look like normal USB MIDI data. Maybe we should add some code to look for know VID-PID-interface combos?

JKIM · Feb 5, 2018

Here's the TB-3: Device VendorID/ProductID: 0x0582/0x017B (Roland Corporation)

I can get my T3.6 fired up with the host implementation and put the analyzer on it when there is a test build for this combo.

waterfield · Feb 6, 2018

the VT-3 Device VendorID/ProductID: 0582:017a Roland Corp.

ive been using alsa amidi because

First things required to use external keyboard are drivers. I have never seen a USB MIDI keyboard that would have drivers for Linux included in it’s package. That’s not surprising, since nobody would need them. It turns out that ALSA manages to communicate with 100% USB MIDI controllers! The trick is that MIDI over USB is a common standard that every single USB controller uses. Therefore, since ALSA supports that standard, Ubuntu users need no additional drivers to use such keyboards. Just plug it in a free USB slot and ALSA will immediately discover it. Well, it won’t display a message, but you can ensure it has found the controller by running aconnect -i which lists all readable MIDI ports – your controller’s name will be included in the list too! (By the way, that makes me wonder why does other systems needs drivers for that…)

aconnect -l returns

client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 20: 'VT-3' [type=kernel]
0 'VT-3 MIDI 1 '

amidi -l gives

Dir Device Name
IO hw:1,0,0 VT-3 MIDI 1

and to send a CC

amidi -p "hw:1,0,0" -S "b2 30 00"

amidi -L gives

RawMIDI list:
default {
type hw
card {
@func getenv
vars {
0 ALSA_RAWMIDI_CARD
1 ALSA_CARD
}
default {
@func refer
name 'defaults.rawmidi.card'
}
}
device {
@func igetenv
vars {
0 ALSA_RAWMIDI_DEVICE
}
default {
@func refer
name 'defaults.rawmidi.device'
}
}
}
hw {
@args.0 CARD
@args.1 DEV
@args.2 SUBDEV
@args.CARD {
type string
default {
@func getenv
vars {
0 ALSA_RAWMIDI_CARD
1 ALSA_CARD
}
default {
@func refer
name 'defaults.rawmidi.card'
}
}
}
@args.DEV {
type integer
default {
@func igetenv
vars {
0 ALSA_RAWMIDI_DEVICE
}
default {
@func refer
name 'defaults.rawmidi.device'
}
}
}
@args.SUBDEV {
type integer
default -1
}
type hw
card $CARD
device $DEV
subdevice $SUBDEV
hint {
description 'Direct rawmidi driver device'
device $DEV
}
}
virtual {
@args.0 MERGE
@args.MERGE {
type string
default 1
}
type virtual
merge $MERGE
}

paul

flocked · Feb 7, 2018

I didn't follow the latest updates on the 3.6 usb midi library. Does the library now support usb hubs so that I could connect several usb midi devices?

flocked · Mar 7, 2018

Sorry for asking again, but would this work with the library?
- Generating a midi clock with the teensy and sending it to 11 usb midi devices via a connected usb hub.
- Receiving notes via a usb midi keyboard and sending it to 2 usb midi devices..

Both at the same time and without any noticeable lag with the midi clock? I’m afraid that this many devices will make it all out of sync.

PaulStoffregen · Mar 7, 2018

flocked said:
would this work with the library?

This should be able to work.

Make sure you have enough hub instances. Most 7 & 10 port hubs are actually 2 or 3 four port HUBs.

Both at the same time and without any noticeable lag with the midi clock?

Assuming the 11 other devices don't add delay (either in their USB stacks or their code processing the incoming messages), this should all be achievable with less latency than a single note-on or control-change message would take on normal serial MIDI.

It will be slightly faster if you use Multi-TT hubs, assuming the receiving devices are 12 MBit speed. Multi-TT allows Teensy 3.6 to efficiently send all the outgoing data at 480 Mbit/sec and the hub simultaneously sends the packets at 12 Mbit/sec on each port. If you have a cheaper Single-TT hub, the 12 Mbit/sec packet get scheduled and actually transmit one at a time for each hub. Because the packets are so small and infrequent, I do not believe any human would be able to tell the difference. Still, if you want transmission to be truly simultaneous to all 11 outputs, Multi-TT hubs are the essential ingredient.

I’m afraid that this many devices will make it all out of sync.

I believe your fear is unfounded. I'm sure you'll discover it's incredibly fast.

But if this does turn out to have noticeable delay, please plan on sharing the code and a way I can try to reproduce it here (eg, using 11 other Teensy boards as the receiving USB devices). If there's any sort of problem in the USB stacks on Teensy, I will investigate and fix... but only when a reproducible test case is posted.

flocked · Mar 7, 2018

Okay perfect. I will try it after I get my 3..6

I might be blind but I can't find a way of sending midi clock to the usb devices. I only find functions for receiving/handling midi messages from usb midi devices..

PaulStoffregen · Mar 7, 2018

flocked said:
I only find functions for receiving/handling midi messages from usb midi devices..

There currently isn't much documentation for USBHost_t36, other than reading the USBHost_t36.h header file or looking at the examples in File > Examples > USBHost_t36.

But I can tell you the recently update put all the same functions in host mode. So if you create a "midi1" instance (again, see the examples) then you'd use midi1.sendRealTime(midi1.Clock). Of course this does nothing (but is safe to do) when no device is connected.

You'll probably create 11 device instances and call sendRealTime(midi1.Clock) on all of them. Should be pretty easy.

flocked · Mar 8, 2018

PaulStoffregen said:
There currently isn't much documentation for USBHost_t36, other than reading the USBHost_t36.h header file or looking at the examples in File > Examples > USBHost_t36.

But I can tell you the recently update put all the same functions in host mode. So if you create a "midi1" instance (again, see the examples) then you'd use midi1.sendRealTime(midi1.Clock). Of course this does nothing (but is safe to do) when no device is connected.

You'll probably create 11 device instances and call sendRealTime(midi1.Clock) on all of them. Should be pretty easy.

Thanks. I think I finished my Initial sketch of all midi routings I want. I also added some NoteOn/Off routing.

Code:

// … setup() … loop()

void digitaktClock() {
  Serial.println("Digitakt Clock");
  sendDigitaktRealTimeMessage(digitakt.Clock);
}

void digitaktStart() {
  Serial.println("Digitakt Start");
  sendDigitaktRealTimeMessage(digitakt.Start);
}

void digitaktContinue() {
  Serial.println("Digitakt Continue");
  sendDigitaktRealTimeMessage(digitakt.Continue);
}

void digitaktStop() {
  Serial.println("Digitakt Stop");
  sendDigitaktRealTimeMessage(digitakt.Stop);
}

 void sendDigitaktRealTimeMessage(uint8_t type) {
  digitone.sendRealTime(type);
  analogFour.sendRealTime(type);
  analogRytm.sendRealTime(type);
  op1.sendRealTime(type);
  as1.sendRealTime(type);
  nordLeadA1.sendRealTime(type);
  tt303.sendRealTime(type);
  beatstepPro.sendRealTime(type);
  space.sendRealTime(type);
  timeFactor.sendRealTime(type);
}
 

void digitaktNoteOn(byte channel, byte note, byte velocity) {
  Serial.print("Digitakt Note On, ch=");
  Serial.print(channel, DEC);
  nordDrum2.sendNoteOn(note, velocity, channel);
}

void digitaktNoteOff(byte channel, byte note, byte velocity) {
  Serial.print("Digitakt Note Off, ch=");
  Serial.print(channel, DEC);
  nordDrum2.sendNoteOff(note, velocity, channel);
}

//more handlers…

I get my 3.6 tomorrow and will try it out. I have two multi-tt hubs, so I should get the max bandwidth.

The only other thing I still don't get:
Right now I created many MIDIDevice instances and named them like my devices.

Code:

SBHost myusb;
//two 7 port usb hubs with each 2 "hubs" inside
USBHub hub1(myusb);
USBHub hub2(myusb);
USBHub hub3(myusb);
USBHub hub4(myusb);

MIDIDevice digitakt(myusb);
MIDIDevice digitone(myusb);
MIDIDevice analogRytm(myusb);
MIDIDevice analogFour(myusb);
MIDIDevice as1(myusb);
MIDIDevice op1(myusb);
MIDIDevice nordLeadA1(myusb);
MIDIDevice nordDrum2(myusb);
MIDIDevice tt303(myusb);
MIDIDevice space(myusb);
MIDIDevice timeFactor(myusb);
MIDIDevice beatstepPro(myusb);
MIDIDevice keystep(myusb);

But how do I really know which MIDIDevice is which real usb device? Is it about the order connected to my hub?

Also: What happens if one midi usb device isn't turned on. Will the code crash while calling it's MIDIDevice?

PaulStoffregen · Mar 8, 2018

You can't control which instance is which device. They are assigned in the order the devices are reported by the hubs, or the order you plug the cables.

But you can query the vendor & product ID or strings, if the devices have strings. Only ID numbers are mandatory.

flocked · Mar 9, 2018

Okay. I will receive my teensy tomorrow. I will report how things will work out with that many devices connected.

I now instead create 13 MIDIDevice instances. My two hubs have 13 max ports and I will only connect midi devices to them.

Like that:

Code:

//Simplified to just 4 devices for this example & missing setup, etc.
MIDIDevice midi01(myusb);
MIDIDevice midi02(myusb);
MIDIDevice midi03(myusb);
MIDIDevice midi04(myusb);
MIDIDevice * midilist[4] = {
  &midi01, &midi02, &midi03, &midi04
};

#define digitaktID      0x8600.  //Example ID.. Have to find out the real ID

void loop()
{
  for (int port = 0; port < 4; port++) {
    if (midilist[port]-> idProduct() == digitaktID) {
      midilist[port]->read();
    }
  }
}

Is there a way to get notified/find out if a usb device gets connected or disconnected so I can queue through all MIDIDevice instances? I couldn’t find anything in the library.

Or should I queue through all 13 MIDIDevice instances in the loop() and compare them to ProductIDs of devices I have. This would give me always an up to date info off all devices connected (In each of my music sessions I don’t necessarily have every midi instrument powered on).

Not sure what’s the best way to do. Queuering all the time in the loop() isn't maybe the best way to do.

fundorin · Mar 10, 2018

Is it possible to have the same functionality with Teensy 2.0++?
I've bought a couple of modules back in the days to build myself a midi wind controllers. All went great and I'm regularly playing music with them, using touch sensitive keys and a breath sensor.
But one thing that lack in my setup is a note velocity. Of cause, I'm using kind of a workaround with getting note velocity from breath CC (above some set up threshold, so that first note won't be sent with zero velocity.
Now I'm planning to exchange touch sensitive DIY pads with Korg Nanokey controller, which responds to velocity.
I want only one cable to go from my instrument to PC or tablet.
So, the plan is to feed midi data from Nanokey to Teensy via usb, alter it with some extra keys, add breath sensor data and then send it to the host. Since I don't have money to buy 3.6, I wonder, if it's possible to use one of my Teensy 2.0++ instead as a hub for usb midi controller, like it's possible with 3.6, as it seems?

PaulStoffregen · Mar 10, 2018

No, sorry, today Teensy 3.6 is the only Teensy model with USB host. Future boards beyond 3.6 will very likely also have USB host, but it's definitely not part of Teensy++ 2.0. With the old boards, you can make them act as a USB device, but they can't work as USB host to plug other USB devices into them. Today only 3.6 can do that.

fundorin · Mar 10, 2018

Thanks. Sad to hear.

flocked · Mar 10, 2018

I tested 13 different midi devices. 8 get detected perfectly:
Arturia Beatstep Pro
Arturia Keystep
AS-1
Nord Lead A1
Eventide TimeFactor
Eventide Space
Ableton Push
Generic midi interfaces

5 Midi devices don't get detected at all. No MIDIDevice instance, no productID/vendor ID and no midi messages . I tested them via powered USB hub and direct, lonely connection to Teensy:
Elektron Digitakt
Elektron Digitone
Elektron A4
Elektron Rytm
TE OP-1

I checked them with my Mac and they send midi messages for sure and also show a vendor and product id. I'm very sure they are native class compliant midi devices..
--
I suspect there is a bug, because it can't be a coincidence that really all 4 Elektron devices don't get detected. Any idea what is going on?

Thanks for all your help!

flocked · Mar 10, 2018

Update: I activated debug mode and connected one of the Elektron devices directly to the Teensy. These are the messages:

Code:

sizeof Device = 36
sizeof Pipe = 96
sizeof Transfer = 64
power up USBHS PHY
port change: 10001803
    connect
  begin reset
port change: 18001205
  port enabled
  end recovery
new_Device: 480 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
Config data length = 101
enumeration:
bNumInterfaces = 2
bConfigurationValue = 1
enumeration:
USBHub memory usage = 960
USBHub claim_device this=1FFF2020
USBHub memory usage = 960
USBHub claim_device this=1FFF23E0
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 92
MIDIDevice claim this=1FFF2E60
len = 92
MIDIDevice claim this=1FFF3520
len = 92
MIDIDevice claim this=1FFF3BE0
len = 92
MIDIDevice claim this=1FFF42A0
len = 92
MIDIDevice claim this=1FFF4960
len = 92
MIDIDevice claim this=1FFF5020
len = 92
Descriptor 36 =  ???
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 74
  Interface is MIDI
type: 36, len: 7
    MIDI Header (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 5, len: 9
    MIDI Endpoint: 1
      tx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
type: 5, len: 9
    MIDI Endpoint: 81
      rx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
MIDIDevice claim this=1FFF2E60
len = 74
  Interface is MIDI
type: 36, len: 7
    MIDI Header (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 5, len: 9
    MIDI Endpoint: 1
      tx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
type: 5, len: 9
    MIDI Endpoint: 81
      rx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
MIDIDevice claim this=1FFF3520
len = 74
  Interface is MIDI
type: 36, len: 7
    MIDI Header (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 5, len: 9
    MIDI Endpoint: 1
      tx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
type: 5, len: 9
    MIDI Endpoint: 81
      rx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
MIDIDevice claim this=1FFF3BE0
len = 74
  Interface is MIDI
type: 36, len: 7
    MIDI Header (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 5, len: 9
    MIDI Endpoint: 1
      tx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
type: 5, len: 9
    MIDI Endpoint: 81
      rx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
MIDIDevice claim this=1FFF42A0
len = 74
  Interface is MIDI
type: 36, len: 7
    MIDI Header (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 5, len: 9
    MIDI Endpoint: 1
      tx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
type: 5, len: 9
    MIDI Endpoint: 81
      rx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
MIDIDevice claim this=1FFF4960
len = 74
  Interface is MIDI
type: 36, len: 7
    MIDI Header (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 5, len: 9
    MIDI Endpoint: 1
      tx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
type: 5, len: 9
    MIDI Endpoint: 81
      rx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
MIDIDevice claim this=1FFF5020
len = 74
  Interface is MIDI
type: 36, len: 7
    MIDI Header (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 5, len: 9
    MIDI Endpoint: 1
      tx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
type: 5, len: 9
    MIDI Endpoint: 81
      rx_size = 512
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
Descriptor 36 =  ???
Descriptor 36 =  ???
Descriptor 36 =  ???
Descriptor 36 =  ???
Descriptor 36 =  ???
Descriptor 5 = ENDPOINT
Descriptor 37 =  ???
Descriptor 5 = ENDPOINT
Descriptor 37 =  ???

And here for the TE OP-1

Code:

port change: 10001803
    connect
  begin reset
port change: 10001805
  port enabled
  end recovery
new_Device: 12 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
Config data length = 131
enumeration:
bNumInterfaces = 3
bConfigurationValue = 1
enumeration:
USBHub memory usage = 960
USBHub claim_device this=1FFF2020
USBHub memory usage = 960
USBHub claim_device this=1FFF23E0
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 122
MIDIDevice claim this=1FFF2E60
len = 122
MIDIDevice claim this=1FFF3520
len = 122
MIDIDevice claim this=1FFF3BE0
len = 122
MIDIDevice claim this=1FFF42A0
len = 122
MIDIDevice claim this=1FFF4960
len = 122
MIDIDevice claim this=1FFF5020
len = 122
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 92
MIDIDevice claim this=1FFF2E60
len = 92
MIDIDevice claim this=1FFF3520
len = 92
MIDIDevice claim this=1FFF3BE0
len = 92
MIDIDevice claim this=1FFF42A0
len = 92
MIDIDevice claim this=1FFF4960
len = 92
MIDIDevice claim this=1FFF5020
len = 92
Descriptor 36 =  ???
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 74
  Interface is MIDI
type: 36, len: 7
    MIDI Header (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 36, len: 6
    MIDI IN Jack (ignored)
type: 36, len: 9
    MIDI OUT Jack (ignored)
type: 5, len: 9
    MIDI Endpoint: 4
      tx_size = 64
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
type: 5, len: 9
    MIDI Endpoint: 84
      rx_size = 64
type: 37, len: 5
    MIDI Endpoint Jack Association (ignored)
new_Pipe
new_Pipe
Descriptor 36 =  ???
Descriptor 36 =  ???
Descriptor 36 =  ???
Descriptor 36 =  ???
Descriptor 36 =  ???
Descriptor 5 = ENDPOINT
Descriptor 37 =  ???
Descriptor 5 = ENDPOINT
Descriptor 37 =  ???

It seems these devices are somehow detected as MidiDevice… But still: If I queue through my Mididevices I can't see them.

flocked · Mar 11, 2018

It seems that it finds the endpoint correctly, but doesn't create it's pipe because MAX_PACKET_SIZE is too small. In USBHost_t36.h I changed MAX_PACKET_SIZE to 512 and RX_QUEUE_SIZE to 256 and all Elektron devices + OP-1 get detected. Not sure if these are the perfect values as I don't know much about USB/midi. It was just a lot of trial and error.

flocked · Mar 11, 2018

@PaulStoffregen: Should I continue posting my discoveries and problems here or should I open Issue reports on Github? I don't wanna spam the forum, but maybe more people will see it here?

Two of the Elektron devices are still causing problems and aren't detected as MIDIDevice. The enumeration doesn't finish and Teensy crashes.

Code:

sizeof Device = 36
sizeof Pipe = 96
sizeof Transfer = 64
power up USBHS PHY
port change: 10001803
    connect
  begin reset
port change: 10001005
  port enabled
  end recovery
new_Device: 12 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
Config data length = 342
//Crash

In your code of enumeration.cpp this is true for both of these Elektron machines:

Code:

if (enumlen > sizeof(enumbuf)) {
   // TODO: how to handle device with too much config data
}

So I changed static uint8_t enumbuf[256] to enumbuf[512]. This is the new output. No more crashing of Teensy but still no MIDIDevice:

Code:

sizeof Device = 36
sizeof Pipe = 96
sizeof Transfer = 64
power up USBHS PHY
midi:port change: 10001803
    connect
  begin reset
port change: 10001005
  port enabled
  end recovery
new_Device: 12 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
enumeration:
Config data length = 342
numeration:
NumInterfaces = 5
ConfigurationValue = 1
enumeration:
USBHub memory usage = 960
USBHub claim_device this=1FFF2020
USBHub memory usage = 960
USBHub claim_device this=1FFF23E0
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 333
MIDIDevice claim this=1FFF3660
len = 333
MIDIDevice claim this=1FFF4520
len = 333
MIDIDevice claim this=1FFF53E0
len = 333
MIDIDevice claim this=1FFF62A0
len = 333
MIDIDevice claim this=1FFF7160
len = 333
MIDIDevice claim this=1FFF8020
len = 333
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 324
MIDIDevice claim this=1FFF3660
len = 324
MIDIDevice claim this=1FFF4520
len = 324
MIDIDevice claim this=1FFF53E0
len = 324
MIDIDevice claim this=1FFF62A0
len = 324
MIDIDevice claim this=1FFF7160
len = 324
MIDIDevice claim this=1FFF8020
len = 324
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 306
MIDIDevice claim this=1FFF3660
len = 306
MIDIDevice claim this=1FFF4520
len = 306
MIDIDevice claim this=1FFF53E0
len = 306
MIDIDevice claim this=1FFF62A0
len = 306
MIDIDevice claim this=1FFF7160
len = 306
MIDIDevice claim this=1FFF8020
len = 306
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 288
MIDIDevice claim this=1FFF3660
len = 288
MIDIDevice claim this=1FFF4520
len = 288
MIDIDevice claim this=1FFF53E0
len = 288
MIDIDevice claim this=1FFF62A0
len = 288
MIDIDevice claim this=1FFF7160
len = 288
MIDIDevice claim this=1FFF8020
len = 288
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 270
MIDIDevice claim this=1FFF3660
len = 270
MIDIDevice claim this=1FFF4520
len = 270
MIDIDevice claim this=1FFF53E0
len = 270
MIDIDevice claim this=1FFF62A0
len = 270
MIDIDevice claim this=1FFF7160
len = 270
MIDIDevice claim this=1FFF8020
len = 270
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 252
MIDIDevice claim this=1FFF3660
len = 252
MIDIDevice claim this=1FFF4520
len = 252
MIDIDevice claim this=1FFF53E0
len = 252
MIDIDevice claim this=1FFF62A0
len = 252
MIDIDevice claim this=1FFF7160
len = 252
MIDIDevice claim this=1FFF8020
len = 252
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 234
MIDIDevice claim this=1FFF3660
len = 234
MIDIDevice claim this=1FFF4520
len = 234
MIDIDevice claim this=1FFF53E0
len = 234
MIDIDevice claim this=1FFF62A0
len = 234
MIDIDevice claim this=1FFF7160
len = 234
MIDIDevice claim this=1FFF8020
len = 234
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 216
MIDIDevice claim this=1FFF3660
len = 216
MIDIDevice claim this=1FFF4520
len = 216
MIDIDevice claim this=1FFF53E0
len = 216
MIDIDevice claim this=1FFF62A0
len = 216
MIDIDevice claim this=1FFF7160
len = 216
MIDIDevice claim this=1FFF8020
len = 216
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 198
MIDIDevice claim this=1FFF3660
len = 198
MIDIDevice claim this=1FFF4520
len = 198
MIDIDevice claim this=1FFF53E0
len = 198
MIDIDevice claim this=1FFF62A0
len = 198
MIDIDevice claim this=1FFF7160
len = 198
MIDIDevice claim this=1FFF8020
len = 198
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 189
MIDIDevice claim this=1FFF3660
len = 189
MIDIDevice claim this=1FFF4520
len = 189
MIDIDevice claim this=1FFF53E0
len = 189
MIDIDevice claim this=1FFF62A0
len = 189
MIDIDevice claim this=1FFF7160
len = 189
MIDIDevice claim this=1FFF8020
len = 189
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 171
MIDIDevice claim this=1FFF3660
len = 171
MIDIDevice claim this=1FFF4520
len = 171
MIDIDevice claim this=1FFF53E0
len = 171
MIDIDevice claim this=1FFF62A0
len = 171
MIDIDevice claim this=1FFF7160
len = 171
MIDIDevice claim this=1FFF8020
len = 171
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 153
MIDIDevice claim this=1FFF3660
len = 153
MIDIDevice claim this=1FFF4520
len = 153
MIDIDevice claim this=1FFF53E0
len = 153
MIDIDevice claim this=1FFF62A0
len = 153
MIDIDevice claim this=1FFF7160
len = 153
MIDIDevice claim this=1FFF8020
len = 153
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 135
MIDIDevice claim this=1FFF3660
len = 135
MIDIDevice claim this=1FFF4520
len = 135
MIDIDevice claim this=1FFF53E0
len = 135
MIDIDevice claim this=1FFF62A0
len = 135
MIDIDevice claim this=1FFF7160
len = 135
MIDIDevice claim this=1FFF8020
len = 135
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 117
MIDIDevice claim this=1FFF3660
len = 117
MIDIDevice claim this=1FFF4520
len = 117
MIDIDevice claim this=1FFF53E0
len = 117
MIDIDevice claim this=1FFF62A0
len = 117
MIDIDevice claim this=1FFF7160
len = 117
MIDIDevice claim this=1FFF8020
len = 117
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 99
MIDIDevice claim this=1FFF3660
len = 99
MIDIDevice claim this=1FFF4520
len = 99
MIDIDevice claim this=1FFF53E0
len = 99
MIDIDevice claim this=1FFF62A0
len = 99
MIDIDevice claim this=1FFF7160
len = 99
MIDIDevice claim this=1FFF8020
len = 99
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 81
MIDIDevice claim this=1FFF3660
len = 81
MIDIDevice claim this=1FFF4520
len = 81
MIDIDevice claim this=1FFF53E0
len = 81
MIDIDevice claim this=1FFF62A0
len = 81
MIDIDevice claim this=1FFF7160
len = 81
MIDIDevice claim this=1FFF8020
len = 81
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 63
MIDIDevice claim this=1FFF3660
len = 63
MIDIDevice claim this=1FFF4520
len = 63
MIDIDevice claim this=1FFF53E0
len = 63
MIDIDevice claim this=1FFF62A0
len = 63
MIDIDevice claim this=1FFF7160
len = 63
MIDIDevice claim this=1FFF8020
len = 63
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 54
MIDIDevice claim this=1FFF3660
len = 54
MIDIDevice claim this=1FFF4520
len = 54
MIDIDevice claim this=1FFF53E0
len = 54
MIDIDevice claim this=1FFF62A0
len = 54
MIDIDevice claim this=1FFF7160
len = 54
MIDIDevice claim this=1FFF8020
len = 54
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 4 = INTERFACE
MIDIDevice claim this=1FFF27A0
len = 27
MIDIDevice claim this=1FFF3660
len = 27
MIDIDevice claim this=1FFF4520
len = 27
MIDIDevice claim this=1FFF53E0
len = 27
MIDIDevice claim this=1FFF62A0
len = 27
MIDIDevice claim this=1FFF7160
len = 27
MIDIDevice claim this=1FFF8020
len = 27
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT

Any ideas?

flocked · Mar 27, 2018

Okay I found the cause of problem: Both Elektron machines have audio interfaces built in. In the settings of these maschines it's possible to either select "Overbridge (the audio interface) + USB Midi" or "USB Midi only". If the option with Overbridge is selected, the device reports it's midi interface not as "midi protocol" but as vendor specific class. If I change to "USB Midi only" the Elektron machines midi interfaces get detected perfectly.

I spent some more days trying to find out, why they only send around 10-20 midi messages over USB and suddenly stop sending anything. I finally read today that this is a known bug of the two machines. So many lost hours…

PaulStoffregen · Mar 27, 2018

Oh, that's very good to know. Sorry it's taken such a painful path.

I have a version of the midi object with larger buffers on my todo list. Likewise for serial.

flocked · Mar 29, 2018

Nice

I had some more time to try my midi sync code. After some minutes all my devices start to get out of sync. I suspect that some midi clock ticks don't get send. Could it be that the usb midi receive interrupts cancel sending some of my midi clock ticks?

ETMoody3 · Nov 20, 2018

Pardon me greatly here but could you clarify exactly how to query the ID string (if present) of any specific MIDIDevice once the library has it?

Otherwise having a blast toying with possibilities. There is an old midi tool called the Zyklus Performance System that allowed for a whole range of swiss army knife functions on a set of midi signal paths - among which were channel matrices, embedded controller events, and arpeggiators. What I'm tinkering up here comes mighty close, and works so far.

Would appreciate this little bit of handholding.

ETMoody3 · Nov 21, 2018

Gah! Sorry, found it. Trees/forest.

Teensy 3.6 USB MIDI host development status

Well-known member

Active member

Well-known member

Active member

Member

Active member

Active member

Well-known member

Active member

Well-known member

Active member

Well-known member

Active member

Member

Well-known member

Member

Active member

Active member

Active member

Active member

Active member

Well-known member

Active member

Well-known member

Well-known member