<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I notice I "misspoke" there a little -<div class=""><br class=""></div><div class="">I should have said that for a *period* of 3.25, the output would be cycles of *period* 3 and *period* 4: 3,3,3,4,3,3,3,4,3,3,3,4,etc<div><br class=""><blockquote type="cite" class=""><div class="">On 27 Oct 2024, at 16:14, Mike Bryant <<a href="mailto:mbryant@futurehorizons.com" class="">mbryant@futurehorizons.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><ul data-editing-info="{"applyListStyleFromLevel":false,"unorderedStyleType":4}" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><li style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;" class=""><div class="elementToProof">It's inherent to any digital NCO, not the PIC#s example specifically. For most frequencies, the frequency increment will not be a neat divisor of the accumulator wraparound value. This means that there will be a slight jitter in the output frequency. One way to think about it is that the NCO creates a frequency by averaging. So if we wanted a frequency of 3.25, the output would be cycles of frequency 3 and frequency 4: 3,3,3,4,3,3,3,4,3,3,3,4,etc</div></li></ul><div id="appendonsend" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;"><br class=""></div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;">This is of course a problem even in a totally digital domain. The easiest solution there is to sum weighted inputs from the final sample and last but one sample, varying the weighting according to where you are in the sequence. Of course this is easy in digital but would require some fancy VCA work plus a sample and hold to store the last output from the BBD which would become the 'last but one' sample.</div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;"><br class=""></div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;"><br class=""></div><hr style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline-block; width: 802.609375px;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class=""></span><div id="divRplyFwdMsg" dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="font-family: Calibri, sans-serif; font-size: 11pt;" class=""><b class="">From:</b> Synth-diy <<a href="mailto:synth-diy-bounces@synth-diy.org" class="">synth-diy-bounces@synth-diy.org</a>> on behalf of Tom Wiltshire <<a href="mailto:tom@electricdruid.net" class="">tom@electricdruid.net</a>><br class=""><b class="">Sent:</b> 27 October 2024 14:00<br class=""><b class="">To:</b> Didier Leplae <<a href="mailto:didierleplae@yahoo.com" class="">didierleplae@yahoo.com</a>><br class=""><b class="">Cc:</b> SDIY <<a href="mailto:synth-diy@synth-diy.org" class="">synth-diy@synth-diy.org</a>><br class=""><b class="">Subject:</b> Re: [sdiy] Frequency shifted from BBD?</span><div class=""> </div></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-size: 11pt;" class="">Brian already gave a comprehensive answer, but here's my own take.<br class=""><br class="">> On 25 Oct 2024, at 21:47, Didier Leplae <<a href="mailto:didierleplae@yahoo.com" class="">didierleplae@yahoo.com</a>> wrote:<br class="">><br class="">> Do you think this is specifically a problem with the PIC’s hardware NCO or do you think this is inherent to any digital clock?<br class=""><br class="">It's inherent to any digital NCO, not the PIC#s example specifically. For most frequencies, the frequency increment will not be a neat divisor of the accumulator wraparound value. This means that there will be a slight jitter in the output frequency. One way to think about it is that the NCO creates a frequency by averaging. So if we wanted a frequency of 3.25, the output would be cycles of frequency 3 and frequency 4: 3,3,3,4,3,3,3,4,3,3,3,4,etc<br class="">This jitter pattern has a much lower frequency than the actual output frequency, and can be within the audible range even for multiple-100KHz or MHz outputs.<br class=""><br class="">> There seem to be a bunch of BBD based devices that have tap tempo for example, which I imagine must be done with a uP.<br class=""><br class="">Yes. There are other ways of creating a digital clock that don't have the jitter problems of NCOs. For a tap tempo delay, I would use a divider-based system, since this provides an output with no jitter.<br class="">A divider-based clock isn't feasible for a flanger because the steps between frequencies cannot be made small enough over a wide enough range - or at least, not on the hardware I was using. It *might* be possible on some chip with a much higher clock frequency and a much bigger divider.<br class=""><br class="">> In fact I make already make a delay module like this, but it seems to present more of a problem with chorus and flanger circuits because of the higher frequencies.<br class=""><br class="">Yes. It's not only to do with the higher frequency, but also the need to sweep the frequency, which implies the need to have imperceptibly small steps between all the frequencies you can generate. For a tap tempo delay, that wouldn't matter, and if the available clock frequencies provided outputs that were even several milliseconds apart, that would be close enough (who can tap more accurately than 5milliseconds anyway?).<br class=""><br class=""><br class=""><br class="">________________________________________________________<br class="">This is the Synth-diy mailing list<br class="">Submit email to:<span class="Apple-converted-space"> </span><a href="mailto:Synth-diy@synth-diy.org" class="">Synth-diy@synth-diy.org</a><br class="">View archive at:<span class="Apple-converted-space"> </span><a href="https://synth-diy.org/pipermail/synth-diy/" id="OWA57e8f96f-2363-2571-51c4-463c29972085" class="OWAAutoLink" data-auth="NotApplicable">https://synth-diy.org/pipermail/synth-diy/</a><br class="">Check your settings at:<span class="Apple-converted-space"> </span><a href="https://synth-diy.org/mailman/listinfo/synth-diy" id="OWAd62e28f4-dc44-249d-85b2-9bf5c2c7a000" class="OWAAutoLink" data-auth="NotApplicable">https://synth-diy.org/mailman/listinfo/synth-diy</a><br class="">Selling or trading? Use<span class="Apple-converted-space"> </span><a href="mailto:marketplace@synth-diy.org" class="">marketplace@synth-diy.org</a></div></div></blockquote></div><br class=""></div></body></html>