[sdiy] MIDI Clock sync advice

[Benjamin Tremblay]

I am certain that an Arduino UNO can parse MIDI clock bytes and transmit pulses to other hardware with ease.
I have used loop() and I have used timers. 
I have read raw bytes and I have used the Arduino MIDI Library. 

What I have found is the Arduino MIDI Library has touchpoints for any clever optimization you can think of. You can ignore everything but a MIDI clock.
You can call read() on a timer. You can also call read() in loop() monitor the buffer in a timer. It’s C++ so you can extend the classes. 

You can’t make something from nothing. I got hung up on supporting tight MIDI-to-TTL clock conversion using the MIDI from Roland grooveboxes. It’s just not possible. 
I purchased a PIC-based MIDI clock kit from deftaudio and I’m certain that thing synthesizes a tempo clock by dead reckoning the MIDI pulses. Awesome thing. But could not handle the crap MIDI coming out of 1990s groove boxes. 

Modern MIDI setups are usually way simpler than what we were (wasting out time) doing in the 1990s. We were obsessed with utilizing full multi-timbrality and getting our money’s worth out of 16-32 tracks of MIDI.  Nowadays, the four tracks on a Digitone seem like overkill for MIDI work. We want 64+ voices of polyphony on a single channel, and a dedicated synth/plugin for each patch.

The Arduino Mega (in the Pro Mini format) is an ideal MIDI sandbox for me. Lots of pins. Lots of ports. Plenty of RAM.  Ten dollah. I was able to scan the trigger bus on the Roland CR-5000 and write the pulses to the analog board very effectively. This allowed me to mix-in external MIDI triggers to the bus using boolean logic. And, it read external MIDI clock. This worked great with a rock-steady vintage sequencer like the Yamaha QY-20, but crashed and burned with the old Roland groove boxes. 

Making a “product” that “just works” for MIDI is getting harder because managing expectations is getting harder. Do you make it work for everyone under any conditions? Do you target a DAW as a primary use case? Etc. 





Benjamin Tremblay
btremblay at me.com
Carlisle, MA 01741







> On Mar 15, 2024, at 11:45 AM, Roman Sowa via Synth-diy <synth-diy at synth-diy.org> wrote:
> 
> 
> 
> W dniu 2024-03-15 o 13:57, René Schmitz pisze:
>> The speed of processors roughly keeps up with programmers ability to waste it.
> 
> Yes, that's my feeling exactly
> 
>> My gripe is that, for beginner programmer, it does not necessarily teach good practices, and even for a seasoned one it proliferates some bad habits.  (How often is everything in loop()...)
>> It's like giveing you a nice sugar coated piece of cake, so you might never be motivated to learn how to bake a better one.
> 
> hell yeah!
> 
> 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.
> 
> 
>> Back to MIDI: generally, when using the serial interrupt you have two choices:
>> Either make the ISR short, and for example just throw the data into a buffer.
>> Or do all the processing (which could take some time) there. Risk is that you might block other ISRs, such as timers, which is of course bad.
> 
> If I need a buffer, I usually process only MIDI clock inside ISR and put all other messages into the buffer. Less than 20 cycles worst case. But for example in my MIDI note decoder there's no buffer at all. The work is done before next byte comes in, so there's no chance of cluttering or missing a message.
> 
> Roman
> ________________________________________________________
> This is the Synth-diy mailing list
> Submit email to: Synth-diy at synth-diy.org
> View archive at: https://synth-diy.org/pipermail/synth-diy/
> Check your settings at: https://synth-diy.org/mailman/listinfo/synth-diy
> Selling or trading? Use marketplace at synth-diy.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20240316/d557c8d8/attachment.htm>