Teensy usb midi problem

ladansedesdamnes

Active member
I'm working on a program that receives midi data from a daw (sysex + note events) and processes this information.
I have simulation functions to emulate a sample midi data stream setup in my program, and everything works fine with that, I'm using several serial printouts to check all stages from message reception to processing and all that. I'm using straight Midi mode.
As soon as I try to use a proper midi output from my DAW (reaper), I enter reboot hell. If I'm fresh from a reboot, I'll be able to upload and get the teensy running, open the midi file in the daw, setup midi output without issues and get data input on playback. All great.
If, however, I upload anything to the teensy (or even just disconnect and reconnect serial monitor, remove focus from reaper and go back), that's that... Everything stops working: DAW starts complaining of not being able to open the teensy's midi out port - restarting it bears no effect; if I try unplugging and reuploading to the teensy, this will fail and the teensy will hang with the "no usb-connection" led steady blinking, and nothing will work until I perform a clean reboot and get everything back to square one.
Logging off does nothing, only a full reboot, which makes me thing of something like the com port staying active or something of the kind.
 
@ladansedesdamnes: I get similar behavior (Teensy is no longer recognized after upload) when using the Aria Maestro MIDI player (which I regularly use to drive my TeensyMIDIPolySynth project, & highly recommended it, if you need a good MIDI player). In that particular program, simply (re)selecting the Teensy as the MIDI output device makes everything happy once again. Is it safe to assume that your DAW has the ability to select the connected device, and can you (re)activate that selection...does that help/work ??

Hope that helps . . .

Mark J Culross
KD5RXT
 
It does have that option, but it never is able to re-connect to it. I tried resetting all midi devices to no avail. I also tried using a different DAW to check if it was a software problem, but any other seems to also be unable to communicate with the teensy midi device. It's as if the port used to set the device up stays "busy" and never responds again, if that makes sense.
I tried actually removing the midi device from the windows device manager, but a reboot is required so that doesn't help in the issue...
 
I tried with other midi hosts, and whenever the port hangs I get the same error as in midi OX:
"Teensy MIDI: There is not enough memory available for this task. Quit one or more applications to increase available memory, and then try again." - which is indicative of the port being considered "in use" by another application. My guess is there is some problem with it being released, but unsure why.
 
Almost any application will complain in one way or another if a device that is actively in use "goes away". Are you disconnecting your apps from the Teensy before reloading it (always a good idea), or are you simply "pulling the rug out from under the app" by reloading the Teensy while it is still actively in use (never a good idea) ??

Back to your DAW: if it doesn't have a way to actually execute a disconnect from the Teensy, what happens if you (NOTE: doing the following while everything is working nicely, without having caused any errors with unplanned disconnects, etc.) 1) shutdown the DAW, 2) reload the Teensy, then 3) restart the DAW ?? Does this sequence work successfully ??

I can confirm that midiOX gets really unhappy (requiring a complete PC reboot) if the Teensy is unplugged while midiOX has an active connection to it. In this specific case, the user deserves full blame for doing something that they shouldn't !! It is good & correct practice In Windows to remove any connections to any device before unplugging it (similar to formally ejecting a USB stick before unplugging it...old spinning drives used to take up to 10 seconds to finally flush everything to the disk, which could easily have been the cause of occasional drive corruption).

Mark J Culross
KD5RXT
 
Have you checked that this is not a problem in the sketch? Is the behaviour the same if you are using a simple example sketch?
 
Almost any application will complain in one way or another if a device that is actively in use "goes away". Are you disconnecting your apps from the Teensy before reloading it (always a good idea), or are you simply "pulling the rug out from under the app" by reloading the Teensy while it is still actively in use (never a good idea) ??

Back to your DAW: if it doesn't have a way to actually execute a disconnect from the Teensy, what happens if you (NOTE: doing the following while everything is working nicely, without having caused any errors with unplanned disconnects, etc.) 1) shutdown the DAW, 2) reload the Teensy, then 3) restart the DAW ?? Does this sequence work successfully ??

I can confirm that midiOX gets really unhappy (requiring a complete PC reboot) if the Teensy is unplugged while midiOX has an active connection to it. In this specific case, the user deserves full blame for doing something that they shouldn't !! It is good & correct practice In Windows to remove any connections to any device before unplugging it (similar to formally ejecting a USB stick before unplugging it...old spinning drives used to take up to 10 seconds to finally flush everything to the disk, which could easily have been the cause of occasional drive corruption).

Mark J Culross
KD5RXT
I tried enabling the midi output in Reaper, and playback happened without error. Disabling it, uploading code to the teensy and re-enabling the midi output, which didn't show any error. I managed to do this for a couple of times and then without any difference in process, it hung again. When I close reaper I can see a process hanging in task manager, which is unkillable (even with taskkil and wmic command line commands). I'm guessing that's related to the midi port not getting closed for some reason. Rebooted computer, tried same process and now was unable to go beyond one code upload before the hangup.

With midiox I seem to be able to control this, and consistently maintain the port available.

Have you checked that this is not a problem in the sketch? Is the behaviour the same if you are using a simple example sketch?
Yes, using the simplest sketch possible just outputting received midi messages has the same result.

Although this made me notice, unrelated to the original issue: unsure why but I suddenly seem unable to receive midi messages on the teensy at all neither from reaper nor from midiox. Using the simple read and output sketch messages are received.

My brain is starting to hurt
 
usb.read() always returns false in the main sketch but works fine in the test sketch.
There are no compilation errors.

Also now midiox is hanging whenever I try to turn the midi port off... I have to disconnect the teensy from usb for the program to become responsive again. I'm increasingly confused.
 
Fell into a rabbithole remarkably similar to this a while ago.

Synth Host system,Win7, Reaper, Presonus, MIO-10 and MidiSport usb-Midi interfaces and my Teensy usbMIDI project. Everything worked until adding and using the IDE.

From a cold start, Win7, Reaper, Presonus, MIO-10 and MidiSport usb-Midi interfaces, MidiOx whatever, and my Teensy usbMIDI project all worked correctly until.. starting up the IDE and uploading a new sketch then ran into similar stuff to Post #1 only it got far worse.

Windows BSODs sometimes needing reformat and reinstall.

Sometimes broke my sketch, sometimes filled with stuff from deep within Windows dungeons, saw stuff that looked more at home in Windows Device stack. Cross-linked clusters in Win Temp file.

The short answer, don't Dev on your DAW PC. Divide and conquer, Dev on its own PC and establish Din Midi links to DAW PC for debugging/ testing.
 
Fell into a rabbithole remarkably similar to this a while ago.

Synth Host system,Win7, Reaper, Presonus, MIO-10 and MidiSport usb-Midi interfaces and my Teensy usbMIDI project. Everything worked until adding and using the IDE.

From a cold start, Win7, Reaper, Presonus, MIO-10 and MidiSport usb-Midi interfaces, MidiOx whatever, and my Teensy usbMIDI project all worked correctly until.. starting up the IDE and uploading a new sketch then ran into similar stuff to Post #1 only it got far worse.

Windows BSODs sometimes needing reformat and reinstall.

Sometimes broke my sketch, sometimes filled with stuff from deep within Windows dungeons, saw stuff that looked more at home in Windows Device stack. Cross-linked clusters in Win Temp file.

The short answer, don't Dev on your DAW PC. Divide and conquer, Dev on its own PC and establish Din Midi links to DAW PC for debugging/ testing.
Well, in a weird way it's good to know I'm not the only one having issues. I had thought of using a different computer for midi sequencing BUT given the nature of needing the usb port for both uploading code and sending midi, I'd always need some software open to redirect midi traffic to the Teensy, which would still result in the same issues...
The only workaround I could think about was to create an actual midi circuit with din input and use the usb just for code and the din for midi stream, but that's a big delay and extra work for something that seamingly should work...
 
Ok, some more debugging.

I seem to have gotten it to work somehow for a short while. After going through 3 different cables without success and finally connecting through a different powered USB hub (changing usb port and - automatically - assigned com port) the sketch seems to come to life and everything works as expected. As soon as a hangup happens, everything goes back to the same problematic behavior.

I can't reliably reproduce this behavior, though. Sometimes after a reboot everything will work, but as soon as I fire up (any) IDE it stops - just as MatrixRat described. Other times even with a fresh reboot nothing works. I even tried removing all serial initialization and output to take that out of the equation, no change.

I can't really place where the problem might lie...
 
Perhaps when uploading, Windows does not have enough time to sort out the initial device disconnect (Cache flushes included) before Teensy usbMIDI is back online pestering Windows for a connection..

Make sure all your stuff is backed up!
 
So you have been using (and are using) an external USB hub all the time? Is it possible to test without this hub?
Also, the timing remark by @MatrixRat does make sense to me.

Paul
Good call (kinda feel dumb for not thinking of that)! So far (30 minutes into using it connected directly to motherboard usb port), it seems to have resolved the issue with hanging. Weirdly on my laptop, directly connected (without any hub) I still get the same hanging issue.
 
Some days gone by, @PaulS ' solution drastically reduced hanging, but it still happens from time to time with midi ox being unable to close the midi port, forcing me to reboot the computer. I believe this is tied to Serial monitor being open.
 
Ok, so for anyone coming to this thread in the future with a similar problem, here's the sequence of steps that seem to have resolved my issues:
  1. make sure midi ports are closed in midi host application
  2. close serial monitor
  3. upload sketch
  4. open serial monitor
  5. open midi ports
  6. send midi messages
  7. close serial monitor
  8. close midi port in midi host application
  9. repeat from step 3 forward
Connecting to a direct USB port (without a hub) helps, but once I got this sequence of steps, even on a usb hub everything works without problems.
 
Back
Top