W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

MIDI synchronization issues

From: James Ingram <j.ingram@netcologne.de>
Date: Sun, 30 Sep 2012 13:49:25 +0200
Message-ID: <506831C5.1070506@netcologne.de>
To: Chris Wilson <cwilso@google.com>
CC: public-audio@w3.org, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Joseph Berkovitz <joe@noteflight.com>
Hi Chris, Jussi, Joe, all,

I have now implemented a Sequence object, and am using it in [1].
This program is a "work in progress" and does not yet implement MIDI 
Input, but it can be used to play back SVG-MIDI scores. For usage, see [2].

I had to make a few changes to Chris's tick() function, and have run 
into a couple of synchronization issues. My current tick() function [3] 
depends on PREQUEUE being 0. If PREQUEUE were to be increased, exact 
synchronization with the score would deteriorate. There would be no way 
of knowing exactly when the MIDIMessage is really sent. Something needs 
to be done to ensure that exact synchronization will always be possible. 
There will be other things that need to be synchronized with 
MIDIMessages, not just running cursors. Another problem is the current 
non-existence of empty messages.

This is not really my sphere, but it might help to understand the 
problem if I say where I'd start looking for a solution:
1. MIDIMessages could have an optional callback, to be called at their 
actual send time. But that would not work for rests. Rest messages are 
currently never sent to the MIDI output device at all. Maybe we need a 
wrapper for MIDIMessages which would include both the callback and the 
information that this is an empty message. Empty messages need to be 
part of the spec too. If you are not convinced, try playing a track 
containing just simple notes and rests. Rests sometimes contain note-off 
messages, but sometimes they are really EMPTY (e.g. when two rests are 
separated by a barline).
2. Currently, MIDI programmers/libraries can set the value of PREQUEUE 
themselves, allowing different applications to be given optimal values. 
What, precisely, are the pros and cons of having larger values?

Maybe the following belongs in a separate thread, but I'd like to 
mention it anyway:
I'm currently not entirely happy with the sound of the output (its not 
always exactly the same, and it sounds rather scratchy compared to 
playing the same scores in C#).
I know I'm pushing things a bit, but I suspect that Jazz is a bit slow, 
especially when it comes to sending continuous controller info (I'm 
currently testing Jazz's speed). For example, the first (ornamented) 
chord in track 1 of Study 2c3.1 contains repeated notes and a simple 
expression hairpin (cresc.-dim.) but, if the hairpin is played at all, 
it is not being performed as smoothly as the MIDI info says it should. 
Also, the tracks in Study 3 sketch don't sound as they should (there's 
an mp3 at [4]). This is only a sketch, and the tracks in bar 1 are 
really only tests, which should be played separately...
As I said, I think its a Jazz problem. I don't think its my javascript 
because these things do sometimes work better. Are you sure it is not a 
problem with Javascript itself?

all the best,

[2] usage:
To start, just select a score and MIDI output device (optionally setting 
the speed option) and hit "Start".
The controls along the top of the score should be fairly self 
explanatory. From left to right:
1. track selector (= staves, in top to bottom order).
2. player controls:
     a) go, pause, paused
     b) stop
     c) set start position tool
     d) set end position tool
     e) send start position to beginning of score (default position)
     f) send end position to end of score (default position)
3. (currently disabled) toggles between playing live and playing the 
MIDI stored in the score
4. set options: click this to reset the options in the upper dialog.

[3] https://gist.github.com/3806262


Received on Sunday, 30 September 2012 11:50:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:11 UTC