Re: MIDI synchronization issues

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>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<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 <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<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
>
>
>