[sdiy] MIDI Clock sync advice

[Amos]

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/2b00aee6/attachment.htm>