Yahoo Groups archive

Disklavier

Index last updated: 2026-04-28 23:20 UTC

Message

Re: [disklavier] Floppy Disk Storage adn Organization

2001-06-30 by Mark A. Fontana

On Fri, 29 Jun 2001 PianoBench@... wrote:

> Regarding playback of MIDI files from the computer:
> 
> In a message dated 6/29/01 6:20:47 AM, mfontana@... writes:
> 
> << With notes being played as they're received, it's impossible to specify
> that multiple notes be struck simultaneously.  Using running status, a 
> three-note chord would require a minimum of almost 19 ms to transmit via
> MIDI, or about 28 ms without.  A larger chord with note-offs and pedal data
> mixed in could slow things much more. >>
> 
> This is an interesting issue. Most MIDI devices--which receive and react in 
> real-time--would have to play those 3 note-on messages one at a time. 
> Although I don't know how the Disklavier handles this issue, I think that it 
> should be able to use the 500 ms delay to its advantage.
> 
> In theory, if running status is used, the 500 ms delay should enable the 
> Disklavier to understand that the hammers of the 3-note chord are intended to 
> strike together. In other words, the structure of the running status message 
> contains enough information to tell the Disklavier that the 2nd and 3rd notes 
> should be played at the same time as the first note.


I'm pretty certain that running status can't solve this problem.  Running
status only serves as a means of reducing MIDI bandwidth, basically
permitting subsequent events of the same MIDI command to be sent without
the command byte.  It doesn't imply anything about the timing of the
events.

As an example, three note-ons:

90 60 7F
90 61 7F
90 62 7F

could be sent with running status as:

90 60 7F
61 7F
62 7F

In both cases, the three notes will inevitably be struck one at a time as
the messages are received, even though we intended them to be struck
simultaneously.

There's nothing to prevent you from inserting a delay between events:

90 60 7F
(wait 300 ms)
90 61 7F
(wait 1500 ms)
90 62 7F

You still have to insert the proper amount of delay when sending this with
running status employed:

90 60 7F
(wait 300 ms)
61 7F
(wait 1500 ms)
62 7F


The Disklavier can't use its 500 ms processing delay to figure out when
notes were intended to be struck at the same time.  It just receives a
stream of bytes with no timing information beyond noting the time each byte
was received.  With the events arriving serially, it can't differentiate
between the case when the events were intended to occur simultaneously and
the case when they were truly intended to occur in sequence.  It could try 
and make a best guess, but it would sometimes be wrong...

One way to reduce the amount of error would be to increase the transmission 
rate; instead of using MIDI, use the TO HOST connector at the fastest speed
it will support.  What's the highest speed the Disklavier controller will
support?


--
Mark A. Fontana
Minneapolis, MN

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.