Midi direct via USB?

Look for [FtdiPort232.NT.HW.AddReg] and change the the second line below to the one that i've got here.

HKR,,"ConfigData",1,11,00,3F,3F,10,27,00,00,88,13,00,00,C4,09,00,00,E2,04,00,00,71,02,00,00,38,41,00,00,9C,80,00,00,60,00,00,00,34,00,00,00,1A,00,00,00,0D,00,00,00,06,40,00,00,03,80,00,00,00,00,00,00,D0,80,00,00

Which second line do you mean exctly?

1[FtdiPort232.NT.HW.AddReg]
2 HKR,,"UpperFilters",0x00010000,"serenum"
3;HKR,,"ConfigData",1,01,00,3F,3F,10,27,88,13,C4,09,E2,04,71,02,38,41,9c,80,4E,C0,34,00,1A,00,0D,00,06,40,0 3,80,00,00,d0,80
4 HKR,,"ConfigData",1,11,00,3F,3F,10,27,00,00,88,13,00,00,C4,09,00,00,E2,04,00,00,71,02,00,00,38,41,00,00,9C,80,00,00,60,00,00,00,34,00,00,00,1A,00,00,00,0D,00,00,00,06,40,00,00,03,80,00,00,00,00,00,00,D0,80,00,00

And the roland serial to usb is this the right vesrsion:RSDRV31W2K.ZIP???

thanxx

I can't get Windows to use the Arduino version of ftdiport.inf that I've changed; it insists on using the XP version in oem5.inf.

Any tips to force Windows to use my version? Is there a place in the registry I can just add the MIDI baud rate?

Thanks!

Any tips to force Windows to use my version? Is there a place in the registry I can just add the MIDI baud rate?

Try somewhere under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FTDIBUS... there you'll find the ConfigData binary key.

Thanks. I don't know if it would be the same for all XP installations, but I made a .reg file people could use. Just paste this into a file, name it "foo.reg" (or whatever) and double-click it to merge it into the registry. (USE AT OWN RISK! REG HACKS CAN KILL YOUR INSTALLATION!!!! BACKUP YOUR REGISTRY FIRST!!!!)

---paste below---

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FTDIBUS\VID_0403+PID_6001+A4001drJA\0000\Device Parameters]
"PortName"="COM4"
"PollingPeriod"=dword:00000000
"ConfigData"=hex:11,00,3f,3f,10,27,00,00,88,13,00,00,c4,09,00,00,e2,04,00,00,
71,02,00,00,38,41,00,00,9c,80,00,00,60,00,00,00,34,00,00,00,1a,00,00,00,0d,
00,00,00,06,40,00,00,03,80,00,00,00,00,00,00,d0,80,00,00
"MinReadTimeout"=dword:00000000
"MinWriteTimeout"=dword:00000000
"LatencyTimer"=dword:00000010

---paste above---

Ok tried installing everything as per in this thread but no luck on midi via usb yet :frowning:
I noticed in that the FtdiPort232.NT.HW.AddReg trick seems to be pointing to port 232. But I've installed on com3 - is that a problem.
I hate to sound lame but I can't find an answer anywhere. Help appreciated :slight_smile:

// The switch is on Arduino pin 10:
#define switchPin 2
// Middle C (MIDI note value 60) is the lowest note we'll play:
#define middleC 60
// Indicator LED:
#define LEDpin 4

// Variables:
char note = 1; // The MIDI note value to be played
int AnalogValue = 0; // value from the analog input
int lastNotePlayed = 0; // note turned on when you press the switch
int lastSwitchState = 0; // state of the switch during previous time through the main loop
int currentSwitchState = 0;

void setup() {
// set the states of the I/O pins:
pinMode(switchPin, INPUT);
pinMode(LEDpin, OUTPUT);
// Set MIDI baud rate:
Serial.begin(31250);
blink(3);
}

void loop() {
// My potentiometer gave a range from 0 to 1023:
AnalogValue = analogRead(0);
// convert to a range from 0 to 127:
note = AnalogValue/8;
currentSwitchState = digitalRead(switchPin);
// Check to see that the switch is pressed:
if (currentSwitchState == 1) {
// check to see that the switch wasn't pressed last time
// through the main loop:
if (lastSwitchState == 0) {
// set the note value based on the analog value, plus a couple octaves:
// note = note + 60;
// start a note playing:
noteOn(0x90, note, 0x40);
// save the note we played, so we can turn it off:
lastNotePlayed = note;
digitalWrite(LEDpin, HIGH);
}
}
else { // if the switch is not pressed:
// but the switch was pressed last time through the main loop:
if (lastSwitchState == 1) {
// stop the last note played:
noteOn(0x90, lastNotePlayed, 0x00);
digitalWrite(LEDpin, LOW);
}
}

// save the state of the switch for next time
// through the main loop:
lastSwitchState = currentSwitchState;
}

// plays a MIDI note. Doesn't check to see that
// cmd is greater than 127, or that data values are less than 127:
void noteOn(char cmd, char data1, char data2) {
Serial.print(cmd, BYTE);
Serial.print(data1, BYTE);
Serial.print(data2, BYTE);
}

// Blinks an LED 3 times
void blink(int howManyTimes) {
int i;
for (i=0; i< howManyTimes; i++) {
digitalWrite(LEDpin, HIGH);
delay(100);
digitalWrite(LEDpin, LOW);
delay(100);
}
}

Has anyone actually gotten any iteration of this to work in OSX?

Or does anyone know of anyone working on a driver solution specifically for the Arduino MIDI crowd?

bump.

Has anyone actually gotten any iteration of this to work in OSX?
Or does anyone know of anyone working on a driver solution specifically for the Arduino MIDI crowd?

No, i haven't, but how hard would this be to code arduino-usb-midi driver ourselves?
let's throw together our crazy ideas and URLs to maybe have a solution within the next couple of years. this thread has been here for long enough.

What do we want?

  • use an arduino board as a (generic) USB-midi device on OS X. That means you hook the board to an USB port on your computer and it shows up as midi-input and output ports as any other USB-Midi device does. most important to me: the board/controller is usb powered.

How do we get there?

I can think of 3 solutions to get there, (which for sure will exist in the near future anyways, but we want it now), so:

SOLUTION A:

  • something like AVR-USB http://www.obdev.at/products/avrusb/index.html
    Arduino is programmed to communicate directly via USB (no FTDI chip in between). It reports itself as a generic midi device and the computer's operation system uses a standard driver.

pro: no installation on computers necessary. arduino device works out of the box on most computers.
contra: a little out of my scope yet, and i'm doubtful if such a AVR-USB-arduino could do much input reading besides doing USB. an extra atmega could be needed.

SOLUTION B:

  • a hacked, or redone FTDI-driver to enable midi baud rate like it has been done on windows PCs. then use a roland midi serial driver to emulate midi ports.

pro: i don't know. it didn't work for me and i got bored because of...
...contra: hacking a driver to be able to use the board with a propietary software, made this unattractive to me. the roland driver seems quite old as well

SOLUTION C:

  • an inbetween application like serial proxy server. Create virtual midi ports and act as a relay between any serial device (arduino board in our case) and MIDI. the baord can send midi messages at any baud rate.

pro: relatively straight forward. debugging friendly, because of flexible baud rate. arduino compatible , no extra atmega or FTDi hack.
contra: installation/configuration necessary on any new computer (only affects people who often switch computers or want to give away controllers to more unsavvy users)

i tend to SOLUTION C, with a nice interface to setup port names. Maybe someone of you knows a good starting point. i tried doing it with processing, but midi on OS X requires a library, which does not work with out of the box Java on OS X. as i have a working solution (midiman usb adapter) i gave up on that. Java would be cool, but since i'm also interested in building native cocoa apps, i'm thinking of going that way. but i couldnt yet find the right documents at the apple developers site or any open source project that uses midi.

anyone?

i tend to SOLUTION C, with a nice interface to setup port names. Maybe someone of you knows a good starting point. i tried doing it with processing, but midi on OS X requires a library, which does not work with out of the box Java on OS X. as i have a working solution (midiman usb adapter) i gave up on that. Java would be cool, but since i'm also interested in building native cocoa apps, i'm thinking of going that way. but i couldnt yet find the right documents at the apple developers site or any open source project that uses midi.

anyone?

I choose this solution too, between Isadora and arduino on a mac, as to drive 3 stepper motor. I send Midi from Isadora to Max/msp (good serial analysis, easy management of integer/hexa/bytes), Max send it via serial to arduino, working well, the same in return with sensor on Arduino, sended easely via serial to max, translated to midi and sended to Isadora. I would prefere OSC but serial and OSC in Isadora are really poorly implemented.

anyone?

well, after reading your post for the third time now, i still must say i just don't get it!
but the good thing is that, now, since i have posted something here in this thread,
i'm authorized to send PMs.

thumbs up ... daniel!

I choose this solution too, between Isadora and arduino on a mac, as to drive 3 stepper motor. I send Midi from Isadora to Max/msp (good serial analysis, easy management of integer/hexa/bytes), Max send it via serial to arduino, working well, the same in return with sensor on Arduino, sended easely via serial to max, translated to midi and sended to Isadora. I would prefere OSC but serial and OSC in Isadora are really poorly implemented.

aah. that sounds like an easy solution for now.
no Max/MSP experience here. but wouldn't it be possible to do a serial-to-midi converter patch in Max and share this (legally)? I don't know what kind of data you're sending from max to arduino, but i'd like to keep the format of the data as it is. I mean that the max patch needs not to do any kind of interpreting of the midi-data. just pass every byte from serial to the midi port and the other way around. Is this what you're doing, or do you know if it would be hard to accomplish?

(and BTW: hello daniel78)

kuk

Hello,

I am testing now the patch, it can work without the max licence (with the free maxPlayer), but you cannot edit the patch. For the moment I can receive the state of the 8 analogIn (tagged "a", "b" etc. in Arduino), receive it in Max and send it with controlChange via midi. The version now use 2 controlChange for each as to keep the 1023 steps of Arduino, that because I use it after in Isadora (serial and OSC in Isadora are not very reliable).

I have 2 thinks to solve: read the serial ports and choose the right one (for the moment impossible to do without editing the patch), the choice to use only 1 controlChange for each sensor (need to make a division by 8) and a better GUI.

I prepare it for a workshop I will give i Mons (Belgium) next week about Isadora and Arduino and I will post it.

Jacques

I prepare it for a workshop I will give i Mons (Belgium) next week about Isadora and Arduino and I will post it.

Waiting in line!

the latest version of Isadora has a serial in actor that could work directly with arduino.

Look for [FtdiPort232.NT.HW.AddReg] and change the the second line below to the one that i've got here.

HKR,,"ConfigData",1,11,00,3F,3F,10,27,00,00,88,13,00,00,C4,09,00,00,E2,04,00,00,
71,02,00,00,38,41,00,00,9C,80,00,00,60,00,00,00,34,00,00,00,1A,00,00,00,0D,00,00
,00,06,40,00,00,03,80,00,00,00,00,00,00,D0,80,00,00

Which second line do you mean exctly?
1 [FtdiPort232.NT.HW.AddReg]
2 HKR,,"UpperFilters",0x00010000,"serenum"
3 ;HKR,,"ConfigData",1,01,00,3F,3F,10,27,88,13,C4,09,E2,04,71,02,38,41,9c,80,4E,C0,34,00,1A,00,0D,00,06,40,03,80,00,00,d0,80
4 HKR,,"ConfigData",1,11,00,3F,3F,10,27,00,00,88,13,00,00,C4,09,00,00,E2,04,00,00,71,02,00,00,38,41,00,00,9C,80,00,00,4E,C0,00,00,34,00,00,00,1A,00,00,00,0D,00,00,00,06,40,00,00,03,80,00,00,00,00,00,00,D0,80,00,00

I think this question isn't answered yet.
If re-installing the ftdi drivers wasn't such a pain I could change stuff by trial and error, but somehow I'm not able to uninstall the drivers or change windows' register...

Thanks in advance, Ben

I have been trying to deal with the usb-midi communication problem for a couple of months using Max/MSP as a work around and have come up with pretty mixed reults.

The main downside has to do with the way in which the Max Scheduler handles serial data, which seems to be fairly inconsistent with respect to timing, and also has the occassional tendency to make my system unstable, requiring at least software restarts, sometimes computer reboots. What I came to learn recently is that a big part of this has to do with the USB-serial communication protocol (I think this is what the ftdi chip is using), which was not designed to transmit messages as quickly and as accurrately as I might like from a USB-Midi insrtrument (which is what I am trying to build).

The upside of using Max is that it is relatively easy to simply grab serial data coming from Arduino, convert it into midi, and then send it to any midi-friendly software such as Ableton Live or Reason or whatever. Max/MSP has its own virtual Midi ports that show up in any of these softwares and it is quite easy to send your data to those ports.

Considering the upside, it is pretty attractive to use Max/MSP as a pseudo-driver to fake a USB-MIDI connection. However, neither the Max/MSP platform nor the USB serial connection that is at the heart of this process are robust enough to provide Fast and Consistent MIDI activity (both are which are important to me).

At this point though, I am trying to move away from the Max/MSP based solution, for reasons of consistency and the need for installation/compatibility.

After reading this thread, I have to say that I am with kuk:
Solution C (to create an inbetween serial proxy server) seems to make the most sense. I have essentially been trying to do this with Max/MSP, but dont think it will be sufficient for the job in the end (at least not given the current state of affairs with the software). Unfortunately, I don't personally know of another way to make this inbetween serial proxy server, so my hands are somewhat tied at the moment.

I am looking more into USB-MIDI communication at the moment, and will update here I find anything interesting or useful.

the latest version of Isadora has a serial in actor that could work directly with arduino.

"could" is important, for the moment serial input in Isadora is not able to receive variable bit number because it's not possible to tag (like in max) a serial message. Mark Coniglio and JCipriani are working on it. I prefere for now use a max patch, more secure for me, but the direct solution is the future?

I 've just installed ftdi hacked driver + roland serial driver + MIDI-OX (for those who need more info => http://www.megadrum.info/drivers.php) on my windows XP box.

I can hear a latency, did anyone of you experienced such a problem ?

@Ben : to remove the ftdi driver, download the FTClean from ftdi (windows only : http://www.ftdichip.com/Resources/Utilities/FTClean.zip).
Set 6001 for product ID and read carefully the dialog boxes (one time yes, one time no as far as I remember)

Nicolas

If you're using a Mac, I wrote an OS X application that creates a virtual MIDI instrument from Arduino serial output. This eliminates the need for additional MIDI hardware and pulls in data directly from the Arduino's USB connection. I made an electronic drum kit out of it. See: Google Code Archive - Long-term storage for Google Code Project Hosting. for details.

Try it out...I'd love to hear how it goes!

hi mschaff,
awesome. thank you very much.

do you think that your application could be expanded (or rather reduced) to accept data in the midi format and pass this on to the virtual port instead of taking "raw data" from the arduino?

the reason for this is that my instruments already have midi ports (non-usb), which i don't want to miss because of interoperability. it would be nice to chose to either use the USB or midi-socket. this would also give us more flexibilty for differnet interfaces than drum-triggers like pots and sliders.

if your code is available i'd give it a try. it's probably even simpler than your approach. what do you think?

kuk