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

Re: MIDI synchronization issues

From: James Ingram <j.ingram@netcologne.de>
Date: Sun, 30 Sep 2012 17:11:18 +0200
Message-ID: <50686116.5070409@netcologne.de>
CC: Chris Wilson <cwilso@google.com>, public-audio@w3.org, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Joseph Berkovitz <joe@noteflight.com>
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.

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 

Received on Sunday, 30 September 2012 15:12:01 UTC

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