28 Jan
2017
28 Jan
'17
9:45 a.m.
Hello linux-audio users,
I recently acquired a roland a-500s midi keyboard and I have problems
using it under linux. When I connect the device via usb, dmesg tells me
this:
[ 68.100184] usb 3-1: USB disconnect, device number 2
[ 73.700119] usb 3-1: new full-speed USB device number 3 using uhci_hcd
[ 73.860157] usb 3-1: New USB device found, idVendor=0582, idProduct=010d
[ 73.860162] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 73.860165] usb 3-1: Product: A-500S
[ 73.860169] usb 3-1: Manufacturer: ROLAND
[ 73.867172] snd-usb-audio: probe of 3-1:1.0 failed with error -5
And this is the relevant portion of lsusb -v:
Bus 003 Device 003: ID 0582:010d Roland Corp. A-500S
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 64
idVendor 0x0582 Roland Corp.
idProduct 0x010d A-500S
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 150mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
I am running debian stable (8) and my machine is a lenovo thinkpad
x60s, any help appreciated!
-F
28 Jan
28 Jan
11:39 a.m.
On Sat, Jan 28, 2017 at 09:45:27AM +0100, Francesco Ariis wrote:
Hello linux-audio users,
I recently acquired a roland a-500s midi keyboard and I have problems
using it under linux. [...]
I found the solution. Apparently every Roland series 500 keyboard has
an ADVANCED MODE switch. Turning it off solved the problem.
The switch is on the left side of the keyboard, I suspect this 'trick'
holds true for many A-xyz Roland keyboard.
I'll add a few more words to make this pop up on search engines:
my Roland a-500 (a-500s, a-800pro) keyboard was not recognised, but I
solved the problem.
11:34 p.m.
On 01/28/2017 12:39 AM, Francesco Ariis wrote:
On Sat, Jan 28, 2017 at 09:45:27AM +0100, Francesco
Ariis wrote:
That's interesting. I wonder of their "Advanced" term is just a synonym
for "Proprietary"?
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
Hello linux-audio users,
I recently acquired a roland a-500s midi keyboard and I have problems
using it under linux. [...]
I found the solution. Apparently every Roland series 500 keyboard has
an ADVANCED MODE switch. Turning it off solved the problem.
The switch is on the left side of the keyboard, I suspect this 'trick'
holds true for many A-xyz Roland keyboard.
I'll add a few more words to make this pop up on search engines:
my Roland a-500 (a-500s, a-800pro) keyboard was not recognised, but I
solved the problem.
29 Jan
29 Jan
12:07 a.m.
On Sat, Jan 28, 2017 at 12:34:37PM -1000, david wrote:
On 01/28/2017 12:39 AM, Francesco Ariis wrote:
Most likely! They promise less latency with advanced-mode on, but I
didn't notice any playing with "normal mode".
On Sat, Jan 28, 2017 at 09:45:27AM +0100,
Francesco Ariis wrote:
That's interesting. I wonder of their "Advanced" term is just a synonym
for
"Proprietary"? Hello linux-audio users,
I recently acquired a roland a-500s midi keyboard and I have problems
using it under linux. [...]
I found the solution. Apparently every Roland series 500 keyboard has
an ADVANCED MODE switch. Turning it off solved the problem.
12:23 a.m.
On 01/28/2017 01:07 PM, Francesco Ariis wrote:
On Sat, Jan 28, 2017 at 12:34:37PM -1000, david
wrote:
My MIDI setup is too simple for me to notice any MIDI latency: one MIDI
keyboard in via a simple MIDI->USB adaptor. No other hardware MIDI
devices. Everything else is software.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
On 01/28/2017 12:39 AM, Francesco Ariis wrote:
Most likely! They promise less latency with advanced-mode on, but I
didn't notice any playing with "normal mode". On Sat, Jan 28, 2017 at 09:45:27AM +0100,
Francesco Ariis wrote:
That's interesting. I wonder of their "Advanced" term is just a synonym
for
"Proprietary"? Hello linux-audio users,
I recently acquired a roland a-500s midi keyboard and I have problems
using it under linux. [...]
I found the solution. Apparently every Roland series 500 keyboard has
an ADVANCED MODE switch. Turning it off solved the problem. 
8:44 a.m.
On Sat, 28 Jan 2017 13:23:07 -1000, david wrote:
My MIDI setup is too simple for me to notice any MIDI
latency: one
MIDI keyboard in via a simple MIDI->USB adaptor. No other hardware
MIDI devices. Everything else is software.
The issue starts, if you expect to record and play MIDI with the same
timing quality you record an instrument by an audio track. IOW if
you don't quantise. It's also an issue if you quantise, but need perfect
sync, using external MIDI gear.
Linux DAW MIDI out ---------------------> External sampler HiHat MIDI in
External drum sampler HiHat audio out --> Linux DAW audio in
Record two audio tracks with the HiHat, not at the same time, but one
after the other. You'll hear audible jitter, if you play both audio
tracks in unison.
If you do the same with an Atari ST MIDI sequencer, SMPTE and a 4-track
tape deck or a C64 MIDI sequencer, click sync and a 4-track tape
deck, there's no audible jitter at all.
The speed of MIDI interfaces is only an issue, if you use one interface
for 16 MIDI channels, when using 4 individual interfaces for 16 MIDI
channels, you already could send short SysEx data quasi in real-time,
without experiencing issues. For modern computers jitter is an issue
and for old computers the sequencer's ticks-per-quarter-note is an
issue. Actually old sequencers with not enough ticks-per-quarter-note
are better, since the amount of jitter for modern computers renders the
more ticks-per-quarter-note useless.
Record a MIDI keyboard by an audio track and a MIDI track at the same
time with as much ticks-per-quarter-note as possible, don't quantise
the MIDI events, then play the MIDI and the audio track in unison. If
you hear a difference, it's jitter, not the speed limit of MIDI.
Regards,
Ralf
12:12 a.m.
On Sat, 28 Jan 2017, david wrote:
On 01/28/2017 12:39 AM, Francesco Ariis wrote:
On Sat, Jan 28, 2017 at 09:45:27AM +0100,
Francesco Ariis wrote:
That's interesting. I wonder of their "Advanced" term is just a synonym for
"Proprietary"? Hello linux-audio users,
I recently acquired a roland a-500s midi keyboard and I have problems
using it under linux. [...]
I found the solution. Apparently every Roland series 500 keyboard has
an ADVANCED MODE switch. Turning it off solved the problem.
The switch is on the left side of the keyboard, I suspect this 'trick'
holds true for many A-xyz Roland keyboard.
I'll add a few more words to make this pop up on search engines:
my Roland a-500 (a-500s, a-800pro) keyboard was not recognised, but I
solved the problem. From the manual:
"This mode utilizes the
A-500S’s special, advanced MIDI driver.
This advanced driver uses *FPT technology for rapid, high-performance
MIDI transmissions."
Standard driver:
"This mode uses the standard MIDI driver included with
the OS. Use this if you do not have the special driver
installed. This setting can be used only when running Windows XP."
The manual does not claim this is Roland technology or that it is licenced
from someone else. Looking up FPT USB MIDI on the web does only return
Roland/Cakewalk pages for as long as I looked.
I did find that this is the advanced mode in the Roland UM-ONE which I
used to have (it is on loan right now) as well. I remember trying that
MIDI interface in Linux with both modes and MIDI seemed to work just fine
either way.... However, I would also point out that the speed was limited
to real MIDI speeds in any case so it may have been a compatablity mode in
case there was a Roland kb plugged in as well, and not the full advanced
mode. Who knows... (maybe my switch was broken too)
--
Len Ovens
www.ovenwerks.net
12:19 a.m.
On 01/28/2017 01:11 PM, Len Ovens wrote:
On Sat, 28 Jan 2017, david wrote:
Sounds a bit proprietary to me. Even if a technology isn't patented or
otherwise legally restricted - if no one else uses it, it's effectively
proprietary.
On 01/28/2017 12:39 AM, Francesco Ariis wrote:
On Sat, Jan 28, 2017 at 09:45:27AM +0100,
Francesco Ariis wrote:
That's interesting. I wonder of their "Advanced" term is just a
synonym for "Proprietary"? Hello linux-audio users,
I recently acquired a roland a-500s midi keyboard and I have
problems
using it under linux. [...]
I found the solution. Apparently every Roland series 500 keyboard has
an ADVANCED MODE switch. Turning it off solved the problem.
The switch is on the left side of the keyboard, I suspect this 'trick'
holds true for many A-xyz Roland keyboard.
I'll add a few more words to make this pop up on search engines:
my Roland a-500 (a-500s, a-800pro) keyboard was not recognised, but I
solved the problem. From the manual:
"This mode
utilizes the A-500S’s special, advanced MIDI driver.
This advanced driver uses *FPT technology for rapid, high-performance
MIDI transmissions."
Standard driver:
"This mode uses the standard MIDI driver included with
the OS. Use this if you do not have the special driver
installed. This setting can be used only when running Windows XP."
The manual does not claim this is Roland technology or that it is
licenced from someone else. Looking up FPT USB MIDI on the web does only
return Roland/Cakewalk pages for as long as I looked. I did find that this is the advanced mode in the
Roland UM-ONE which I
used to have (it is on loan right now) as well. I remember trying that
MIDI interface in Linux with both modes and MIDI seemed to work just
fine either way.... However, I would also point out that the speed was
limited to real MIDI speeds in any case so it may have been a
compatablity mode in case there was a Roland kb plugged in as well, and
not the full advanced mode. Who knows... (maybe my switch was broken too)
That's possible. Never underestimate the power of hardware to break!
Haven't most modern/current MIDI devices switched to USB? If so, do the
old MIDI hardware transmission speed limits still apply?
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
12:41 a.m.
On Sat, 28 Jan 2017, david wrote:
On 01/28/2017 01:11 PM, Len Ovens wrote:
I agree, in general if I driver is needed for both Windows and MacOS, I
concider it proprietary.
On Sat, 28 Jan 2017, david wrote:
Sounds a bit proprietary to me. Even if a technology isn't patented or
otherwise legally restricted - if no one else uses it, it's effectively
proprietary. That's interesting. I wonder of their
"Advanced" term is just a
synonym for "Proprietary"?
The manual does not claim this is Roland technology or that it is
licenced from someone else. Looking up FPT USB MIDI on the web does only
return Roland/Cakewalk pages for as long as I looked. Haven't most modern/current MIDI devices switched
to USB? If so, do the
old MIDI hardware transmission speed limits still apply?
It depends... Some just take the base midi and add a USB chip in which
case there is no speed improvement. Beyond that, I don't know. Even USB1.1
is certainly able to go faster.
--
Len Ovens
www.ovenwerks.net
4:55 a.m.
On 01/28/2017 01:41 PM, Len Ovens wrote:
On Sat, 28 Jan 2017, david wrote:
So I wonder. Is there some sort of upper speed limit in the MIDI
standard? Is the MIDI standard smart enough to negotiate speeds if
various MIDI devices differ? Or was the MIDI standard strict in saying
that your device must operate at this official speed?
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
On 01/28/2017 01:11 PM, Len Ovens wrote:
I agree, in general if I driver is needed for both Windows and MacOS, I
concider it proprietary.
On Sat, 28 Jan 2017, david wrote:
Sounds a bit proprietary to me. Even if a technology isn't patented or
otherwise legally restricted - if no one else uses it, it's
effectively proprietary. That's interesting. I wonder of their
"Advanced" term is just a
synonym for "Proprietary"?
The manual does not claim this is Roland technology or that it is
licenced from someone else. Looking up FPT USB MIDI on the web does only
return Roland/Cakewalk pages for as long as I looked. Haven't most modern/current MIDI devices
switched to USB? If so, do
the old MIDI hardware transmission speed limits still apply?
It depends... Some just take the base midi and add a USB chip in which
case there is no speed improvement. Beyond that, I don't know. Even
USB1.1 is certainly able to go faster.
9:14 a.m.
On Sat, 28 Jan 2017 17:55:40 -1000, david wrote:
So I wonder. Is there some sort of upper speed limit in
the MIDI
standard? Is the MIDI standard smart enough to negotiate speeds if
various MIDI devices differ? Or was the MIDI standard strict in saying
that your device must operate at this official speed?
You are aware that MIDI data simply is send and received without a time
stamp and without any sync. The software checks if an ACIA/UART
register reports that a byte was received by a short machine language
endless loop. The endless loop is only interrupted by a branch, if a
byte was received, to read the byte and then to continue the endless
loop. On old computers such as the C64 a lot of MIDI operations were
done by even disabling IRQs. The 65xx chips have a command to disable
timer and break command/flag IRQs, named SEI. One MIDI interface must
use the same rate on both ends, the receiver and transmitter, but if
you use different interfaces you could ignore the MIDI standard and
chose any other rate, as long as sender and receiver chose the same
rate. IOW one interface could not communicate with several MIDI
interfaces using different rates.
9:20 a.m.
On Sun, 29 Jan 2017 09:14:07 +0100, Ralf Mardorf wrote:
On Sat, 28 Jan 2017 17:55:40 -1000, david wrote:
^^^^^^^^^^^^^^^^ English isn't my native language, this
phrase might not be that good, but it anyway is to the point.
So I wonder. Is there some sort of upper speed
limit in the MIDI
standard? Is the MIDI standard smart enough to negotiate speeds if
various MIDI devices differ? Or was the MIDI standard strict in
saying that your device must operate at this official speed?
You are aware that MIDI data simply is send and received without a time
stamp and without any sync. The software checks if an ACIA/UART register reports that a byte was received by a short
machine language
endless loop. The endless loop is only interrupted by a branch, if a
byte was received, to read the byte and then to continue the endless
loop. On old computers such as the C64 a lot of MIDI operations were
done by even disabling IRQs. The 65xx chips have a command to disable
timer and break command/flag IRQs, named SEI. One MIDI interface must
use the same rate on both ends, the receiver and transmitter, but if
you use different interfaces you could ignore the MIDI standard and
chose any other rate, as long as sender and receiver chose the same
rate. IOW one interface could not communicate with several MIDI
interfaces using different rates.
10:35 a.m.
david wrote:
Is there some sort of upper speed limit in the MIDI
standard? Is the
MIDI standard smart enough to negotiate speeds if various MIDI devices
differ? Or was the MIDI standard strict in saying that your device
must operate at this official speed?
<https://www.midi.org/specifications/item/the-midi-1-0-specification>:
| The hardware MIDI interface operates at 31.25 (+/- 1%) Kbaud,
| asynchronous, with a start bit, 8 data bits (D0 to D7), and a stop
| bit. This makes a total of 10 bits for a period of 320 microseconds
| per serial byte.
USB MIDI does not specify any limit. However, the protocol implicitly
throttles when the device takes longer to accept a new packet; this
happens automatically when the device's buffer is full.
FireWire MIDI has no synchronization mechanism, so the sender must take
care to avoid sending the data faster than the receiver can handle it.
RP-027 says:
| The encapsulation function block of a transmitter that does not
| implement a negotiation procedure shall use a maximum rate of one
| LABEL 81H quadlet every 320 microseconds per MPX-MIDI Data Channel.
| [...]
| NOTE: a future extension of this specification will define a negotiation
| procedure between transmitters and receivers and will allow the use of
| LABEL 82H and 83H quadlets. These capabilities will allow transmission
| of MIDI data at rates substantially faster than the MIDI 1.0 data rate.
| However, the current version of this specification limits the use of
| these capabilities in order to avoid interoperability problems with
| other MIDI devices. Higher speed modes (e.g. MIDI1.0–2X–SPEED and
| MIDI1.0–3X–SPEED) are described solely so that devices compliant with
| the current specification will be able to interoperate with devices
| compliant with a future extension of this specification.
Regards,
Clemens
10:23 a.m.
Len Ovens wrote:
On Sat, 28 Jan 2017, david wrote:
Please note that this is about the _driver_. The switch just makes
the device report itself as "proprietary" so that the standard Windows
driver does not attach to it; the actual protocol is the same.
On 01/28/2017 12:39 AM, Francesco Ariis wrote:
From the manual:
"This mode utilizes the A-500S’s special, advanced MIDI driver. On Sat, Jan 28, 2017 at 09:45:27AM +0100,
Francesco Ariis wrote:
I found the solution. Apparently every Roland series 500 keyboard has
an ADVANCED MODE switch. Turning it off solved the problem.
That's interesting. I wonder of their "Advanced" term is just a synonym for
"Proprietary"? This advanced driver uses *FPT technology for
rapid, high-performance
MIDI transmissions."
"FPT" is marketing-speak for "the driver can send more than one MIDI
event in one USB packet, and can pipeline multiple USB packets". This
is just what any proper USB driver should do (and what the Windows XP
driver did not; I've heard they've rewritten it in Windows 10 or so).
However, I would also point out that the speed was
limited to real
MIDI speeds
USB MIDI can be as fast as the driver and the device can send and accept
packets. The microcontroller in my SC-8820 can eat up MIDI data at
about three times the normal MIDI speed, but when there is a real MIDI
port involved, it is not possible to go faster.
Regards,
Clemens
4:49 p.m.
On Sun, 29 Jan 2017, Clemens Ladisch wrote:
Len Ovens wrote:
The case inpoint was my din midi to USB interface. The USB would not limit
the speed, but the din midi would :) In the case of the keyboard, I would
be surprised if Roland did not send USB midi faster than standard MIDI.
--
Len Ovens
www.ovenwerks.net
However, I would also point out that the speed
was limited to real
MIDI speeds
USB MIDI can be as fast as the driver and the device can send and accept
packets. The microcontroller in my SC-8820 can eat up MIDI data at
about three times the normal MIDI speed, but when there is a real MIDI
port involved, it is not possible to go faster.
10:45 a.m.
Francesco Ariis wrote:
I recently acquired a roland a-500s midi keyboard
and I have problems
using it under linux. When I connect the device via usb, dmesg tells me
this:
[ 73.700119] usb 3-1: new full-speed USB device number 3 using uhci_hcd
[ 73.860165] usb 3-1: Product: A-500S
[ 73.860169] usb 3-1: Manufacturer: ROLAND
[ 73.867172] snd-usb-audio: probe of 3-1:1.0 failed with error -5
When in "Advanced Mode", most newer devices tell the driver in the
descriptors how many MIDI ports they have; for older devices, the driver
just has to know.
Please show the "lsusb -v" output for this device in standard mode.
Regards,
Clemens
2858
days inactive
2859
days old
linux-audio-user@lists.linuxaudio.org
15 comments
5 participants
participants (5)
-
Clemens Ladisch -
david -
Francesco Ariis -
Len Ovens -
Ralf Mardorf