Please, someone who know about the current "quirks" of the Tempest.

[Stoss]

Definitely only cosmetic as the room stays in sync. Thanks for your thoughts Razmo!

[John the Savage]

The display of the BPM requires a smoothed out calculation of the past time between each clock. This calculation can be fairly processor intensive depending on how you do it (using floats typically, so it takes more processor time). So a difference of .5bpm is pretty reasonable on a display

The actual response of the instrument will not be affected as the BPM is responding directly to the incoming clock, not the number it's displaying on the screen.

When the Tempest is the master, all other devices in the room show continually fluctuating BPMs.

When a Rytm (or many other devices) is inserted into the same set up in place of the Tempest, all other devices match the BPM exactly and do not fluctuate.

This tells me that the culprit is the Tempest, and not the processing capabilities of every other device in the room. As I said earlier, everything stays in sync, it's just the slaved display of BPM of all other devices that is the problem.

What is it about the Tempest that would cause this to happen?

I honestly can't believe we're still hearing the "every clock drifts, and tempo is calculated thusly" excuses.  For the last time, so help me the powers that be, the Tempest's clock runs slow.  Period.  In fact, at a tempo of 78 BPM, it lags by nearly a 10th of a BPM.  Which is why every single device that is slaved to the Tempest shows a discrepancy in tempo, just as Stoss observed above.

Folks, I've been doing this a long time.  Music is my job.  For 30 years I've been paying the bills as a musician, producer, and audio engineer.  The last time this controversy came up, my esteemed colleagues and I decided to gathered together every drum machine and groovebox we owned: everything from a lowly Alesis SR-18 and a Korg Electribe 2, to an entire array of high-end music production stations covering every Elektron box ever made, a few Roland machines, and several models of MPC including the new MPC Live... Nearly two dozen boxes in total.  We even threw a few iPad apps in the mix just for fun.  First, we ran them all as slaves to the Tempest, and predictably, they all showed the same discrepancy in BPM.  Then, just for shit's and giggles, we ran them all unsynced.  We pressed play on each box, by ear, with no MIDI cables hooked up whatsoever, taking care to make sure they all started in sync, old school...

The result was undeniable: The Tempest fell out of sync within the first 8 bars.  I kid you not.  And I mean jarringly out of sync!  No matter how many times we restarted it, the results were the same.  Meanwhile, the other boxes stayed notably and useably in sync with each other for miles by comparison.  The worst of them made it 10 minutes or so before the trough got too wide, whereas we were still jamming with the better contenders nearly 40 minutes later, having all but forgotten we weren't actually hard synced.

Take from that what you will.  But that's the truth.  Go ahead, if you've got a few different machines kicking around, try it for yourself.  You'll see.

Cheers!

[Razmo]

But the funny thing is, that this then has to be a bug in the way Sequential calculate their device's BPM... because as I wrote; REV2 and TEMPEST both show the same BPM no matter which is master! ... so this hints that the REV2 has exactly the same "problem" as the TEMPEST... the BPM it shows is not correct... it is off...

But again... if you are sync'ed up to a clock no matter if you are the master or slave, you listen to the clock, and react on it when it comes in... so there are no sync problems at all with TEMPEST... it follows if it gets a clock signal, and other devices follow the TEMPEST if they get clock signals from it... the only difference is that when TEMPEST is master, the real BPM should be read on the attached slaves, because they will show the correct BPM... if that even matters really... who the hell would be able to hear so little a deviance anyway!? ... I'm certain that if your dance track is 140 or 139.9 the people will eventualy dance nonetheless! 

But if you wanted to run TEMPEST non-synced at the same BPM in other devices, then you'd surely run into problems...

[John the Savage]

Where it does matter, Razmo, is when the Tempest is clocking a sampler, triggering beat loops and longer tempo-based audio samples.  In fact, the first time I ever noticed this issue, I was using the Tempest to clock an SP-404SX, and suddenly all my immaculately trimmed beat samples were ending a 10th of a second prematurely, leaving a gap in the audio.

Never mind DJ situations wherein you need to jam unsynced, or those times when you've recorded a live jam to a stand-alone track recorder, only to then drop it into your DAW to find that the Tempest has pushed everything off the grid, etc.  The bottom line is, there are many situations in which this is not a trivial matter; and worse yet, it betrays an inherent flaw in what is supposed to be a premium product.

It cannot be overstated, as far as I'm concerned, that every single device we tested performed better in this respect, by a country mile; including all of our bottom-of-the-barrel, budget grooveboxes.  I'm currently using my $200.xx Alesis SR-18 to clock my $2000.xx Tempest in order to keep it in line.  Not acceptable.

Cheers!

[Razmo]

Ahh... Yes of course... Triggered loop samples would not work... Did not think of that...

I do think that Sequential should look their BPM code thru and get this fixed, especially if this bug is creeping in to new products.

[Stoss]

I honestly can't believe we're still hearing the "every clock drifts, and tempo is calculated thusly" excuses.  For the last time, so help me the powers that be, the Tempest's clock runs slow.  Period.  In fact, at a tempo of 78 BPM, it lags by nearly a 10th of a BPM.  Which is why every single device that is slaved to the Tempest shows a discrepancy in tempo, just as Stoss observed above.

Folks, I've been doing this a long time.  Music is my job.  For 30 years I've been paying the bills as a musician, producer, and audio engineer.  The last time this controversy came up, my esteemed colleagues and I decided to gathered together every drum machine and groovebox we owned: everything from a lowly Alesis SR-18 and a Korg Electribe 2, to an entire array of high-end music production stations covering every Elektron box ever made, a few Roland machines, and several models of MPC including the new MPC Live... Nearly two dozen boxes in total.  We even threw a few iPad apps in the mix just for fun.  First, we ran them all as slaves to the Tempest, and predictably, they all showed the same discrepancy in BPM.  Then, just for shit's and giggles, we ran them all unsynced.  We pressed play on each box, by ear, with no MIDI cables hooked up whatsoever, taking care to make sure they all started in sync, old school...

The result was undeniable: The Tempest fell out of sync within the first 8 bars.  I kid you not.  And I mean jarringly out of sync!  No matter how many times we restarted it, the results were the same.  Meanwhile, the other boxes stayed notably and useably in sync with each other for miles by comparison.  The worst of them made it 10 minutes or so before the trough got too wide, whereas we were still jamming with the better contenders nearly 40 minutes later, having all but forgotten we weren't actually hard synced.

Take from that what you will.  But that's the truth.  Go ahead, if you've got a few different machines kicking around, try it for yourself.  You'll see.

Cheers!

Thanks for the sanity check. 

[John the Savage]

Sanity Checker: I think that's been my official title around here for years (smirk)...

If only it were a paid position, I'd be a rich man by now (wink).

Cheers!

[KoSv]

this is not trivial and lies in the nature of MIDI SYNC implementation itself! so every (and I mean every!) machine is drifting when is acting as a slave.

[Blueskytech]

Using an E-RM multiclock I can sync all my outboard gear with the tempest as a slave. That being said no matter how much I try I can never get the Tempest to not have some drift after recording 10 bars. It’s certainly much better then using the Tempest as a master but I’m curious if others still have drift in slave mode.

Additionally I confirmed Razmo’s behavior that when the Rev2 is only connected to the Tempest they do not have a fluctuating BPM like when I used to try and slave my DAW to the Tempest.

Lastly with 100 ms delay positive or negative I can never get the Tempest to start after the first beat in my DAW, it syncs reasonably by the 2nd bar. If anyone has tricks on how to make the Trmpest sync on the first down beat of recording I would appreciate it.

Either way the tempest is the most fun I have ever had designing sounds but I would love to learn any additional tricks for syncing the device to your DAW of choice when recording.

[Razmo]

Not that I have the knowledge of MIDI clocking in programing, but I am just wondering about something...

MIDI clock pulses are 24 PPQ I have read... And if a device ticks it's sequencer emediately as it receive a clock pulse, and do not miss any pulses, then the slave really should not drift... It would be perfectly slaved to the clock (unless there are problems with jitter coming from the master or the slave is sloppy in reacting to the clock).

But Tempest is 96 PPQ... So how does it obtain clock pulses in between the MIDI clocks coming in from the master at 24 PPQ? Tempest's clock engine must be interpolating something to get those three more clock pulses in between, and could this maybe be the cause of the clocking problem when Tempest is the slave?

[muleskinner]

But Tempest is 96 PPQ... So how does it obtain clock pulses in between the MIDI clocks coming in from the master at 24 PPQ? Tempest's clock engine must be interpolating something to get those three more clock pulses in between, and could this maybe be the cause of the clocking problem when Tempest is the slave?

Presumably it will make a best guess based on the timing of the last two pulses. It should be back in sync at the next pulse anyway so I can't see how that would cause drift.

FWIW I have not noticed any drift when using the Tempest as a slave. It seems slightly laggier than my other devices, i.e. if synced recording to DAW sounds on the beat from the Tempest are very slightly behind everything else, but it's not really enough to be an audible problem in the context I tend to use it and if I'm being really finicky I just line everything up 'by hand'.

[KoSv]

Lastly with 100 ms delay positive or negative I can never get the Tempest to start after the first beat in my DAW, it syncs reasonably by the 2nd bar. If anyone has tricks on how to make the Trmpest sync on the first down beat of recording I would appreciate it.

no. the slave machine needs time to figure out what the bpm is. so it can trigger its internal sequencer that has mostly an another resolution than 24PPQ.
I don't know how this is implemented in the tempest, but it seems to wait a bit, until it has enough data to calculate the proper tempo.
this is normal!
there are another and better solutions, but I suspect this wasn't a priority at the time they designed the tempest. I think they wanted more a kind of a standalone instrument..

[KoSv]

Not that I have the knowledge of MIDI clocking in programing, but I am just wondering about something...

MIDI clock pulses are 24 PPQ I have read... And if a device ticks it's sequencer emediately as it receive a clock pulse, and do not miss any pulses, then the slave really should not drift... It would be perfectly slaved to the clock (unless there are problems with jitter coming from the master or the slave is sloppy in reacting to the clock).

But Tempest is 96 PPQ... So how does it obtain clock pulses in between the MIDI clocks coming in from the master at 24 PPQ? Tempest's clock engine must be interpolating something to get those three more clock pulses in between, and could this maybe be the cause of the clocking problem when Tempest is the slave?

If you really have a background in MIDI Sequencer programming you would know that this is very common issue and how to deal with!

I was hoping that MIDI 2.0 would solve the 24PPQ problem as of today we have much wider bandwidth especially with usb 3.0..

EDIT:

But Tempest is 96 PPQ... So how does it obtain clock pulses in between the MIDI clocks coming in from the master at 24 PPQ? Tempest's clock engine must be interpolating something to get those three more clock pulses in between, and could this maybe be the cause of the clocking problem when Tempest is the slave?

just for clarification: the slave machine doesn't "obtain" the pulses in between. it generate those constantly by calculating and guessing and waiting for new tick (for a GHz processor it is takes an eternity). and that is the problem with ALL machines acting as a slave.
every hardware clock drifts, due to the fact of thermal issues, electrical interference, etc.
the master clock drifts and the slave clock drifts.. and they both are trying to sync at its best at 24PPQ... in the 80‘s this was really ok. in 2019 - I don't know..
so having an atomic clock in your synth would solve this issue (well not entirely)

[Razmo]

Not that I have the knowledge of MIDI clocking in programing, but I am just wondering about something...

MIDI clock pulses are 24 PPQ I have read... And if a device ticks it's sequencer emediately as it receive a clock pulse, and do not miss any pulses, then the slave really should not drift... It would be perfectly slaved to the clock (unless there are problems with jitter coming from the master or the slave is sloppy in reacting to the clock).

But Tempest is 96 PPQ... So how does it obtain clock pulses in between the MIDI clocks coming in from the master at 24 PPQ? Tempest's clock engine must be interpolating something to get those three more clock pulses in between, and could this maybe be the cause of the clocking problem when Tempest is the slave?

If you really have a background in MIDI Sequencer programming you would know that this is very common issue and how to deal with!

I was hoping that MIDI 2.0 would solve the 24PPQ problem as of today we have much wider bandwidth especially with usb 3.0..

EDIT:

But Tempest is 96 PPQ... So how does it obtain clock pulses in between the MIDI clocks coming in from the master at 24 PPQ? Tempest's clock engine must be interpolating something to get those three more clock pulses in between, and could this maybe be the cause of the clocking problem when Tempest is the slave?

just for clarification: the slave machine doesn't "obtain" the pulses in between. it generate those constantly by calculating and guessing and waiting for new tick (for a GHz processor it is takes an eternity). and that is the problem with ALL machines acting as a slave.
every hardware clock drifts, due to the fact of thermal issues, electrical interference, etc.
the master clock drifts and the slave clock drifts.. and they both are trying to sync at its best at 24PPQ... in the 80‘s this was really ok. in 2019 - I don't know..
so having an atomic clock in your synth would solve this issue (well not entirely)

As I wrote, I do NOT have the knowledge of MIDI clock programing  ... That is why i wondered because I do know that those  extra clock pulses must be obtained by the slave doing some sort of estimating them.

I never really had an interrest ind MIDI clock because I always found it unstable... Not only with Tempest but other devices as well... I also will not use Tempest with clock... I'll use it stand alone which is probably what it is best suited for... Maybe use it remotely via noteon messages as well...

[deep_transmissions]

I just got a Tempest. Love the sound, it's a great machine, but the delay in midi means I can't record unless adjusting the MIDI sync delay in ABleton. Thisis a bummer because devices I have with internal sequencers I prefer to clock to my Octatrack. Its WAY off, like 29 ms off. Tanzbar, Alpha Base, 101, Juno, Octatrack, Blofeld, MIcrowave, Syncussion I built, TB-01 from Erica, all of them dead on. This is definitely a flaw of the Tempest for sure. Unfortunate because it really is a huge gap. It's noticeably audible.

It just floated a bit and then recentered itself at -9 ms. Still off enough that recording can't be done with out latency correction. Bummer, but it's still wonderful to create on, and I guess I'll learn to record warts and all. It sounds fantastic.