Subject: Re: [linux-audio-dev] Sequencer Sync Woes
From: Tim Goetze (tim_AT_quitte.de)
Date: Sat Feb 10 2001 - 02:01:17 EET
in the light that Paul shed on how 0xF8 sync is used, i think we both can
now implement sync on a somewhat firmer base ;)
.tim
On Feb 9 Stephane Letz wrote:
>>Billy Biggs wrote:
>>
>>> Do you calculate your position in the song based on the current time?
>>>That's no good for me. In my app, you need to be able to turn looping
>>>on and off, and move the loop mid-song. Otherwise, how can you play
>>>live?
>>>
>>> I usually have to sync to an external source: I have a TR-707 which
>>>can output DIN sync to my TR-606, but only if it's the sync master. So,
>>>I usually don't care too much about keeping track of the tempo myself.
>>
>>i did some more improvements to the time-based clock, and now i am
>>thinking about how to implement sync to external q/24. not so hard
>>to do with the current design, but one thing keeps bugging me, and
>>i'd like to know how you would (or do) handle it: in the interval
>>that passes between receiveing the first two 0xF8 signals, one cannot
>>afaik have any idea of what the tempo will be. do you say "oh well, i
>>don't know anything about the current tempo, so i'll do nothing til
>>the second signal comes in" or do you make an assumption on the tempo?
>>(or the third way: all MIDI messages are aligned to q/24 anyway so you
>>don't have to care about this at all ...)
>>
>>the first, lazy assumption would mean you'd possibly delay some MIDI
>>events by a couple of ticks; the second could mean that if you do
>>too fast a tempo, you'd have to rewind the 'MIDI tape'. i'm reluctant
>>to apply the first, do not like the second for doing something arbitrary
>>and cannot do the third because it isn't appropriate for complex
>>patterns in time.
>>
>>any ideas?
>>
>
>For my own sequencer library, i'm using the second solution, assuming a
>default tempo to play events between the first clock and the second clock.
>
>The general idea is that when a clock is received, the sequencer starts
>playing (using the current tempo) but only events which dates_in_ticks
>are inferior to the
>date_in_ticks of the next expected clock.
>
>When the next clock arrives, there are 2 cases:
>
>- estimated tempo was to high, events are already played
>- estimated tempo was to low, events are still not played, the new tempo is
>computed, and remaining events are played (in only one "clock slice"),
>actually at the same date (in millisecond).
>
>So with this method, there is no problem of "rewinding the MIDI tape". The
>tempo between the first and second clock is set to a default value.
>
>
>Stephane Letz
>
>
>Grame: Centre National de creation musicale
>9, Rue du Garet
>69001 Lyon
>Tel: 04-72-07-37-00
>Fax: 04-72-07-37-01
>Web: www.grame.fr
>
>
>
This archive was generated by hypermail 2b28 : Sat Feb 10 2001 - 02:27:38 EET