Timing limits of MIDI events

#1

Hello!
I am new to this but I just watched a few reviews and read some documentation and I think I want to buy an organelle M for myself.
I’m used to making my own stuff and recently I started to build a multi tempo sequencer with Arduino. It was not easy though since I had to play with the limitations of the hardware in terms of how many tics per seconds you can play with and the performance limits of synchronizing them with multiple events.

How does it work with the Organelle M? what are the limits related to timing and latency/synchronization of MIDI events?

#2

All of the MIDI processing / programming on the Organelle is done in Pure Pata (Pd). The timing granularity is limited by the Pd scheduler which runs each DSP block, 64 samples or about 1.5ms. This is usually sufficient for anything in the MIDI domain. Latency depends more on the stuff ‘outside’ Pd, the MIDI interface (or the 1/8" jacks on the M), if it is connected to USB hub, etc.

The experience in terms of programming and timing / latency will be very similar to just running Pd on your computer (and a USB MIDI interface), if you’d like to try it out.

#3

Maybe I’m not approaching the concept of coding for the Organelle appropriately, but when I am coding for Arduino, about timing of events I can go as deep as the internal clock, which is 16Mhz. So when I want to make a grid of events I can setup a hierarchy that starts, lets say around 200k interupts per second if I consider that my instructions will occupy 80 clock cycles (not super reallistic but you have the idea, ~1k/s is more usable).
I know the Organelle’s clock goes 100 times faster but there is an OS and all. Can I go somehow that deep with the Organelle or am I limited to 64 “interrupt”/trigger/event per second like you suggested?

#4

Yes, the approach for coding Arduino is different.

It’s 64 samples , a sample is 1/44100 of a second - not 64/second :wink:

What are you trying to do?

Like anything , there are always trade offs etc, it’s all about choosing the right tool for the job.

#5

You can think of Pd firing an interrupt every 64 audio samples. The audio rate is 44100 samples / sec, so the interrupt is firing 44100 / 64 = 689 times per second, which is a period of 1.45 milli seconds.

But there are many high level objects in Pd for dealing with timing: delays, metronomes, timers, sequencers… With many of these objects, timing is specified in units of milli seconds. So usually you don’t have to think in terms of low level things like interrupts when designing patches. That is what is nice about Pd, it provides high level framework for dealing with timing and events.

#6

Thank you very much for that answer, I’ll start messing with pd while my unit makes it to the store ;D

#7

I want to build a multi-tempo arp. So the higher my base frequency is, the more complex/rich the resulting interaction can be. At least that was how I needed to proceed on Arduino (+ I was sending on 3 different MIDI OUT) but maybe here it is different :slight_smile: