Hi, some of you might like to know... All the discussion of tempo maps and sync in the Jack lists forced me to get off my butt and finally fix MusE's midi sync in. (Someone asked recently in the Jack lists if there are any apps which sync properly. Here is one answer). Until now, MusE responded to midi sync by calculating the sync's tempo. Then, this tempo together with the sample rate and current frame, determined what 'tick' MusE was currently at. And of course, ticks drive a midi engine to produce the notes at particular times. Because a tempo value was used, sub-tick (frame) resolution was available. Trouble is, that was the problem, a too-lofty goal. It used a complicated 24-stage clock tempo filter while playing, and a simpler three-stage filter while idling in stop mode. This meant it could not respond to fast changes in tempo, even a simple step. It was prone to drift, even without tempo changes. Considering incoming tempo can drift slightly, I had originally recorded the incoming tempos to a list so I would have and exact record of the whole 'time line'. But the whole idea of using tempo seemed odd. So my idea was to 'direct drive' (increment) the midi engine's tick counter by the incoming sync messages. Drift between master and slave has been essentially eliminated. Response is instantaneous. The only slight drawback is the resolution. I've abandoned any notion of using a tempo or tempo map, or to obtain sub-tick (frame) resolution, during external sync. At standard 24 ticks per quarter note, resolution is 1/3 of a 64th note. Not too shabby, acceptable for music. Now I'm thinking, this is probably how sync was designed to be used, considering simple old 80's hardware - (what clock filtering?). Extreme stress tests with a Roland TR-505 which has an adjustable 'analog' tempo pot, and a complete song in the app, with extra 'tick' tracks driving external synths: Rock solid and stable, even when going absolutely nuts with the tempo knob! No noticeable resolution effects. In our SVN repo now. Tim.