[sdiy] Techniques for Multiplying MIDI Clock frequency?

Brian Willoughby brianw at audiobanshee.com
Sat Dec 18 23:04:22 CET 2021


It's tempting to think of code design in (individual) human terms - as if you could shrink yourself down small enough to fit inside the processor and handle everything yourself. If that were the best approach, then you might be waiting around doing nothing but counting to 12 before taking action to flip an output pin.

The problem is: this isn't very efficient. It's like the small business that fails because the owner is trying to do everything (instead of delegating many tasks to specialists). A CPU can only execute one thing at a time, so even "waiting around doing nothing" takes a few cycles, causing delays when something finally does happen.


Instead, it's helpful to think of a team of multiple people with a manager, or a band with a band leader / conductor. How does a tight rhythm section stay in sync? Do the drummer and bassist each wait around doing nothing until the other one hits the down beat? No: each musician builds an internal tempo model, anticipates when the beat will hit, and then plays accordingly (with built-in mental compensation for internal delays between thoughts and muscle reactions).

So, a good MIDI system is going to separate the task of following incoming PPQ from generating its own music events and clock. This internal tempo is most likely going to be a timer peripheral. Incoming PPQ are all considered as contributing to the model of the actual tempo. The timer drives the musical events and clock, but there's no "waiting around doing nothing," at least not anywhere in the timing-critical code. It's not exactly a perfect analogy with a band, because the operations are divided along different lines, but the key is to think of individual pieces - each handling a very specific aspect of the overall device - but coordinated to produce the desired result.


By the way, there is one kind of processor that literally does wait, doing nothing, until something happens. This is the XMOS series of processors. They have lots of cores - at least 8 or probably 16 cores - where the code designer separates the overall features into separate parts. A single core will literally block until a particular hardware event, and then that core can start up faster even than an interrupt handler on a "normal" processor. Some processors have a "wait" opcode, but it stops everything, whereas the XMOS can stop each core independently so that things can happen.

Normally, though, you're going to have hardware peripherals driving pins directly, or (timer) interrupts driving operations with minimal latency overhead. It's all about designing around multiple "moving" parts, rather than trying to design everything into a single thread of code.

Brian


On Dec 18, 2021, at 13:00, Benjamin Tremblay wrote:
> If I’m waiting around doing nothing until I count 12 pulses, all that matters is I construct a square wave 12 pulses long.
> 
> Benjamin Tremblay
> 
> On Dec 18, 2021, at 3:56 PM, Benjamin Tremblay wrote:
>> I’m assuming all it does is divide by 12 to get a 16th note. 
>> 
>> Benjamin Tremblay
>> 
>> On Dec 18, 2021, at 3:53 PM, Pete Hartman wrote:
>>> On Sat, Dec 18, 2021 at 2:15 PM Benjamin Tremblay wrote:
>>>> 2) I wish I understood the theory of clock multipliers. I have seen code that measures the period between clock pulses and dead reckons the double-time pulse as an average of the recent periods. But why? Why can’t I just fire another extra HIGH-LOW pulse whenever I get a MIDI clock event? Why does timing of the extra ticks matter?  I’m assuming 48 PPQ divides the clock down to individual sequencer steps on the KPR-77. As long as the divided clock is coming in on the beat, what does it matter if some of the synthetic pulses are a little off? (They’re just shadows of the main tempo clock). It’s not like the KPR-77 is inferring something or trying to calculate BPM from the external clock… So… Anyway I just wish I knew what I was aiming for, and then maybe I could hit the target.
>>>> 
>>> One suspects that most people are trying to write a general purpose converter.  E.g. you could run those 48ppq out to some other module, like an analog sequencer, and it would keep time.  I'm not familiar with the KPR-77, but I'm also slightly puzzled by the idea that some piece of gear would require 48PPQN but not care about the timing of half of the pulses.
>>> 
>>> Pete 





More information about the Synth-diy mailing list