According to WikiPedia the “MIDI standard consists of a communications messaging protocol designed for use with musical instruments, as well as a physical interface standard. It consists physically of a one-way (simplex) digital current loop electrical connection sending asynchronous serial communication data at 31,250 bits per second. 8-N-1 format, i.e. one start bit (must be 0), eight data bits, no parity bit and one stop bit (must be 1).”
So, I’m trying to send data to a MIDI device using the USBH_SerialUSB class. It seems like I might be able to instantiate the serial device as follows:
void USBHostController_DeviceConnectedEvent(GHIElectronics.NETMF.USBHost.USBH_Device device)
{
if (index == 0)
{
deviceVar = new USBH_SerialUSB(device, 31250, System.IO.Ports.Parity.None, 10, System.IO.Ports.StopBits.One);
}
A first chance exception of type ‘System.Exception’ occurred in GHIElectronics.NETMF.USBHost.dll
Message: Exception was thrown: System.Exception Inner Exception:
You are reading about the original midi that uses serial ports. The new USB midi is totally different. Unfortunately, the USB midi uses an ugly way to handle descriptors that we do not support.
This sounds like an opportunity for Pete Brown to flex his module-building muscles. After all, he’s already built his own custom PCB for a MIDI thru box:
How hard could it be for him to build a MIDI module for Gadgeteer?
Actually, my MIDI module is why I had downloaded and learned Eagle. It’s fairly far along.
Even if it was done before (there are tons of shields), that’s fine.
On Gadgeteer (and other NETMF boards), the complication comes from 3.3v vs. 5v. That’s why so many MIDI modules won’t work, especially if you have older equipment that really needs the full 5v.
Real time MIDI changes are no problem using this toolkit and the .NET Framework.
I think they could be adapted to run on NETMF and Gadgeteer, and that would be fine!
parsing MIDI isn’t hard, but on an MCU running NETMF really needs efficient code to help avoid lag. I haven’t checked the desktop library there, but really, working with MIDI isn’t difficult
It’s starting to seem more feasible. Here’s the kind of thing I want to do:
switch(key)
{
case ConsoleKey.LeftArrow:
{
int oldTempo = tempo;
tempo += 10000;
int result = sequencer.ChangeTempo(oldTempo, tempo);
Console.WriteLine("Slower... ." + " New tempo: " + result);
break;
}
case ConsoleKey.RightArrow:
{
int oldTempo = tempo;
tempo -= 10000;
int result = sequencer.ChangeTempo(oldTempo, tempo);
Console.WriteLine("Faster... ." + " New tempo: " + result);
break;
}
case ConsoleKey.S:
{
sequencer.Stop();
timer.Stop();
outDevice.Reset();
Console.WriteLine("Stopped.");
Console.WriteLine("Press C to continue, R to rewind, X to exit... ");
break;
}
case ConsoleKey.C:
{
sequencer.Continue();
timer.Start();
Console.WriteLine("Playing... ");
break;
}
case ConsoleKey.X:
{
sequencer.Dispose();
timer.Dispose();
outDevice.Dispose();
ended = true;
break;
}
case ConsoleKey.R:
{
sequencer.Position = 0;
Console.WriteLine("Playing from start... ");
break;
}
case ConsoleKey.UpArrow:
{
pitch++;
break;
}
case ConsoleKey.DownArrow:
{
pitch--;
break;
}
default:
{
break;
}
}
Can you try wrapping your code with the code tags? Just edit your post, and highlight the code section, then click the icon with the 1s and 0s. Will make it MUCH easier to read code in your posts.
In this case the sequencer is an instance of a .net class. The MIDI device is represented by an OutputDevice. The ChangeTempo method changes the bpm rate to slow down or speed up the tempo, so it affects every MIDI event the sequencer processes.
I tried to do this with other libraries long ago, but the new tempo tended to be overridden by a tempo change event in the sequence and was gone.
