How to usb MIDI to nano?

i have a half dozen arduino nanos (ATmega328P)

and a trinket MO (ATSAMD21)

i want to sequence a drum machine, using an arduino to receive MIDI note messages via USB, and turn them into short pulses. i have 20 years of audio dsp programming experience, but i have some severe PTSD and no longer deal well with anything i perceive as a needless problem. sure, that's on me. i've already got wrapping micros() so i'm set with the stuff dsp can touch.

there is a MIDIUSB library but it doesn't support these boards.

there is a USBMIDI library which says it "does", but it's built around the arduino serial() functions. i don't want to learn about that. i don't want to spend my day wondering which parameter of serial() i have no knowledge of, is affecting timing, or other foreseeable or unforeseeable problems. trust me, i foreseee problems you would never imagine, and that messes me up something fierce, frequently.

there are, apparently, more midi-usb related libraries, but there seems to be even less documentation of these.

my choices now are either:

A) wait three months until property tax season is over and i can afford to buy an ?arduino leonardo? with a USB port so i can use the library with the simple read function.

B) spend my free time going through hell figuring out how to use a serial function i have no interest in.

C) whine on the forum and see if anyone has insight into a simple solution for this simple function that doesn't involve so much crap.

posting this might even elicit useful responses like, this, or that library, actually elicits the timing responsivity i am definately going to be immensely oversensitive to.

i guess "it's cool" that everyone is so much more interested in getting midi data into the pc, but folks.... computers are pretty freaking good at generating midi data, so it would be awesome to see more resources about that. i've got a lifetime's experience of generating midi data but i don't have twenty dollars. life isn't fair but it is amazing how everything seems to always suck so much more for me than it needs to.

can i get a timely pulse out of my currently purchased nano from the pc, please?

This project seems to be related to your quest:
https://create.arduino.cc/projecthub/tyrkelko/let-s-build-an-sn76489-usb-midi-synth-with-arduino-nano-ec2a52

The easy way to get MIDI data into an Arduino is to use Serial (the original) MIDI. If you want to use USB MIDI you either need an Arduino that can act as a USB Host (maybe a Due?) or you need to add hardware (USB Host Shield or equivalent) to an Arduino, like the Nano, which does not have native USB Host capability. The project above uses the SN76489 chip to do the USB interface.

If you can copy the above project enough to get the USB MIDI data into your Nano, you should be in good position to make your Nano do whatever you want with the MIDI signals.

anything requiring parts is impossible for some months.

this library

claims to accomplish the task. the problem i see is, as described, the use of unfamiliar serial() protocols, and the damnable example, which presents me with:

#include <usbmidi.h>

void setup() {
	Serial.begin(9600);
}

void loop() {
	//Handle USB communication
	USBMIDI.poll();

	// While there's MIDI USB input available...
	while (USBMIDI.available()) {
		u8 b = USBMIDI.read();

		// Output the byte to the Serial interface.
		Serial.print(b >> 4, HEX);
		Serial.print(b & 0xf, HEX);
		Serial.print('\n');

		// Echo the byte back to the MIDI USB output.
		USBMIDI.write(b);
		USBMIDI.flush();
	}
}

reading one byte at a time is absolutely useless to the extent of my awareness. well, for anything except shoving them into a pipe in serial.

my doobidge all got fried in 116 degree winds last june so i'm not capable of intensive cogitation until it's cool enough for me to grow inside a house in arizona with no air conditioning. i don't understand how anyone could think reading single bytes is sufficient notation for a midi algorithm. but it ain't their problem. neither is that baud rate.

clarification for future problem solvers,

  1. the midi spec for baud rate is 31250 Hz.

  2. midi spec is indeed a series of single bytes. i'm used to being spoonfed NoteOn events :slight_smile: .

i have managed to upload a script to the nano using "usbmidi.h" and a 31250 rate but haven't tested it yet, so my objective may be possible given that it would not accept "midiusb.h" uploads. it will take a wile to write, verify and take care of incidental odds and ends (setting the identifier for the device?), one hopes i'd follow up once i have fenangled a robust solution rather than the immediate.

No it isn't. Midi data format allows for commands that exist of a single byte as well. Regardless of that, you need to process one byte at a time, firstly to determine what type of byte you are dealing with. Once you have done that, either you can determine what to do with the data. Normally a library will do that for you under the hood, but it doesn't have to.
Mind you, this sketch does appear to be written for a Micro or a Due, something that has a USB and a Serial port of some kind.
Anyway i remember this project, that actually claims it can use any Arduino using this software or even program an Uno to show up as a device.
I've never successfully done it, also because my soundcard anyway has real MiDi and so normally i work with midi cables, which are more practical with their greater length and daisy chain option. And i have a Micro somewhere if i would want to do the USB thing

The USBMIDI library includes a copy of V-USB which does slow USB on a couple of data pins (PD2 and PD7) which are Pin 2 and Pin 7 on an UNO or Nano.

despite the code uploading successfully, i'm getting absolutely no recognition of this device in my DAW or on windows 10 (which i am unfamiliar with, i sulked for two years after my last xp computer stopped working).

i think john's last post is the first time i've seen anyone mention usbmidi apart from the author and myself :slight_smile: i think i'm going to relegate this project to the "you don't have $20 right now" department.

i'm sorry i'm not posting my code, using another machine to post.

deva rishi's 2nd link (a midi to serial port converter) looks like it may be a solution for some in this situation, but i'm intending to create a device that my niece doesn't have to do a lot of system fiddling to use.

hopefully, one day i'll have $20, and then i can see if midiusb will let me down as well. i'll be back here weeping a Little then.

You should be able to get an Arduino Micro for less than $20,- online somewhere, but if you don't have $20,- you probably don't have $10,- for online purchase either.

very true, spent a couple decades making free music software so that music isn't just a presentation of wealthy memetics, earned poverty and persecution from people who liked making money off of nescient people. "the general populace" don't see audio dsp as any kind of meaningful skill, so society has me chainsawing because i'm too weird to wash dishes apparently. its either that or cleaning toilets. screwed my ears (they fill up with fluid hourly), lost all enjoyment of music long ago. and so much crap music everywhere, all my fault, very sorry. property tax season (estate) hits like a wall of bricks every year. but these are only a small set of my complaints that will never be addressed in a capitalist society. and i'd better shut my mouth, or someone around here will get on me.

at least i don't have to listen to anything much :slight_smile: and whenever i'm at work, i'm outside, away from people, and have a nifty deterrent.

i suppose at this point one ought ask,

usbmidi is distributed as an pretty official looking resource for arduino, when it doesn't seem to have the ability to perform what it claims whatsoever. even if one refuses to accept that a non-usb hosting board can't be observed as a usb device, the 9600 baud rate in the example is a dead giveaway that it's not developed or even slightly helpful as a resource, which is the point of libraries.

can't the proper arduino people do something to clear up this resource so it doesn't misrepresent the capabilities of the product?

(and concerning the completely different but more popular library midiusb, the structure midiEventPacket_t ought be documented. a structure with no documentation is one more thing that a person like me accepts as everyday life, but could affect the aspirations of someone less weathered.)

Did you wire your USB cable correctly? Black to Ground, Green (DATA-) to Pin 7 and White (DATA+) to Pin 2?

There are several libraries that would meet that criterium which does not mean anything at all.

MIDI USB packets are documented by the official USB MIDI specification, that's way beyond the scope of a simple Arduino library.

for anyone searching,
i think this could be the first example code for receiving via midiusb on teh internets.

i don't know how the timing is, but deep breath, compile, leonardo shows up in energyXT as a device for midi out, right next to the microsoft GS wavetable synth :slight_smile: . blinks in response to notes on channel 1.

that's a pretty nice feeling to have that go so nicely.

the only thing to add is that if someone reads this considering drum machine triggers, the leonardo has a limit of 20 I/O pins (10 or less channels if you use the board for manual triggering).

#include <MIDIUSB.h>

byte command;
byte channel;

void setup() {
  //pinMode(LED_BUILTIN, OUTPUT);
  pinMode(11, OUTPUT);
  digitalWrite(11, LOW);
  Serial.begin(192000);//(31250);
}

void loop() {
  midiEventPacket_t rx;
  do {
    rx = MidiUSB.read();
    if (rx.header != 0) {
      command = rx.byte1 & 0xF0;
      channel = rx.byte1 & 0x0F;
      if (channel == 0x00) {
        if (command == 0x90) digitalWrite(11, HIGH);//noteon
        else if (command == 0x80) digitalWrite(11, LOW);//noteoff
      }
    }
  } while (rx.header != 0);

Great work and thanks for sharing.

One advise: don't use magic numbers. In your case, 11 is a magic number. If you ever need to change it to another pin, you will have to change all occurences of 11 in your code and run the risk that you forget one.

#include <MIDIUSB.h>

byte command;
byte channel;

byte thePin = 11;

void setup() {
  //pinMode(LED_BUILTIN, OUTPUT);
  pinMode(thePin, OUTPUT);
  digitalWrite(thePin, LOW);
  Serial.begin(192000);//(31250);
}

void loop() {
  midiEventPacket_t rx;
  do {
    rx = MidiUSB.read();
    if (rx.header != 0) {
      command = rx.byte1 & 0xF0;
      channel = rx.byte1 & 0x0F;
      if (channel == 0x00) {
        if (command == 0x90) digitalWrite(thePin, HIGH);//noteon
        else if (command == 0x80) digitalWrite(thePin, LOW);//noteoff
      }
    }
  } while (rx.header != 0);
}

If you want to control more pins in your code, you're better off using (an array of) a struct or class that associates the channel with the pin; that will save you from having to repeat the below block for each channel / pin combination.

You can always expand with shift registers or (I2C or SPI) port expanders.

ty, i've been coding for forty years and never use variables where i can use numbers, never use a routine where i can write discrete instructions, i prefer to keep my code to myself because eg. the tendency of modern programmers to O.O. everything (such as a 1 pole lowpass which can be written in one line.. buffer += w * (in - buffer):wink: balks my sensibilities. the concept of using long descriptive variable names instead of single characters is also equally alien (eg. HIGH and LOW would appear as 1 and 0 if i wasn't sharing this script for basic functionality online). it makes sense when you realise that i program on tiny machines like netbooks with 600 pixel size screens and like to see as much instruction on one screen as possible, and that i've spent years of my life trying to conserve as much headroom as possible for audio dsp to run on tiny processors. fortunately i don't have to please anyone else.

at present i am finding this project impossible to proceed with because my ambition of triggering analog drum circuits via midi/usb is blocked by the onerous clock noise the leonardo is adding to my audio circuit. so from here, i cannot recommend this type of project to anyone until this issue is solved.

Would putting an inductor on the GND line to the audio device help ? (i mean yes it helps, but enough..)
I am not to good at these things, but without the circuit schematic it is just groping in the dark. Pretty sure the clock noise can be removed though, also because it is at a frequency that isn't normally audible. Are you sure it is actually noise from the clock ? what does the oscilloscope tell you ?

i should reply in this thread so people don't have to read the other thread.

most fun i've had in years. two sites of engineers on this. turns out i had the leads (green and white in the pic) swapped running into the audio card, flipped them around, horrible sound went away (or dropped by ~40dB). clock tone produced by the audio card not the arduino.

:slight_smile:

but i picked up some stuff.. inductor on ground.. "blocks AC passes DC" hmm.. have to order one to build a lorentz osc (without a gyrator circuit to replace the inductor).

also suggested to me.. run the circuit in ltspice, but with an AC voltage source on the + rail.. simulators won't do the clipped transistor but this method will allow one to observe how much AC interference the circuit passes to the output... brilliant!

so plans for leonardo as midi trigger are full steam ahead after i make up a few naps. it's nice that it works, and its nice that the noise circuit works as well!

I had a suspicion, but since it wasn't really clear to me what you're setup was, i was a little in the dark. Interference on an Audio card is not very common, and i was quite sure that the clock of the leonardo runs at 8 or 16 MHZ which is wel outside of audible range. Ground loops were an issue in the past, but mainly on internal soundcard, and usually caused by a fan motor or HDD not being properly isolated. Of course i would need the exact setup to know where to look. But there shouldn't be a buzz on the GND line though.
Inductors come in many sizes and calculating the proper one for a particular purpose is not something i do every day. Anyway your problem has been solved i'd say. Great !

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