midilab / uClock

A tight BPM clock generator for Arduino and PlatformIO using hardware timer interruption. AVR, Teensy, STM32xx, ESP32 and RP2040 support
https://midilab.co/umodular
MIT License
165 stars 22 forks source link

Clock bug on Arduino board? #29

Closed dcrvx2100 closed 10 months ago

dcrvx2100 commented 11 months ago

Hi,

Thank you for creating this library.

I am testing a clock generator with uClock on Arduino and ESP32(M5stack). When changing Tempo from 77 to 76 on the Arduino board, the clock momentarily collapses. Could someone please check?

ArduinoIDE 2.2.1 Arduino UNO and Nano(uClock Ver. 0.10.0 to 1.5.1) NG. Arduino UNO and Nano(uClock Ver. up to 0.9.4) OK. ESP32(uClock Ver. 1.4.2) OK.

This is code for test. Three buttons are required. (D2,D3,D4)



include "Arduino.h"

include

define MIDI_CLOCK 0xF8

define MIDI_START 0xFA

define MIDI_STOP 0xFC

void ClockOut96PPQN(uint32_t tick) { Serial.write(MIDI_CLOCK); }

void setup() { pinMode(2, INPUT_PULLUP); pinMode(3, INPUT_PULLUP); pinMode(4, INPUT_PULLUP);

Serial.begin(31250);

uClock.init(); uClock.setClock96PPQNOutput(ClockOut96PPQN); uClock.setTempo(77);

uClock.start();

}

void loop() { if (digitalRead(2) == LOW) { uClock.setTempo(78); } if (digitalRead(3) == LOW) { uClock.setTempo(77); } if (digitalRead(4) == LOW) { uClock.setTempo(76); } }


Sorry if I am something wrong, and I apologize for my poor English. Thanks.

senorblasto commented 11 months ago

Yes because you are just changing the clock speed while ignoring what is going on in the background.

Look how it is done in the aciduino example

dcrvx2100 commented 11 months ago

Yes because you are just changing the clock speed while ignoring what is going on in the background.

Look how it is done in the aciduino example

Hi, Thank you for the reply.

I will refer to Aciduino for the actual program to make it better.

I've added minimal code to MidiClock.ino for someone to check.

I don't know why it is not stable only at the moment the BPM changes from 77 to 76, only when using the Arduino board.

Many Thanks,

midilab commented 11 months ago

Hi @dcrvx2100

I don't know why it is not stable only at the moment the BPM changes from 77 to 76, only when using the Arduino board. Can you give me more details about? how are you measuring the stability of clock? post the code you're using to reproduce the situation and related arduino microcontroller model.

dcrvx2100 commented 11 months ago

Hi, @midilab

Thank you for your reply, and great library.

I was testing to make a clock generator with an Arduino Uno (SMD R2) and a Sparkfun MIDI Shield, I noticed that the slave Roland TR-8S(or TB-3) would only falter when crossing 77 and 76 when up or down the tempo.

And I made a BPM Counter before, that says momentary slowdown between 77 to 76.

So, I changed to M5stack, it worked fine. And I tested Older version of this library with Arduino UNO and Nano, it works fine too.

Some information and simplest code for testing is my 1st post of this issue.

Many Thanks,

midilab commented 11 months ago

The best way to test the clock on your gears would be via buttons to increment or decrement tempo(make sure your code does handle the noises signals on buttons pressing and release).

Based on your code i can tell if there is a bad button or bad wiring noises can get into the reads and create a mess of unpredictable times changes between those 3 values you code [76, 77,78]. a increment and decrement button would be the ideal way of test, if noises comes in the worst cenario would be clock down or up some more bpms than expected but not changing between 3 values randomly(wich can cause clock issues).

Other than that, can you provide the exaclty version of uClock you tested against each setup and the results?

dcrvx2100 commented 11 months ago

Thanks for other code to test.

Yes, I prefer buttons instead of analog input too. So I tested buttons Inc/Dec version (with debounce) first, after that change to rotary encoder. Then I noticed clock problem as mentioned above. (uClock Ver. was 1.4.2) And back to primitive code....

Anyway, I'll try something test in a few days.

Many thanks,

midilab commented 11 months ago

I suggest you always try first the latest version wich is now: 1.5.1 If you could inform wich version you test that was ok against the one not ok based on your tests i'll appreciate that.

dcrvx2100 commented 11 months ago

Hi,

I already tested 1.5.1 and wrote that 1st post.

ArduinoIDE 2.2.1 Arduino UNO and Nano(uClock Ver. 0.10.0 to 1.5.1) NG. Arduino UNO and Nano(uClock Ver. up to 0.9.4) OK. ESP32(uClock Ver. 1.4.2) OK.

NG means clock problem happend. OK means work fine.

Thank you,

midilab commented 11 months ago

great! thanks for the informations and tests so far, i will try to reproduce the problem on my side firstly. i will keep you posted.

midilab commented 10 months ago

Hey @dcrvx2100

Could you test the latest version of the library on repo(not releases), a lots of changes and preparing to v2.

let me know if the problem still persists

dcrvx2100 commented 10 months ago

Hi, @midilab

I tested new version with simple code, and it works so fine! I look forward to release.

Thanks a lot!

midilab commented 10 months ago

great! good news! i've reword all the internals to support higher PPQNs resolution.

Thank you for test and debug! just finishing the regression tests and fix some little stuffs to release oficially.