Midipal analog clock to midi-clock

Would it be possible for the midipal (+firmware customization) to read a clock on it’s analog IOs and to generate a midi-clock accordingly?
Goal: I would like to use the audio out from the daw to synchronise an hardware sequencer. This is the technique used by some commercial products from Innerclock Systems or Expert Sleepers (a discussion related to those products has been started here)
I found this piece of code from the anushri.
From what I understand, you sample the input with a timer set to 4,9Hz. How do you calculate the maximum (sampling) jitter? 1/4900 ~ 0,2ms?
What are the other potential sources of jitter? Variable number of cycles spent in the ISR?

Thanks!

> Would it be possible for the midipal (+firmware customization) to read a clock on it’s analog IOs and to generate a midi-clock accordingly?

They are not just analog inputs - you can use them as general I/O pins, so I would recommend you to have a little circuit that thresholds/conditions the signal from the DAW (I have no idea how it looks), so that you have a clean digital signal. It’s much faster to acquire digital signal than have something analog go through an ADC.

> What are the other potential sources of jitter? Variable number of cycles spent in the ISR?

None, I rarely do much in my ISRs. Anyway, that’s the Anushri codebase :slight_smile:

In MIDIpal land, I suggest you to repurpose the TIMER1_COMPA interrupt (which normally is called 24 times per quarter note to tickle the internal MIDI clock) to trigger at a much faster rate (say 10kHz if you want low jitter), monitor the input pin you are interested in, and if something is detected, just go through whatever code was already there in the ISR :slight_smile:

Thanks for your answer :slight_smile:
Good idea for the pre-circuit. I think to send basic pulse waves at 24ppq. I have to consider that most soundcards are AC coupled. I could increase the resolution.
I should actually just try it and see how it works!

Try a single transistor inverter, R1 = 100k, R2 = 10k ; and detect falling edges (since it invert) - the advantage is that it has a low threshold (0.7V) - I can detect pulses well enough from an audio interface to allow firmware updates on one of my modules which has only digital inputs :slight_smile:

It works!
However the first tick is off by ~1ms.
I’m not sure of the cause (analog or avr) because I cannot really record a correct signal (I’m doing it with my sound card. For some strange reason, the recorded signal phase is reverted and the initial ramp-up is strange).
In the attached screenshot

  1. midi tick recorded by sound card. Can see that the first tick is off.
  2. recorded analog inverted signal fed to the avr input. I manually inverted the phase after recording.
  3. original signal that I send to the output of my sound card.

That’s rather badass. May I see the code to see if I have a clue about the first tick being off?

I really did not do anything special (not trying to use update the midipal clock for now, just sending plain midi for testing):

See here

EDIT:
it was analog! The input resistance of the inverter was to high. Put 10k as you suggested and it runs smoothly!
No start lag, almost no jitter (max 2 samples in my test!). I just have to integrate this nicely with the midipal code.

Further questions : how did you come up with the invertor R values?
On my todo:

  • Implement start-stop messages (I think to simply detect the presence of the clock or not),
  • Measure the actual latency (analog in, clock out).

these are the r values everybidy uses :wink:

Regarding the R values:

  • The one going in the transistor base determines the input impedance (sort of). If the resistor here is too close in the value to the output protection resistor on the module sending the gate trigger, and if you mult this trigger to other modules, bad things will happen because this will behave like a voltage divider attenuating the trigger to the point that it’ll be below the detection threshold. My rule of thumb is that it must be at least 20x larger than the one on the output. Usually 1k is used as protection resistors -> input resistor > 20k. 100k for inputs is the implicit norm in eurorack land.
  • The one on the collector determines how much current will be used by your gate, but also its reaction time. High = low current use and sluggish ; low = high current use and fast to react. Reaction time depends on the characteristics of the transistor (capacitance effect). Solution: spice it!

Thanks a lot pichenettes (quite late, I way away for a while ;-)).
It works very well, at first. I can record the x0xb0x doing 16th patterns in Live and everything is perfectly aligned on the grid!
However, after a while it accelerate and the clock is then sent at high speed.
I’m sending the clock with my soundcard, which is AC coupled.
Here the inverted signal (collector), working and non-working
Note that my soundcard input invert the phase, and would also kill any DC component.
I guess the noise is responsible here. I think I cannot saturate the transistor properly.
I tried to add a fixed bias and a decoupling capacitor to drive the transistor better. It worked somehow but startup was problematic and I don’t think it is a very good design because the soundcard capacitor seems also to have an effect on it.
Any tips on this ?

Here is a shot of the x0xb0x perfectly aligned on Live’s grid . I did not move it after recording. Just spot on!

I noticed that the output of my soundcard is really quieter than the one from macbook. From the macbook it just works. Also it would be better to send shorter pulses.
Waiting for an oscilloscope to investigate this better.

So…this is a very very interesting development…

So, I found the problem. DC pulse out of the soundcard was barely sufficient to drive the NPN. Sending correct AC pulse fixed it. Thanks to my recent acquisition, an oscilloscope (hameg rulez!), to point that out.
I still thinking about the best way to integrate it with the midipal. Thinking about making a small “sub-board” with clock input.
I’m also thinking about doing an analog clock output. Still not decided if it really makes sense.

Both makes sense imho. This way a midipal could be driven or drive an eurorack… if you amp the clocks to… hm… 3v3? that’s the maximum you get from the psu. i think it will work for triggers…

isn’t SMPTE possible than? am i wrong thinking it is an analog pulse too? :smiley:
i’d soo love that…

Indeed 3.3v would be the maximum. I think that almost every input would trigger at 3.3v though.
SMPTE would be much more difficult, if not impossible. Here I’m simply converting analog clocks to midi clocks with an 1:1 ratio.
I could divide it and still having a simple low-jitter solution. Multiplying it is a bit more difficult.
By the way, I’m using sync-unit-ac to generate the clock.
Firmware and schematics soon (as soon as I get to understand eagle!).

I’m wondering how I should protect the output. I studied some DIY projects with microcontroller+trigger and most of them don’t really protect the output or not completely.
Regarding max current sinking/sourcing, an 1k resistor would do it.
I could :

  1. use a buffer IC, inverted or not (which one?),
  2. use a BJT as buffer inverter (should I consider the breakdown voltage?),
  3. clip voltage within range with 2 diodes,
  4. just use the limiting resistor and leave the internal protection doing its job.

What would be the advantages/disadvantages?

Decided to go with 4), as cvPal do the same, which should be the good solution :wink:
I posted the code here and schematics here.
See analog_io for implementation details.

So basically it’s almost done:

  • 2 inputs, 2 outputs used as clock input, start/stop input, clock output and start/stop output.
  • Start/Stop is implemented like DIN sync (stop = logic low, start = logic high maintained),
  • A 24ppq clock on the input generates the same midi clock and 24ppq analog clock.
  • The output clock can be divided with an app, to drive a modular thing,
  • All apps interacting with midi clock work the same with the analog clock. For example bpm cntr displays the BPM of the analog clock intput and divider divide the analog clock output, etc…
  • Start/stop input is not required. Can be configured to auto start and stop on clock reception. If you have a DC coupled soundcards (most of them are), you have to use this. See here to send a correct signal with ableton. You have to kill the DC component and raise the signal level. Could also be done with a HPF set at 0Hz.
  • When using auto start, the start is sent just after the stop, like a reset. The slaved devices should start on the first clock signal. This improve really start speed of the slaved devices (but I’m not sure if all devices handle this well).

Somebody wants to test it? I plan to make a board for myself, but could then order a few if somebody is interested.

I still have one problem, I cannot make start_input to work. Here is the code. When I activate it, it makes the avr crash. Somebody minds having a look at it?
EDIT: memory was full :wink: I need to cleanup a bit.

Ableton users (or anyone unsatisfied with hardware sync in DAWS…): convince him to sell this after testing.

I hope everyone realizes how awesome this is =)

I can’t test it (not enough free time right now) but I would definitely use this.