W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: MIDI synchronization issues

From: James Ingram <j.ingram@netcologne.de>
Date: Mon, 01 Oct 2012 22:59:15 +0200
Message-ID: <506A0423.8070801@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,

I'll put it another way: There is going to be a synchronization problem 
when the timestamp property on sendMiDIMessage is implemented and 
PREQUEUE is increased.

Lets say the sendMIDIMessage timestamps are working as advertised, and 
we increase PREQUEUE to 500. That would mean in [1] that the 
reportTimestamp function would only be called ca. every 500ms, and would 
not be able to report the timestamp as often as it needs to. There is no 
way, as things stand, for the world outside the while{} loop to report 
the sending of events inside the loop at the time they are actually 
sent. I think this problem needs thinking about now. We don't need to 
wait for sendMIDIMessage timestamps to be implemented.

Whatever the answer is going to be, I think it also needs to take empty 
messages into account. Empty messages have lots of uses when 
synchronizing with other things going on on the same computer. Maybe one 
of MIDI's more obscure messages could be hijacked for the purpose, but 
the state of the output device should not change. Maybe someone has an 
idea in that direction?

Hope that's a bit clearer.

best,
James

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


Am 01.10.2012 20:21, schrieb Chris Wilson:
> Hey James -
> I'm not entirely sure what you're running in to, but I do want to be 
> clear - PREQUEUE other than zero will only work if the timestamp 
> property on sendMIDIMessage is implemented.  I don't know if it is, in 
> the polyfill you're using.
>
> On Sun, Sep 30, 2012 at 9:26 AM, James Ingram <j.ingram@netcologne.de 
> <mailto:j.ingram@netcologne.de>> wrote:
>
>     I've now updated the tick() function (both in the code and in the
>     gist) and the sound has indeed improved.
>     Among other things, the hairpin in bar 1 of Study 2c3.1 is now
>     working properly! :-))
>     Sorry to have cast aspersions on Jazz! Mea culpa!
>
>     The synchronization issues are still there.
>
>     all the best,
>     James
>
>     Am 30.09.2012 17:11, schrieb James Ingram:
>
>         ooops. Sorry.
>         Just discovered a serious bug in my version of the tick()
>         function.
>         Why do such things always happen just after hitting the send
>         button?
>         I don't think this affects the synchronization issues, but it
>         may well have something to do with the sound of the output.
>         Hope to have a correction out within a couple of hours.
>         j.
>
>         Am 30.09.2012 13:49, schrieb James Ingram:
>
>             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,
>             James
>
>             [1]
>             http://james-ingram.de/tests/AssistantPerformer_W3CAudio/AssistantPerformer.html
>             [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
>
>             [4]
>             http://james-ingram-act-two.de/compositions/sketches/study3Sketch/scores/Study%203%20sketch%201%20score/Study%203%20sketch%201.html
>
>
>
>
>
>
>     -- 
>     www.james-ingram-act-two.de <http://www.james-ingram-act-two.de>
>
>
>


-- 
www.james-ingram-act-two.de
Received on Monday, 1 October 2012 20:59:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:03 UTC