Re: [Lmuse-developer] Fixes to midi sync "Clock Output". Please try it now...

[Geoff B. <ge...@la...>]

hey allan, you seen this?

On Friday 13 March 2009 13:07:32 Tim wrote:
> **Please run muse on the command line and let me know if, and how often,
>  you get messages (which I added, permanently, to muse) like this:
> Dropped 6640 midi out clock(s). curTick:177070 midiClock:70828 div:16
>
> I recoded MidiSeq::processTimerTick().
> Tested OK with external synth, with multiple tempo changes
>  in song, and fooling around with global tempo.
>
> For best results please try running muse with a HIGH midi thread priority
>  (-P command line option, I believe lower numbers are higher priority -
>  try 1, not zero).
> AND
> Make sure the RTC resolution configuration setting is high (8192 best).
>
> **Warning: You may be disappointed by the target device's slow drift out
>  out of phase with muse (after about 20 bars or so).
> Other times, when moving the cursor around and playing, you may
>  have severe phase difference. Try playing from song beginning...
> Still some tweaking the code may be required, or replacing with
>  something more reliable, as I mentioned before.
>
> Tim.
>
>
>
> ---------------------------------------------------------------------
> Here are some rambling comments from MidiSeq::processTimerTick(),
>  for those of you too lazy to read the function:
> ---------------------------------------------------------------------
> // Keeping in mind how (receiving end) Phase Locked Loops (usually)
> operate... // Increment as if we had caught the timer exactly on the mark,
> even if the timer
> //  has passed beyond the mark, or even beyond 2 * div.
> // If we missed some chances to send clock, resume the count where it would
> have been,
> //  had we not missed chances.
> // We can't do anything about missed chances except send right away, and
> make up
> //  for gained time by losing time in the next count...
> // In other words, use equalization periods to counter gained/lost time, so
> that
> //  ultimately, over time, the receiver remains in phase, despite any short
> dropouts / phase glitches.
> // (midiClock only increments by div units).
> //
> // Tested: With midi thread set to high priority, very few clock dropouts
> ocurred (P4 1.6Ghz).
> // But target device tick drifts out of phase with muse tick slowly over
> time, say 20 bars or so,
> //  I believe because of the frequent major shifts (below).
> // May need more tweaking, possibly use round with/instead of lrint
> (above), and/or
> //  do not use equalization periods - set midiClock to fractions of div.
> //
> // Another issue: Sync pulses occasionally have a major shift to the left
> (and seem to affect
> //  the next several pulses).
> // This couldn't be caused by us sending the sync message here, at that
> time (look at this block's conditional).
> // This might be caused by the queue, further down the pipeline, but I
> thought our queue is in 'direct' mode?
> // Found some info about a experimental special sync queue by Takashi at
> alsa (2000).
> // www . alsa-project . org / ~tiwai / alsa-sync . html
> // Maybe using that would solve stability issues.
>
> ---------------------------------------------------------------------------
>--- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Lmuse-developer mailing list
> Lmu...@li...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer

-- 
Geoff Beasley
Composer,Arranger,Performer.
Laughing Boy Records Australia
www.laughingboyrecords.com