MIDI timing question

UDO Audio Gear Super Gemini
1

Has anyone else had issues with MIDI timing being sloppy/delayed? I’ve got my SG set up to receive MIDI clock over DIN from my Roland R8 so the arp and seq sync to it. I’ve tried all the different MIDI option including disabling CC/NRPN and Prog Change messages and it starts and stops fine when I start and stop the drum machine but the sequence or arp I select isn’t on the beat, it’s delayed by enough for it to be noticeable (and not really usable). I tried a different drum machine (TR8) but the problem persists.

I don’t know if it’s related but the actual arp when triggered from the keybed doesn’t start as soon as a key is depressed either, it seems to ‘wait’ as if it’s clock isnt reset by the key press. Is this normal behaviour?

Am I missing something here? I’m running v1.25 at the moment and was holding back on going to v1.26 until some if the bugs are ironed out

2

A traditional arp shouldn’t be key-synced but beat-synced so I wouldn’t expect it to start on a keypress as that defeats a lot of tricks of classic arpeggiators. It should wait for the next beat so that everything lines up without you having to play in time. Maybe this is what’s happening?

1 Like
3

Well that happens if I key down but it’s still ‘behind’ the beat. If I leave hold turned on and start the drum machine the arp or sequence will start but again is behind. There’s even reference in the manual to doing this saying the sequence will lock to the midi clock but it’s not synchronised. I did see another post reporting the same issue but it was some time ago and there wasn’t a reply to say whether the poster had resolved the issue. I hope it gets addressed soon if it’s a bug as it’s unusable in that situation. I’ve tried a couple of drum machines and it’s the same with both

It’s as if there is some latency between the SG receiving midi clock and triggering the seq or arp starting. I’ve got the SG set to external clock and I’d expect it lock to that which it does but with a lag

I just wanted to ask the question here before I raise a ticket with UDO in case I’d missed something

Edit. I’ve just plugged it back in and set up the drum machine and narrowed it down a bit…

If I start the drum machine then turn on the arp it doesn’t snap to the incoming clock. It’s getting the clock and is in time but isn’t in sync. If I stop the drum machine and restart with the arp engaged it’s bang on in time. However a few times when it’s been in sync and I’ve changed the clock division of the arp it’s lost its sync again. It doesn’t happen every time and doesn’t seem related to when I actually turn the switch (if I do it ‘off the beat’ I can hear the SG play the first note off then snap back in time). Stopping the drum machine and restarting it seems to snap it back again so it must be using the midi start stop to sync the arp. But there is still the issue when changing the clock division

Either way it seems to be fine as long as I engage the arp before it gets its start stop message and I leave the clock division alone!

1 Like
4

Ah, apologies then, hope my reply didn’t confuse things. I haven’t progressed much beyond a Jupiter 6 for my arpeggiation as so many modern synths feel sloppy in comparison.

1 Like
5

Not at all, thanks for your input!

Love my JP4 arp… it’s nice and easy to play nicely with anything with an old fashioned clock output!

1 Like
6

I was having a lot of timing issues trying to sync the Super Gemini to either my EP-133 or my Tempest. I finally purchased a Sim’n Tonic Nome II as my master clock and have the SG and EP-133 on one DIN, and the Tempest on the other.

This has tightened things up considerably, and as long as I press start on the Nome II sometime before the SG is engaged everything seems tightly synced. If I don’t press start beforehand, then the clock the right tempo, but the SG will be off beat.

3 Likes
7

TL;DR: Seems to be a BUG :cockroach:

…

I’ve only had the SG briefly so not exactly experienced with it (so there could easily be something I’m missing) but I’ve been through the entire manual, and I’ve just done about 2hrs of testing this and there does seem to be a bug with the Arp timing, from what I can see.

My SG is on the latest firmware v1.26
I have it clocked to an Elektron Octatrack (over 5-PIN MIDI, no USB cable connected).

The Octatrack has been absolutely solid as my master clock for all my gear for years. Never had a single timing issue.
I had a drum loop going on the Octa so it was very obvious when the Arps weren’t in time. I haven’t tried another clock source yet but it’s very unlikely the Octatrack has anything to do with the issue.

…

SYNC SETTINGS (SHIFT > SYNC [EXT CLK]):

Button 1 - Clock Transmit is OFF (flashing #1 LED)
Button 2 - Clock Receive is ON (solid #2 LED)
Button 4 - MIDI Stop Message Receive is OFF (flashing #4 LED)

…

The Tempo LED blinks in time with the Octatrack as it should. Changing the tempo on the Octatrack changes the tempo on the SG, and the arps speed up and slow down. They are definitely synced ok.

  • I did Shift+INIT PATCH on both layers
  • I cleared the Mod Assign on both just in case.
  • I manually set all faders, knobs switches to the same (I manually moved everything away and then back to the position I wanted - basically everything off, nothing free running, filters fully open without res, no LFOs, no binaural, no pw/drift/spread/phase, no portamento, no dynamics, no effects etc etc.
  • Arp set to 1/16 on both
  • SYNC (button in the Arp section) ON for both layers

…

Going between SINGLE and DUAL modes, (and in each mode, testing between LAYERS), the arp timing is completely inconsistent, mostly not starting immediately when a key or chord is pressed.

I am pressing the keys in time with the beat.

I thought I was getting somewhere for a few minutes - it seemed like if you change from SINGLE to DUAL mode and disable and reenable each layers’ Arp before pressing keys, they seemed to sync but this proved inconsistent. Both arps were kicking in at different, seemingly random times when keys were pressed.

It also seemed at times that, when in SINGLE mode, if you change layer, but wait for a few seconds before pressing a key, the two arps would be in time with each other, starting at the correct time, but it turned out that when the layer is changed once or twice, it loses timing again. Most of the time the LOWER layer was ok and in time with the beat, while the UPPER layer was way out of sync and not starting for some milleseconds - up to about half a second.

No apparent consistency with the Arp start. I didn’t take video but it’s quite easy to reproduce. Same after power cycle. Same with any other settings (switch/button positions) I tried. Stopping and starting and power cycling the Octatrack made no difference to the issue. Powering on one or the other first made no difference.

Same results trying DDS 1 on both layers (DDS2 turned down), versus DDS2 on both layers (DDS1 turned down)

Don’t know if I’ve forgotten anything there.
I plan to raise a ticket with UDO Support myself about it - if it is a bug, they may well be aware of it already and working on a fix, I’ve no idea but it definitely seems to be a bug.

2 Likes
8

Just an Update - UDO Support were super fast on their response and investigation and said they were able to recreate the issue and added it to their list! :clap:

They said it only seems to affect live playing, i.e. when you play along to a drum machine or external sequencer in realtime. When tested with recorded clips in Ableton, for example, the arpeggios would always be in sync.

They’re going to investigate what could be causing the delayed arpeggio notes :metal:

2 Likes
9

Hey nice find there, probably what I’ve been experiencing as well.

2 Likes
10

FWIW I have also been getting delayed arps on my S6 Desktop when being externally clocked.

Starting/stopping a few times can bring them back in order but they are still liable to have the delayed start on note ons come back in the normal course of composition.

11

I’ve often thought a good way of doing it would be some sort of amalgamation of strict quantisation with key sync. Basically the first note trigger should be immediate unless it falls within a small window before a step in the arp’s timebase in which case it is hard quantised to that successive step. Thereafter all steps are hard quantised. In a live system this would only work in a ‘feed forward’ fashion as you can’t quantise a live note backwards in time as far as I’m aware :laughing:

The system I describe would allow push/pull playing with single initial notes but then follow the timebase when held. Of course, the holy grail is groove quantised arpeggiation…

1 Like