[sdiy] MIDI Clock sync advice

René Schmitz synth at schmitzbits.de
Tue Mar 19 11:20:17 CET 2024

On 18.03.2024 09:42, Roman Sowa wrote:
> W dniu 2024-03-16 o 10:04, Spiros Makris pisze:
>> On Fri, 15 Mar 2024 at 17:47, Roman Sowa via Synth-diy 
>> <synth-diy at synth-diy.org <mailto: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.
> yes, that makes sense. Noone expects the java programmer to know how 
> computers work, because java is already created by people who don't 
> know that. And I bet the people commercially making websites in 
> WordPress are hired as "programmers".
> I was thinking rather about programmers writing operating systems like 
> Windows

The whole field has diversified and changed in the 40 odd years since I 
wrote my first BASIC program. If you're writing business or web 
applications you don't really need to know that much about the processor 
in detail. Neither did you for BASIC.

You'd better understand the details of the business requirements and how 
to get them implemented. (And as an addendum to my earlier remark, it's 
these req's that actually eat many of the clock cycles.)

Database applications are usually also far abstracted from machine 
words. Speed is often I/O bound with network and drives or memory being 
the bottleneck, so gaining a few ns with some processor tricks doesn't 
give you much.

But untangling the messy monstrous SQL that your predecessor wrote on a 
Friday afternoon, and is now yours to deal with, can get you more speedup.

Lots of problem domains are not really close to the metal. Embedded, 
device drivers and operating systems are really among the few domains I 
can think of, where an intricate knowledge of hardware is required.

IMO programming should be more about algorithms and data structures than 
hardware. Architectures come and go....

>> 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.
> The USB alone makes 1ms jitter. I was observing MIDI clock out on an 
> oscilloscope and no matter what I do, the clock coming out of MOTU 
> interface is 1ms jittery AF
It's aliasing, sample rate is 1kHz.

> if incoming clock suddenly increases frequency, you have no chance to 
> output enough number of clock before next pulse comes. So I had a wild 
> idea to simply add all thoise missing MIDI clocks right away, back to 
> back, so the receiving side will not loose any clock.

Midi clearly lacks a "tempo change" announcement message. The midi file 
format has that though.



synth at schmitzbits.de

More information about the Synth-diy mailing list