Objective Development Forums

Unfortunately that patch only helps mice, I eventually discovered. This is a real problem on Windows and really the only option is to use something else in most cases. Windows XP has a higher polling speed, but the application I run needs a minimum of Windows 7 and ideally Windows 7 64-bit.

I've used this library to build a little CV/Gate interface and it's working great on OS X (>= 10.6.3+ when they removed the "sanity check" on the poll interval), iOS and Linux, but on windows we are limited by the 8ms poll time. I am wondering if someone has successfully tried to patch system drivers to overcome this limitation - looks like it's a common practice among gamers who want to increase the poll rate of their mice.

hello,

how do usb midi work with windows 8?

thx georgiu

Hi thanks for that. Nice to have it confirmed that I wasn't doing something wrong!

I have my project all working now but the latency is too high. I'm using Windows 7 and know it would be better with Linux and its 2mS poll time, but to be honest I will probably go to a USB hardware solution like the Teensy in the end.

[quote="winelight"]How many MIDI Event Packets can you send in one go?
...
So I guess I have my answer, but I'd like to know where it's documented please![/quote]
Hi winelight,

You're right, two packets with a total of eight bytes is the maximum.
USB MIDI transfers are defined as bulk transfers which are not allowed for low speed devices - but it's possible to change them into interrupt transfers in the device descriptor (see my post above [url]http://forums.obdev.at/viewtopic.php?f=8&t=1352&start=15#p9104[/url]).

I've found a very good documentation ([url=http://www.beyondlogic.org/usbnutshell/usb4.shtml#Interrupt]USB in a NutShell[/url]) which states about package size:
[quote][b]Interrupt Transfers[/b]
The maximum data payload size for low-speed devices is 8 bytes.[/quote]
I've printed the [url=http://www.beyondlogic.org/usbnutshell]NutShell docs[/url] along with the [url=http://www.usb.org/developers/devclass_docs/midi10.pdf]official USB MIDI docs[/url] and used them while I developed the VUSB MIDI interface. These papers are now quite crinkled and bear notes in different colors - but hey - the software works.

Ciao, Martin

Hi everyone

Thanks to everyone who's worked on V-USB and V-USB-MIDI and had posted great tips in this thread and other places. My MIDI project is now working, however, like everyone else I would love it to go faster!

One thing I cannot seem to find an answer on is:

[b]How many MIDI Event Packets can you send in one go?[/b]

I've seen:
[list=1]Most (nearly all) examples only sending one packet[/list]
[list=2]A very few examples (and a couple of comments) suggesting two (for a total of 8 bytes) is OK[/list]
[list=3]Suggestions that you can have multiple packets - although this may only apply to bulk transfers.[/list]

Does anyone have a definitive answer please?

(edit) Well I've found by experimentation that if I return two packets, it's fine, but more than that, something somewhere goes wrong.

So I guess I have my answer, but I'd like to know where it's documented please!

Hi!

This V-USB-MIDI project is great!
I want to make some MIDI controllers with it, but i dont know how to program in other languages than the used in the Arduino IDE...I saw that some guys installed the V-USB library for using it with the Arduino IDE, anyone here knows how to do this with the V-USB_MIDI library?

Thanks in advance!
Dex

Hi,

some days ago I had an email discussion with Philipp (in german) about my hardware, maybe the conclusion will be helpful so I'll give a rough translation:

[quote]Q: what does the inductor do?
A: it formes a lowpass together with the two capacitors to filter out noise from 5v usb.

Q: what about 3.3V and 12MHz - aren't you out of spec?
A: I use ATMega16A - the data sheet (figure 27.1, Maximum frequency vs. Vcc) shows that we are slight out of spec at 3.3V but I measured Vcc to be in the range of 3.5..3.8V so it's ok again. I also use ATMega168A which is full in spec (figure 29.1). As these are worst case values over the full temperature range there is sufficent margin (up to 16 MHz).
[/quote]
Warning:
The ATMegas work at incredible low Vcc (<1V), if you use the internal eeprom you MUST set the brown out detection fuses to avoid spurious data corruption due to (slowly) dropping Vcc (I learned it the hard way).

Ciao, Martin

Sorry for my English, it's not my native language :)

I want to create USB MIDI controller based on this project: http://cryptomys.de/horo/V-USB-MIDI/
But i want to use encoders instead of potentiometers.
I need to get information about controllers position in host to display it on my device.

I know that i should use usbFunctionWriteOut, but don't understand how... Small number of examples does not give the right information about this.
Can somebody give a little piece of code for this function? How can i get this information from "data"?

I try to do this:

[code]void usbFunctionWriteOut(uchar * data, uchar len)
{

uchar cable= (*data)
uchar channel = (*(data+1))
uchar CC = *(data+2);

if (CC == 77){
PORTB = 0x00;
}
}[/code]

I expect that if in host control number 77 is changed then my LEDs are light up. That's don't work.
Where is my mistake?

Thanks.
Evgeny

Hi @ all...

I've solved the problems on my own and finally, I got the whole thing running. I've built a foot controller for digital guitar effect software, based on the V-USB-MIDI project.
[img]http://philaudio.files.wordpress.com/2011/12/phi-t-1-small3.jpg?w=549&h=411[/img].

It works perfect with Win 7.

I've created a small blog for the documentation of the project:
[url]http://philaudio.wordpress.com[/url]

Best,
Philipp.

Hi guys,

I'm very new to AVR programming, and my first big project is a midi controller. So I hope it's okay to post my questions in this threat. I've downloaded the latest version of V-USB-MIDI and I'm using an ATmega8 with AVR Studio 5 and AVRISP mkII. At the moment, I've only connected one potentiometer, one LED and one button to the device. But, unfortunately, it doesn't work. Both, Windows 7 and XP can't identify the USB device.

I've connected the USB-jack in this way:
[img]http://vusb.wikidot.com/local--files/hardware/level-conversion-with-zener.gif[/img]
In my case, D- goes to PD0 and D+ to PD2 (INT0). I've also adjusted this by editing "usbconfig.h".

But connecting the 1k5 pull-up resistor confuses me. In the schematic above, it's a pull-up to +5V, isn't it? Because in the comments of "usbdrv.h" I've read the following:
[quote]
Hardware Prerequisites:
=======================
If you use Zener diodes to limit the voltage on D+ and D-, you MUST use a pull-down resistor, not a pull-up.[/quote]
So, what to do?!
Anyway, if I don't connect the 1k5 resistor to a port of the microcontroller, how must I handle the "Optional Hardware Config" in "usbconfig.h"? Is it okay, to simply delete "#define USB_CFG_PULLUP_IOPORTNAME D" and "#define USB_CFG_PULLUP_BIT 4"? Do I have to change something else in the source code, if I use this way to connect the USB jack? Btw, I'm using those zener diodes:
[url]http://www.reichelt.de/index.html?;ACTION=7;LA=3;OPEN=0;INDEX=0;FILENAME=A400%252FZF%2523MOT.pdf;SID=13Tmr58n8AAAIAADj1Ejc9346e0fe3139afadbe3f92f875a7f569[/url]

Next thing is linking the correct files to the project. I've copied all files of the folder "usbdrv-20090415" (except the ones, that don't fit to my 12 MHz clock rate) into my project folder. Then I've included all to my project by adding them to the folder tree in AVR Studio 5, except the files "asmcommon.inc" and "usbdrvasm12.inc". They're only in the project folder, because in the comments I've read: [quote]Do not link this file! Link usbdrvasm.S instead, which includes the appropriate implementation![/quote] I hope, that's correct.
So far, so good. But where do I tell the compiler, which clock rate I've choosen?! Because unlike in "usbconfig-prototype.h" the "#define USB_CFG_CLOCK_KHZ (F_CPU/1000)" is missing in "usbconfig.h" of the V-USB-MIDI sample.

I promise, I didn't change anything in the source code (except the pin assignment)! Has anyone an idea, what I else could do, to get the thing working? Or what I do have to change in the source code when using an ATmega8?

As I said, I'm very new to that stuff, so it would be great if someone could help me.

Best,
Philipp

Hi,

some time ago I also did some tests with win xp and linux:

http://forums.obdev.at/viewtopic.php?f=8&t=1352&start=15#p9104

[quote]linux:
bmAttributes=2 (bulk), bIntervall don't care -> 2ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=1..3 -> 2ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=4..7 -> 4ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=8..15 -> 8ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=16..31 -> 16ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=0 or 32..63 -> 32ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=64..127 -> 64ms poll, low cpu load
bmAttributes=3 (interrupt), bIntervall=128..255 -> 128ms poll, low cpu load[/quote]

Ciao, Martin

I've done a few tests and I've found a hack on machines which allows high speeds on Interrupt Endpoints.

Usually, USB Polls low speed interrupt endpoints at:

Windows 8ms (minimum)
Linux 2ms (minimum)

See this page for more details:
http://msdn.microsoft.com/en-us/library/ff539114%28v=vs.85%29.aspx

Value of bInterval Polling Period (1-millisecond frames) Interrupt
0 to 15 8 Supported.
16 to 35 16 Supported.
36 to 255 32 Supported.
> 255 Polling intervals > 255 are forbidden by the USB specification. Supported.

Basically, this says that even though the device asks for 2ms or 1ms pollrate interval, windows only gives us 8ms.

With a maxmimum of 8byte packets, this gives us a maximum interrupt throughput of around 1000bytes/second. ~ 9600 baud.

However, we can HACK windows system files to give us a faster poll rate of 1ms allowing up to around 60,000baud which is great!

many gamers have hacked the sys and dlls to allow them to poll their low speed mice at a faster rate. Google: Mouse 500Hz Hack or something similar.

SweetLow from russia has developed a hack which works with all version of Windows including Win7 64bit. I've tested this myself and have seen the transmit rates increase from 1000bytes/second to 4000bytes per second. A 4 fold increase. Obviously this puts more load on the ATMEGA, but that's a decision you'll have to make.

Even though the bInterval on my device is set to 1ms, I think Win7 polls it at 2ms anyway even with the hack. Not sure why this is, by again I didn't write the hack. Apparently the hack does allow up to 1ms poll rates on low speed devices however.

You may ask why not just use Bulk Endpoints - the reason being Win7 no longer supports Lowspeed bulk devices.

Did you have a look at Osamu Tamura's pages at http://www.recursion.jp/avrcdc/

He has a similar problem with CDC (which requires bulk endoints) on Windows 7 and as far as I know, he came up with a patch.

Since Win7 doesn't support Low Speed Bulk endpoints. My version doesn't work anymore.

It works with interrupt endpoints, but its 4 times slower. and latencies suffer as a result.

Until someone makes a Win7 Bulk Low Speed driver or something.... WinXP supported this however...

Cheers,

Adrian