8 Sep
2004
8 Sep
'04
10:59 a.m.
Greetings:
I'm doing some research for an article about Linux MIDI support. In my
text I briefly describe the evolution of the MIDI specification since
its adoption, mentioning things like MIDI Time Code, MMC, the sample
dump standard, and the standard MIDI file. However, one item has me a
bit mystified. I'm unable to ascertain whether multi-port interfaces are
in fact described and supported by the spec. I checked the MMA docs
on-line, and I also have the Sciacciaferro/De Furia MIDI Programmers
Handbook, but nowhere do those sources indicate explicit support for
multi-port hardware. Are multi-port MIDI interfaces vendor-specific
solutions or is there actually an extension to the MIDI spec somewhere
that I'm just missing ? TIA!
Best regards,
dp
8 Sep
8 Sep
1:56 p.m.
Dave Phillips wrote:
I'm doing some research for an article about
Linux MIDI support. In my
text I briefly describe the evolution of the MIDI specification since
its adoption, mentioning things like MIDI Time Code, MMC, the sample
dump standard, and the standard MIDI file. However, one item has me a
bit mystified. I'm unable to ascertain whether multi-port interfaces are
in fact described and supported by the spec.
SMF files can have the "MIDI Port" meta event (FF 21) to specify the
port number for the following events. RP-019 describes the "device
name" meta event (FF 09) with exactly the same purpose
(<http://www.midi.org/about-midi/smf/rp019.shtml>), but it isn't used
in practice.
HTH
Clemens
7:14 p.m.
On ons, 2004-09-08 at 17:40, Clemens Ladisch wrote:
Dave Phillips wrote:
Dave!
Clemens fine article pointer made me look around in midi.org and (just
for the record) here is the spec for midi over firewire (with multiple
midi-devices):
http://www.midi.org/about-midi/rp27v10spec(1394).pdf
Mmmm .. Seams like that old elephant in wheelchair got himself a brand
new pair of rollerscaters ;)
mvh // Jens M Andreasen
I'm doing some research for an article
about Linux MIDI support. In my
text I briefly describe the evolution of the MIDI specification since
its adoption, mentioning things like MIDI Time Code, MMC, the sample
dump standard, and the standard MIDI file. However, one item has me a
bit mystified. I'm unable to ascertain whether multi-port interfaces are
in fact described and supported by the spec.
SMF files can have the "MIDI Port" meta event (FF 21) to specify the
port number for the following events. RP-019 describes the "device
name" meta event (FF 09) with exactly the same purpose
(<http://www.midi.org/about-midi/smf/rp019.shtml>), but it isn't used
in practice.
HTH
Clemens
2:10 p.m.
On ons, 2004-09-08 at 15:34, Dave Phillips wrote:
Greetings:
I'm doing some research for an article about Linux MIDI support. In my
text I briefly describe the evolution of the MIDI specification since
its adoption, mentioning things like MIDI Time Code, MMC, the sample
dump standard, and the standard MIDI file. However, one item has me a
bit mystified. I'm unable to ascertain whether multi-port interfaces are
in fact described and supported by the spec. I checked the MMA docs
on-line, and I also have the Sciacciaferro/De Furia MIDI Programmers
Handbook, but nowhere do those sources indicate explicit support for
multi-port hardware. Are multi-port MIDI interfaces vendor-specific
solutions or is there actually an extension to the MIDI spec somewhere
that I'm just missing ? TIA!
Muliport-interfaces were included in the initial discussions on the MIDI
standard and referred to as "star systems":
tape-sync
¦
+-----+
<---| SEQ |--->
+-----+
|
V
It was thought that a single interface would be good enough for stage
and budget systems and that professional recording studios could
overcome bandwith limitations by using one port for each synth-module
attached.
No specifics regarding naming nor discovery were mentioned. I suppose
Roland, Sequential and Yamaha intended to build and sell those
sequencers all by themselves ...
The place to look for a universal standard for multiple midi-devices
would be in the USB specification. And it even appears like some vendors
are (finally!) starting to follow suit:
http://midiman.com/products/en_us/KeystationPro88-main.html
- "USB class compliant—no drivers required for
Windows XP or Mac OS X"
mvh // Jens M Andreasen
Best regards,
dp
4:29 p.m.
On Wednesday 08 September 2004 11:53 am, Jens M Andreasen wrote:
On ons, 2004-09-08 at 15:34, Dave Phillips wrote:
Yeow! I bought a keystation49e and all it took to get running was plug it in,
turn it on.
Greetings:
I'm doing some research for an article about Linux MIDI support. In my
text I briefly describe the evolution of the MIDI specification since
its adoption, mentioning things like MIDI Time Code, MMC, the sample
dump standard, and the standard MIDI file. However, one item has me a
bit mystified. I'm unable to ascertain whether multi-port interfaces are
in fact described and supported by the spec. I checked the MMA docs
on-line, and I also have the Sciacciaferro/De Furia MIDI Programmers
Handbook, but nowhere do those sources indicate explicit support for
multi-port hardware. Are multi-port MIDI interfaces vendor-specific
solutions or is there actually an extension to the MIDI spec somewhere
that I'm just missing ? TIA!
Muliport-interfaces were included in the initial discussions on the MIDI
standard and referred to as "star systems":
tape-sync
¦
+-----+
<---| SEQ |--->
+-----+
V
It was thought that a single interface would be good enough for stage
and budget systems and that professional recording studios could
overcome bandwith limitations by using one port for each synth-module
attached.
No specifics regarding naming nor discovery were mentioned. I suppose
Roland, Sequential and Yamaha intended to build and sell those
sequencers all by themselves ...
The place to look for a universal standard for multiple midi-devices
would be in the USB specification. And it even appears like some vendors
are (finally!) starting to follow suit:
http://midiman.com/products/en_us/KeystationPro88-main.html
- "USB class compliant—no drivers required
for
Windows XP or Mac OS X"
mvh // Jens M Andreasen
> Best regards,
>
> dp
9 Sep
9 Sep
6:23 a.m.
Jens M Andreasen wrote:
[...] the USB specification. And it even appears like
some vendors
are (finally!) starting to follow suit:
http://midiman.com/products/en_us/KeystationPro88-main.html
- "USB class compliantno drivers required for
Windows XP or Mac OS X"
M-Audio started following suit only after they hung their engineers
with a USB cable and bought Evolution who had always made
class-compliant devices.
Regards,
Clemens
10 Sep
10 Sep
9:09 a.m.
[...] the USB
specification. And it even appears like some vendors
are (finally!) starting to follow suit:
http://midiman.com/products/en_us/KeystationPro88-main.html
- "USB class compliant-no drivers required for
Windows XP or Mac OS X"
M-Audio started following suit only after they hung their engineers
with a USB cable and bought Evolution who had always made
class-compliant devices. 
2:55 p.m.
On Fri, 2004-09-10 at 07:49, Martijn Sipkema wrote:
The problem here is that class compliant devices suffer bad timing
because they use bulk transfers for MIDI data. The standard for
MIDI over FireWire is much better.
Hmm.. I'm just about to drop $400 on a USB MIDI interface (Edirol
UM-880), so that's not something I want to hear!
Is the timing really that bad? I don't even think a firewire 8x8
rackmount MIDI interface exists, so my options are kinda limited. :/
-DR-
[...] the USB specification. And it even appears like
some vendors
are (finally!) starting to follow suit:
http://midiman.com/products/en_us/KeystationPro88-main.html
- "USB class compliant-no drivers required for
Windows XP or Mac OS X"
M-Audio started following suit only after they hung their engineers
with a USB cable and bought Evolution who had always made
class-compliant devices.
3:26 p.m.
On Fri, 2004-09-10 at 07:49, Martijn Sipkema wrote:
The problem here is that class compliant devices suffer bad timing
because they use bulk transfers for MIDI data. The standard for
MIDI over FireWire is much better.
Hmm.. I'm just about to drop $400 on a USB MIDI interface (Edirol
UM-880), so that's not something I want to hear!
Is the timing really that bad? I don't even think a firewire 8x8
rackmount MIDI interface exists, so my options are kinda limited. :/
Timing is especially bad when there is other data being transferred on
the same USB bus, as is the case with combined audio/midi interfaces.
There are several USB interfaces that don't use the standard
MIDI-over-USB protocol, but I don't think information about these
protocols is available.
Perhaps there are interfaces that support both the standard protocol and
one with better timing...
--ms
[...] the USB specification. And it even appears like
some vendors
are (finally!) starting to follow suit:
http://midiman.com/products/en_us/KeystationPro88-main.html
- "USB class compliant-no drivers required for
Windows XP or Mac OS X"
M-Audio started following suit only after they hung their engineers
with a USB cable and bought Evolution who had always made
class-compliant devices.
4:56 p.m.
On Friday 10 September 2004 02:07 pm, Martijn Sipkema wrote:
"Especially bad" is still pretty vague. What might look bad on paper might be
acceptable in context...
On Fri,
2004-09-10 at 07:49, Martijn Sipkema wrote:
Hmm.. I'm just about to drop $400 on a USB MIDI interface (Edirol
UM-880), so that's not something I want to hear!
Is the timing really that bad? I don't even think a firewire 8x8
rackmount MIDI interface exists, so my options are kinda limited. :/
Timing is especially bad when there is other data being transferred on > [...]
the USB specification. And it even appears like some vendors
> are (finally!) starting to follow suit:
>
> http://midiman.com/products/en_us/KeystationPro88-main.html
>
> - "USB class compliant-no drivers required for
> Windows XP or Mac OS X"
M-Audio started following suit only after they hung their engineers
with a USB cable and bought Evolution who had always made
class-compliant devices.
The problem here is that class compliant devices suffer bad timing
because they use bulk transfers for MIDI data. The standard for
MIDI over FireWire is much better. the same USB bus, as is the case with combined
audio/midi interfaces.
Perhaps, but midi takes a lot less bandwidth than audio so how much worse
could it get? It sounds like it wouldn't be a problem if you were
overdubbing, but potentially in a live recording/performance if you are using
the audio ins for a vocal mic or whatnot.
There are several USB interfaces that don't use
the standard
MIDI-over-USB protocol, but I don't think information about these
protocols is available.
Perhaps there are interfaces that support both the standard protocol and
one with better timing...
--ms
6:59 p.m.
[...]
"Especially bad" is still pretty vague. What might look bad on paper might be
acceptable in context...
It's not unusable, but IIRC it can get to several ms of jitter.
I'm by no means an expert on this, but I think MIDI taking less bandwidth than
audio is not really relevant; it's audio data being isochronous and using a lot
of bandwidth causing the MIDI timing to suffer.
--ms
> > > The problem here is that class
compliant devices suffer bad timing
> > > because they use bulk transfers for MIDI data. The standard for
> > > MIDI over FireWire is much better.
[...]
Is the timing really that bad? I don't even think
a firewire 8x8
rackmount MIDI interface exists, so my options are kinda limited. :/
Timing is especially bad when there is other data being transferred on the same USB
bus, as is the case with combined audio/midi interfaces.
Perhaps, but midi takes a lot less bandwidth than audio so how much worse
could it get? It sounds like it wouldn't be a problem if you were
overdubbing, but potentially in a live recording/performance if you are using
the audio ins for a vocal mic or whatnot.
11 Sep
11 Sep
1:14 a.m.
On Friday 10 September 2004 05:40 pm, Martijn Sipkema wrote:
[...]
"Especially bad" is still pretty vague. What might look bad on paper
might be acceptable in context...
It's not unusable, but IIRC it can get to several ms of jitter.
I'm by no means an expert on this, but I think MIDI taking less bandwidth
than audio is not really relevant; it's audio data being isochronous and
True
> > > The problem here is that class
compliant devices suffer bad timing
> > > because they use bulk transfers for MIDI data. The standard for
> > > MIDI over FireWire is much better.
[...]
Is the timing really that bad? I don't even think
a firewire 8x8
rackmount MIDI interface exists, so my options are kinda limited. :/
Timing is especially bad when there is other data being transferred on the same
USB bus, as is the case with combined audio/midi interfaces.
Perhaps, but midi takes a lot less bandwidth than audio so how much worse
could it get? It sounds like it wouldn't be a problem if you were
overdubbing, but potentially in a live recording/performance if you are
using the audio ins for a vocal mic or whatnot. using a lot of bandwidth causing the MIDI timing to
suffer.
Right, but still, if one isn't planning on using the audio in concurrently
it's not an intolerable situation.
--ms
7:59 a.m.
On Fri, Sep 10, 2004 at 10:40:05PM +0100, Martijn Sipkema wrote:
[...]
"Especially bad" is still pretty vague. What might look bad on paper might be
acceptable in context...
It's not unusable, but IIRC it can get to several ms of jitter.
Why is that? The USB iso clock is every ms IIRC, so naively you
would expect the maximum jitter to be just under 1ms (if the bus was
saturated by audio transfers), and less in proportion to the degree of
saturation.
- Steve
> > > The problem here is that class
compliant devices suffer bad timing
> > > because they use bulk transfers for MIDI data. The standard for
> > > MIDI over FireWire is much better.
[...]
Is the timing really that bad? I don't even think
a firewire 8x8
rackmount MIDI interface exists, so my options are kinda limited. :/
Timing is especially bad when there is other data being transferred on
8:32 a.m.
[...]
It's not unusable, but IIRC it can get to several ms of jitter.
Why is that? The USB iso clock is every ms IIRC, so naively you
would expect the maximum jitter to be just under 1ms (if the bus was
saturated by audio transfers), and less in proportion to the degree of
saturation. > > > The problem here is that class
compliant devices suffer bad timing
> > > because they use bulk transfers for MIDI data. The standard for
> > > MIDI over FireWire is much better.
[...]
> Is
the timing really that bad? I don't even think a firewire 8x8
> rackmount MIDI interface exists, so my options are kinda limited. :/
Timing is especially bad when there is other data being transferred on
"Especially bad" is still pretty vague. What might look bad on paper might be
acceptable in context...
13 Sep
13 Sep
6:22 a.m.
Martijn Sipkema wrote:
> > It's not unusable, but IIRC it can get
to several ms of jitter.
>
> Why is that? The USB iso clock is every ms IIRC, so naively you
> would expect the maximum jitter to be just under 1ms (if the bus was
> saturated by audio transfers), and less in proportion to the degree of
> saturation.
USB transfers always wait for the beginning of the next frame, so the
maximum jitter is never less than 1 ms, even on an otherwise free bus.
Yes, one would expect that (if there are no other bulk
transfers), but
somehow this does not seem to be the case:
http://www-2.cs.cmu.edu/~eli/papers/icmc01-midiwave.pdf
These measurements include the jitter added by the drivers and by the
high-quality realtime-capable (yeah :-) Windows 98 scheduler.
I did some similar measurements under Linux, and it seems the jitter
isn't bigger than the expected 1 or 2 ms (2 because MIDI through
involves two USB transfers).
Regards,
Clemens
15 Sep
15 Sep
4:47 a.m.
> >
It's not unusable, but IIRC it can get to several ms of jitter.
>
> Why is that? The USB iso clock is every ms IIRC, so naively you
> would expect the maximum jitter to be just under 1ms (if the bus was
> saturated by audio transfers), and less in proportion to the degree of
> saturation.
USB transfers always wait for the beginning of the next frame, so the
maximum jitter is never less than 1 ms, even on an otherwise free bus.
Yes, one would expect that (if there are no other
bulk transfers), but
somehow this does not seem to be the case:
http://www-2.cs.cmu.edu/~eli/papers/icmc01-midiwave.pdf
These measurements include the jitter added by the drivers and by the
high-quality realtime-capable (yeah :-) Windows 98 scheduler.
I did some similar measurements under Linux, and it seems the jitter
isn't bigger than the expected 1 or 2 ms (2 because MIDI through
involves two USB transfers).
8 Sep
8 Sep
4:23 p.m.
On Wednesday 08 September 2004 09:34 am, Dave Phillips wrote:
Greetings:
I'm doing some research for an article about Linux MIDI support. In my
text I briefly describe the evolution of the MIDI specification since
its adoption, mentioning things like MIDI Time Code, MMC, the sample
dump standard, and the standard MIDI file. However, one item has me a
bit mystified. I'm unable to ascertain whether multi-port interfaces are
in fact described and supported by the spec. I checked the MMA docs
on-line, and I also have the Sciacciaferro/De Furia MIDI Programmers
Handbook, but nowhere do those sources indicate explicit support for
multi-port hardware. Are multi-port MIDI interfaces vendor-specific
solutions or is there actually an extension to the MIDI spec somewhere
that I'm just missing ? TIA!
It's implicit in the design. Ports are an object. Every MIDI entity has ports.
Racking then up on any physical entity is like adding cylinders to an engine.
Best regards,
dp
7170
days inactive
7177
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
7 participants
participants (7)
-
Clemens Ladisch -
Dave Phillips -
Dave Robillard -
Jens M Andreasen -
John Check -
Martijn Sipkema -
Steve Harris