[sdiy] MIDI Clock sync advice

Amos controlvoltage at gmail.com
Sat Mar 16 15:38:13 CET 2024


PS) I just re-read the end of your message and saw that you were thinking
of exactly the mechanism I suggested (hard-syncing the output every quarter
note). I don't know whether it seems wrong or not, but I can confirm that
it does the job. :)

On Sat, Mar 16, 2024 at 9:34 AM Amos <controlvoltage at gmail.com> wrote:

> One small thought I’d add is that once you’re happy with your
> clock-frequency detection, one way to handle phase is to every so often do
> a hard-reset of your output timer phase on receipt of an incoming clock, so
> that you output a clock at the next possible instant. I suppose you could
> be fancy and keep track of the time delta by which your output leads/lags
> incoming clocks, and reset phase when this drifts beyond an acceptable
> measure, but in practice I think I’ve just done this every quarter note or
> something like that (it’s been a while).
>
> In any case, adding some mechanism like this can ensure that your clock
> output stays pretty well in sync with the beat.
>
> On Saturday 16 March 2024, Spiros Makris via Synth-diy <
> synth-diy at synth-diy.org> wrote:
>
>> On Fri, 15 Mar 2024 at 17:47, Roman Sowa via Synth-diy <
>> synth-diy at synth-diy.org> wrote:
>>
>>>
>>> If I may just add - maybe it's just my impression, but I think that new
>>> generations of programmers educated today have absolutely no idea how
>>> microprocessor works.
>>>
>>>
>> That feels true, but we should keep in mind that "programmer" has been a
>> continuously expanding group of people, and you can now be a programmer
>> starting from a wild variety of disciplines, most of which don't start from
>> the bottom, as is customary in electrical engineering and (sometimes)
>> computer science degrees. Most programs I know of have computers and
>> operating systems as a standard class, but microcontrollers and embedded
>> systems as an elective. That is, you can't become an embedded programmer
>> "by accident", unlike python, java and others, which any STEM major will
>> have some knowledge of.
>>
>> I gave it a quick try on a teensy 4. I used USB-MIDI and fed a clock from
>> Ableton, without using interrupts. I made all the wrong choices, I know.
>> So my strategy was to create something that resembles a phase frequency
>> detector: I created an internal clock that will run at double the speed of
>> the incoming clock, and implemented a /2 divider. I am listening for clocks
>> from either USB or the internal clock, and switch between decreasing and
>> increasing a count variable based on the lead-lag relationship of the
>> incoming messages. The result resembles the functionality of a PFD coupled
>> with a charge pump/integrator filter, and it does lock to the incoming
>> tempo. It will follow abrupt tempo changes reasonably fast, but then sync
>> between beats is lost. Furthermore, I can see the PFD values fluctuating,
>> which does happen in such a configuration, but I would expect less of a
>> ripple under a good lock. I suspect Ableton clocks are fairly jittery
>> through USB, so I'll give it another go using a more stable clock and
>> figure out if the ripple is system instability or Ableton acting up.
>> Another approach I intend to try is simply measuring the incoming
>> frequency using a reference timer and then assigning the value (multiplied
>> by a factor) to a second timer to act as a clock. I know it will more or
>> less work, but doesn't really have any syncing mechanism; I expect the
>> resulting beats will be out of sync.
>> I am contemplating adding a syncing mechanism that keeps track of the
>> number of incoming beats and introducing a secondary feedback mechanism
>> following the quarter notes. It feels like a wrong approach though.
>>
>>
>> On Fri, 15 Mar 2024 at 17:47, Roman Sowa via Synth-diy <
>> synth-diy at synth-diy.org> wrote:
>>
>>>
>>>
>>> W dniu 2024-03-15 o 13:57, René Schmitz pisze:
>>> >
>>> >
>>> > The speed of processors roughly keeps up with programmers ability to
>>> > waste it.
>>>
>>> Yes, that's my feeling exactly
>>>
>>> >
>>> > My gripe is that, for beginner programmer, it does not necessarily
>>> teach
>>> > good practices, and even for a seasoned one it proliferates some bad
>>> > habits.  (How often is everything in loop()...)
>>> >
>>> > It's like giveing you a nice sugar coated piece of cake, so you might
>>> > never be motivated to learn how to bake a better one.
>>>
>>> hell yeah!
>>>
>>> If I may just add - maybe it's just my impression, but I think that new
>>> generations of programmers educated today have absolutely no idea how
>>> microprocessor works.
>>>
>>>
>>> > Back to MIDI: generally, when using the serial interrupt you have two
>>> > choices:
>>> >
>>> > Either make the ISR short, and for example just throw the data into a
>>> > buffer.
>>> >
>>> > Or do all the processing (which could take some time) there. Risk is
>>> > that you might block other ISRs, such as timers, which is of course
>>> bad.
>>>
>>> If I need a buffer, I usually process only MIDI clock inside ISR and put
>>> all other messages into the buffer. Less than 20 cycles worst case. But
>>> for example in my MIDI note decoder there's no buffer at all. The work
>>> is done before next byte comes in, so there's no chance of cluttering or
>>> missing a message.
>>>
>>> Roman
>>> ________________________________________________________
>>> This is the Synth-diy mailing list
>>> Submit email to: Synth-diy at synth-diy.org
>>> View archive at: https://synth-diy.org/pipermail/synth-diy/
>>> Check your settings at: https://synth-diy.org/mailman/listinfo/synth-diy
>>> Selling or trading? Use marketplace at synth-diy.org
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20240316/6b05302f/attachment.htm>


More information about the Synth-diy mailing list