- From: Chris Wilson <cwilso@google.com>
- Date: Mon, 1 Oct 2012 16:57:53 -0700
- To: James Ingram <j.ingram@netcologne.de>
- Cc: public-audio@w3.org, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Joseph Berkovitz <joe@noteflight.com>
- Message-ID: <CAJK2wqWsB+vKs2tgVD7=Tv8gtYTxNv7mqbrgeoiuP1GuWtyTow@mail.gmail.com>
I think we're talking at cross purposes. There will not be any way to get
a precise timestamp of when a MIDI message is ACTUALLY sent; the underlying
hardware may not report that, and we don't have any callback mechanism that
has a super-high-precision timing itself (below 1ms, and the slop in
setTimeout/Interval is, as you've found, >1ms).
You can keep PREQUEUE very small, at the cost of precision and running the
callback frequently; then you can "report" the timing more closely to the
time the MIDI messages are actually enqueued, but again, we don't have a
callback to tell you when it is "REALLY" sent.
I'm not sure what you mean by empty messages and synch across programs on
the same machine. We cut virtual MIDI ports from the goals for v1; but
regardless, we're not adding to or modifying the MIDI spec. There are
messages you could use for most types of synchronization, but I'm not sure
what you're looking to do.
On Mon, Oct 1, 2012 at 1:59 PM, James Ingram <j.ingram@netcologne.de> wrote:
> 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 <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<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 <http://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 23:58:23 UTC