Need advice setting up MIDI-over-USB project

I've been reading around a lot and there are some things I am willing to work out on my own but I'm trying to prevent going down a dead-end path. I've done lots of HW and firmware development but never anything that had to connect to an OS.

I'm making a midi keyboard that needs to be recognized as a compliant device in Windows (and elsewhere I guess?). This would eventually be a custom board with the same processor chip.
If I get something with a native USB port (Leonardo for now) and use the USB-MIDI library I'm sure I can get the performance I need but I'm unsure of what development capabilities I will have:
The first part seems easy: install the MIDI library and make sure Windows registers it as a MIDI device. I can just internally program some note-ons to ensure it is actually sending MIDI.
-How will Windows respond to (this) midi device that keeps turning off and on (debugging, uploading, and start/stop)?
-If the USB port is tied up in the application, through what method would I debug and/or upload?
For debugging the MIDI output I supposed I would want to 'print' the MIDI messages instead of sending them out the USB, which possibly means I could use that port for uploading and debugging? That would of course mean constantly swapping something to use the USB port in application mode but not sure if that is practical or tedious.
Thanks for pointing the way!

Hello!
To create a MIDI keyboard recognized by Windows using a board like the Leonardo with USB-MIDI library, start by programming it to send MIDI messages correctly. During debugging and uploading phases, Windows may recognize the device disconnecting and reconnecting, which is normal. For debugging MIDI output, print messages to the serial monitor instead of sending them via USB to avoid interference. You can manage USB port usage by temporarily halting MIDI functionality or using separate communication channels for debugging. Plan for seamless switching between MIDI operation and debugging/uploading to streamline development and ensure Windows compatibility.

image
if board Leonardo you will able to use both midi and serial output, but not Uno. on uno maybe help softwareSerial

@kolaha
I have a Leo laying around but haven't otherwise figured out which one I need yet.

With those devices that can use the same port for upload and as a peripheral there is a specific procedure you need to do involving restarting the device and uploading right away with a particular timing. I forget the details, but there is a specific way to do it for those boards (micro)

That is the one you need to use. However, there are official Leonardo boards and then there are clones. some of the clones behave differently and have different pin-outs.

Most other replies to this thread are either irrelevant or wrong.

You program the Leonardo through a virtual serial port that gets created shortly after the board receives power. Start off trying to upload the LED blink example.

Sometimes, occasionally, the board will get into a state, due to loading bad code, and only then do you need to recover it like @LanGenz alluded to. The procedure is to hold down the reset button, set a download using the blink LED example, or any other simple code. Keep your eye on the output of the monitor window, and as soon as you see the message saying how much memory it consumes release the reset button.

This is some example code to get you going:-

/*
 * MIDIUSB_test.ino
 *
 * Created: 4/6/2015 10:47:08 AM
 * Author: gurbrinder grewal
 * Modified by Arduino LLC (2015)
 */ 

// works only with Leonardo, ProMicro and similar devices with MEGA 32u4 chips

#include "MIDIUSB.h"

// First parameter is the event type (0x09 = note on, 0x08 = note off).
// Second parameter is note-on/note-off, combined with the channel.
// Channel can be anything between 0-15. Typically reported to the user as 1-16.
// Third parameter is the note number (48 = middle C).
// Fourth parameter is the velocity (64 = normal, 127 = fastest).

void noteOn(byte channel, byte pitch, byte velocity) {
  midiEventPacket_t noteOn = {0x09, 0x90 | channel, pitch, velocity};
  MidiUSB.sendMIDI(noteOn);
  MidiUSB.flush();
}

void noteOff(byte channel, byte pitch, byte velocity) {
  midiEventPacket_t noteOff = {0x08, 0x80 | channel, pitch, velocity};
  MidiUSB.sendMIDI(noteOff);
  MidiUSB.flush();
}

void setup() {
  Serial.begin(250000);
  Serial1.begin(250000);
}

void loop() {
    int val;
  val = random(20,100);
    noteOn(0, val, 64);   
    delay(100);
    noteOff(0, val, 64);
   delay(800);
   Serial1.println(val);
}

Note it also prints messages out of the Serial1 pins, to see them open the Serial1 monitor window.

Thanks for the different replies, they all helped in some way.
I did not have a Leo so bought one and hooked it up to my laptop in Starbucks.
I finally got clear headed enough to just load the blink.ino and it blinked but I did have some problems with print statements because the serial monitor window said 'can not connect, select board and port's. Turns out this seems to be a bug in the current IDE but manageable.
I then tried the NoteOnNoteOff sketch and was pinging my VSTs with little trouble! It still having weird serial monitor moments. Although there are clearly print statements in loop() they aren't executing. A print statement in setup() does print out though so I can't blame the HW.
It's funny, I'm so used to building things up from scratch that it didn't occur to me to look for a working example as a starting point for my project.
It would be nice to figure out why those print statements in NoteOnNoteOff arent working.

Also, I think I was having a hard time understanding the USB connection and how it was sending both app data (midi notes) and debug prints. My understanding (from reading) is that some ports can't be used by both the app and the IDE, but I can't recall any details and until now didn't care lol.

OK try replacing the

Serial1.println(val);

with

Serial.println(val);

Then just open the serial monitor from the sketch window.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.