|
From: Geoff B. <ge...@la...> - 2009-03-13 03:19:48
|
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 |