<div dir="ltr">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. :)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 16, 2024 at 9:34 AM Amos <<a href="mailto:controlvoltage@gmail.com">controlvoltage@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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).<div><br></div><div>In any case, adding some mechanism like this can ensure that your clock output stays pretty well in sync with the beat.<br><br>On Saturday 16 March 2024, Spiros Makris via Synth-diy <<a href="mailto:synth-diy@synth-diy.org" target="_blank">synth-diy@synth-diy.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr" class="gmail_attr">On Fri, 15 Mar 2024 at 17:47, Roman Sowa via Synth-diy <<a href="mailto:synth-diy@synth-diy.org" target="_blank">synth-diy@synth-diy.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>If I may just add - maybe it's just my impression, but I think that new<br>generations of programmers educated today have absolutely no idea how<br>microprocessor works.<br><br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div> </div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 15 Mar 2024 at 17:47, Roman Sowa via Synth-diy <<a href="mailto:synth-diy@synth-diy.org" target="_blank">synth-diy@synth-diy.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
W dniu 2024-03-15 o 13:57, René Schmitz pisze:<br>
> <br>
> <br>
> The speed of processors roughly keeps up with programmers ability to <br>
> waste it.<br>
<br>
Yes, that's my feeling exactly<br>
<br>
> <br>
> My gripe is that, for beginner programmer, it does not necessarily teach <br>
> good practices, and even for a seasoned one it proliferates some bad <br>
> habits.  (How often is everything in loop()...)<br>
> <br>
> It's like giveing you a nice sugar coated piece of cake, so you might <br>
> never be motivated to learn how to bake a better one.<br>
<br>
hell yeah!<br>
<br>
If I may just add - maybe it's just my impression, but I think that new <br>
generations of programmers educated today have absolutely no idea how <br>
microprocessor works.<br>
<br>
<br>
> Back to MIDI: generally, when using the serial interrupt you have two <br>
> choices:<br>
> <br>
> Either make the ISR short, and for example just throw the data into a <br>
> buffer.<br>
> <br>
> Or do all the processing (which could take some time) there. Risk is <br>
> that you might block other ISRs, such as timers, which is of course bad.<br>
<br>
If I need a buffer, I usually process only MIDI clock inside ISR and put <br>
all other messages into the buffer. Less than 20 cycles worst case. But <br>
for example in my MIDI note decoder there's no buffer at all. The work <br>
is done before next byte comes in, so there's no chance of cluttering or <br>
missing a message.<br>
<br>
Roman<br>
________________________________________________________<br>
This is the Synth-diy mailing list<br>
Submit email to: <a href="mailto:Synth-diy@synth-diy.org" target="_blank">Synth-diy@synth-diy.org</a><br>
View archive at: <a href="https://synth-diy.org/pipermail/synth-diy/" rel="noreferrer" target="_blank">https://synth-diy.org/pipermail/synth-diy/</a><br>
Check your settings at: <a href="https://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" target="_blank">https://synth-diy.org/mailman/listinfo/synth-diy</a><br>
Selling or trading? Use <a href="mailto:marketplace@synth-diy.org" target="_blank">marketplace@synth-diy.org</a><br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>