From: . T. <ter...@ro...> - 2009-03-13 15:47:49
|
--- On Fri, 3/13/09, son...@ii... <son...@ii...> wrote: > Yeah saw this.. > Not sure if you saw my thread earlier .. where I mentioned > that setting MusE to > Master tends to crash my entire MIDI rig... I suspect some > kind of limitation to > the ALSA driver for my MIDI racks (AMT-8 and Unitor 8 Mk > II).. > > So it's not something I can really test.. But try it now. Simply turning the sync clock master on WAS causing my equipment to screw up too! But not now, since I fixed it. > > On Fri Mar 13 14:18 , Geoff Beasley sent: > > >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 |