The Official Sequential/Oberheim Forum
SEQUENTIAL/DSI => Tempest => Topic started by: Razmo on November 25, 2018, 08:51:25 AM
-
I know it's probably written all over this forums recent topics, but I really do not have much interrest in reading thru this whole forum for this, so please, if anyone can tell me about the current "bugs", "Quirks" etc. since of the latest (and final) Tempest OS.
Reason is, that some things have changed since I sold my Tempest for the second time some time ago, but since my workflow has changed since then, and I'm using my devices rather differently, the way I would be using a Tempest would be a bit different than the last times I had it.
Back then most of my focus was on MIDI specs and other stuff... i know these still exist, but it does not really matter now, as I intend on using the Tempest stand alone (only using it with my computer for editing sounds)... I'll simply be filling the Tempest up with my own kits and sounds, and then use it without MIDI (recording the audio outputs).
But I've been reading a bit about bad MIDI timings now... one thing I'd want to do with the Tempest is playing back simple sequences, using Beats mode to launch different pre-recorded sequences live.... alas, I'm not going to be changing a lot of parameters while playing back these sequences, I'll only be tweaking the Beat Wide parameters live to induce some dynamics into the playback.
I will also need to sync the Tempest (which is what worries me a bit regarding those other posts I've read), but in my case I need to sync it as a slave because I'll be connecting it to my Prophet REV2's MIDI DIN output... I want to be able to sync the Tempest this way so that I can have a bassline/arp or other sound running in tandem with the Tempest's groove... and then manipulate both's sounds live when recording them into my DAW.
I do not need any of the Song Chaining features from the Tempest... just to sync it to REV2 via MIDI DIN, and then tweak Beat Wide parameters while also changing beats live.
Anything I should watch out for in this case?
-
Timing is fine when running as a slave.
Scan the recent posts on the bugs thread - there's not many to speak of in the latest fw.
Welcome back (again)!
-
I’ve never had an issue using the Tempest as the master clock. It almost always is for me.
-
I use the Tempest as a master clock in a studio with two other musicians. Lots of high end gear and it all stays in sync. The only weird thing is that the Tempest will show a tempo of 75 BPM while the rest of the synced gear displays a fluctuating tempo between 74.9 and 75. Again... even with this, they are all in perfect sync and never drift from each other. It’s just a weird anomaly that we live with. When I swap out the Rytm for the Tempest in the exact same setup... all tempos are matched exactly, so it has to be discrepancy between what Tempest intends as the tempo and what it is actually producing. I can only assume this is “expected behavior”. ;)
The thing is... the Rytm can’t replace that Tempest. The Tempest is so good at participating in an improvisational beat making role... both in how well it records the beats I have in my head, but also in my ability to instantly change any of the 32 sounds while I’m recording them... and even after they are recorded. Those per sound FX sliders and the ability to record them while performing is so much more powerful (for me personally) than P-Locks in the Rytm. DSI should really have included them when saving individual sounds as they are a key part of sound design on an instrument like this.
Anyway... the “quirks” are still there. I don’t doubt you’ll run into something... you’ll just have to live with it. Unfortunately, firmware quirks seem to be a consistent theme through many of the threads on this forum.
-
Well... I'll live with it... unfortunately I just bricked my just arrived Tempest when trying to update to the latest OS... it took all the data fine via USB and then started to write the OS, but half a second after that, the FX1 LEDs went all the way down, and they just stayed there for about 15-30 minutes (I don't recall exactly how long I waited)... so i had to turn it off in the end, resulting in a bricked Tempst ... and now I'm almost certain that this device has no bootloader code... I've written support, but if I'm right, I'll have to send the darn thing all the way to the US and have it "revived from the dead" :/
Still waiting for support to answer on this... I really hope there is some sort of bootloader via MIDI DIN that i can access by a specific button combination on power-on, but I'm beginning to doubt it...
-
unfortunately I just bricked my just arrived Tempest when trying to update to the latest OS...
As far as I remember you have a PIC programmer. If its the same interface that is used to reprogram the Tempest board then maybe it can be solved by them sending you the file(s) and you do the hard work yourself. Also, maybe its only the main board that have to be sent over? Ask support!
-
unfortunately I just bricked my just arrived Tempest when trying to update to the latest OS...
As far as I remember you have a PIC programmer. If its the same interface that is used to reprogram the Tempest board then maybe it can be solved by them sending you the file(s) and you do the hard work yourself. Also, maybe its only the main board that have to be sent over? Ask support!
I have contacted support, and it's being taken care off... I deposit some money, they send me a replacement board, I then send the bricked one to them, and they refund the deposit minus the service fee... all at a really reasonable price... I'm just happy I get the new board first, so i can get my Tempest up and running... that saves me half the time really. Sequential support has always been top notch in my opinion... i know I have some remorse on some of their update policies from the past, but their support is splendid... I'm not ashamed to say that :) ... I actually hope to have them send a Tempest Knob kit with the new board as well, maybe saving a bit of freight cost now that they're sending me the board anyway... really would like the knobs to match the ones on my REV2 if possible :)
With all that said, I'm amazed that Tempest do not have any kind of bootloader that could have avoided this situation. I know it would probably have worked only with the MIDI DIN since USB was not available on Tempest until OS 1.2, but it would have been nice if it was possible to reflash the OS via a bootloader.
I asked for the replacement board to be installed with the absolutely latest OS updates so I do not have to do this myself... after this experience, I'd really hate to have to update Tempest ever again... so I'm kind of glad that the OS development has stopped... that way it will never be necessary to update again.
For more than 25 years I've never had ONE update of an OS fail on me... not even a single one... this is the first time it has ever happened... so please... anyone trying to update your Tempest, please make sure you know exactly what you're doing so this does not happen to you... but anyway it should not have happened... i do not know why it stopped in the writing of the flash... had it been a bad SysEx dump, it should have told me that before even trying to burn the flash... so I suppose that the dump was successful... I dumped the Voice OS first via USB... no problem... then I dumped the Main OS right after, in exactly the same way... all SysEx went smoothly to the Tempest, and it started to write to flash... then froze... I cannot see how i should have been able to be more careful... there was nothing I could have done differently.
And about the PIC programmer... naaah... the one I have is a very old one... maybe it would have worked with the Evolvers, since i recall those chips being the same models as I used myself for my PIC projects back then... but DSI surely switched to newer unsupported models that my PIC burner would not work with... that's one thing... another is that I don't think Sequential would ever give those files out... also i do not want to be messing with that myself... I could accidentally fry something if not connected correctly... Tempest is not exactly a cheap machine, even though i got it at almost half the price of a new one. :)
-
I have contacted support, and it's being taken care off... I deposit some money, they send me a replacement board, I then send the bricked one to them, and they refund the deposit minus the service fee... all at a really reasonable price...
Good old Board Swap Dance (TM). They hardware support are very good. Look forward to hear your new sonic experiments with Tempest.
As for what caused this lockup one wonders if it could be hardware problem or perhaps a timing issue.
-
I have contacted support, and it's being taken care off... I deposit some money, they send me a replacement board, I then send the bricked one to them, and they refund the deposit minus the service fee... all at a really reasonable price...
Good old Board Swap Dance (TM). They hardware support are very good. Look forward to hear your new sonic experiments with Tempest.
As for what caused this lockup one wonders if it could be hardware problem or perhaps a timing issue.
Yup... tried it with the Prophet 12 module earlier so i know the drill... about the lockup... I really have no clue, so could be anything i guess.
Even though it pisses me off, that it's dead and I have to wait some time it's actually good because i still have 32 REV2 sounds to do before the end of december, so this event has insured I do not get distracted :) ... i certainly look forward to creating complete fantasy percussion kits for the Tempest now, and it will be good to take a long break from designing sounds on the REV2... 96 sounds is a lot for me (I've done more sounds in the last 6 months than I've been doing sounds the 25 years before that). and i feel I've been in most of the REV2's engine corners now and feeling the urge to test my sound design on a new engine... also I've purposefully not created any percussion sounds for the REV2, simply because i have no intention of using the REV2 for percussion... that is exactly what I wanted the Tempest for, along with it's live sequencing a tweakability. It'll be fun to see what weird fantasy kits i can come up with for all kind of ambient genres.
-
Challenge: design percussion sounds on Rev2 that cannot be done on Tempest.
Creative uses of modulation sequencer could be one such thing. Shape modulation could be another such thing.
-
I've now had the time to connect my Tempest MIDI DIN output to my REV2 MIDI DIN input... i wanted to see how the syncing of the REV2 would turn out if Tempest is the master... I've read a lot about Tempest having to be the slave, or things start to screw up, and also about how other devices have their BPM showing a slight difference to what is on the Tempest...
I do not get this... I get absolutely no deviations... when Tempest is at 120BPM then my REV2 is exactly 120BPM as well, and showing it on its display... even changing programs on the fly on REV2 quickly readjust the BPM.. .it takes less than a second for it to adjust correctly...
Everything is in time, rock solid and without any problems... the REV2 sequencer start tight and on the spot when it receive start/stop messages, and also gated sequences and arpeggiators are tight...
So why others are experiencing problems with Tempest being the master is beyond me... here everything works fine :)
-
So why others are experiencing problems with Tempest being the master is beyond me... here everything works fine :)
Damn, really? I see variations of .1 less around 75BPM and around .5 less around 225BPM. That’s showing up on a Roland SPD-SX, Octatrack, Digitakt, Rytm, Pyramid. I mean I see it everywhere with the resolution to show it. Have you tried it with anything other than the Rev2?
-
So why others are experiencing problems with Tempest being the master is beyond me... here everything works fine :)
Damn, really? I see variations of .1 less around 75BPM and around .5 less around 225BPM. That’s showing up on a Roland SPD-SX, Octatrack, Digitakt, Rytm, Pyramid. I mean I see it everywhere with the resolution to show it. Have you tried it with anything other than the Rev2?
No, because I only have Tempest and REV2 at the moment :)
I do not doubt other users experiences with this, i just wanted to inform you that i do not see any deviations... I've seen deviations before in the past with other gear, trying to sync to my DAW, where I'd see a slight BPM deviance on the calculated value, even if they synced up nicely... i think it may simply be that the algorithm for calculating the BPM must be different in DSI hardware maybe... it seems that two DSI devices sync fine, and calculate to the same value... maybe it' the DSI tempo that is just a bit off so that other hardware devices show you the real BPM, but DSI devices do not?
I do not know how to actually measure the BPM in that small values for any errors, so I'm probably not of much help with that.
I may have to add, that I'm of course on the absolute latest OS if that may matter at all.
-
^ thanks Razmo. Just want to make sure it wasn’t fixed somehow and I wasn’t aware... or had some older hardware. Good to see you back on the Tempest with a new approach to it’s shortcomings. BTW... I totally agree with your perspective on the samples. I’m fine with a fixed bank of sounds. Those buzzy single cycles are a bit of a bummer. More thought into including wildly interesting samples for the beginning point of sound design would have been great. All that being said... it’s a wonderful machine. :)
-
I don't have a tempest, but what you're seeing in terms of slight random timing is actually to do with the way MIDI clock is handled and not (necessarily) the Tempest in particular.
MIDI is an asynchronous protocol - packets are sent whenever the host has data to send and the timing of those packets is literal - as in the nanosecond I woggle the wire to put the bit on it, the bit is there, and when the full packet has been sent, that's the timing of the message.
MIDI clock is sent very simply, a clock pulse packet is sent down the MIDI wire, and 1/24th of the BPM later, another, and another, etc. So if the BPM is 120, 2,880 packets will be sent per minute, all more-or-less evenly spaced in time. Most hosts display a non-smoothed calculated from the (local, perceived) time of the last two packets, divided by 24 and scaled to bpm, and update this value every X milliseconds from whatever the last two packets' timing was.
This works perfectly fine if there is no other MIDI data on the wire.
But as soon as you have even a single other piece of MIDI data to send (say a note event - which is always two packets, the on and the off, or a cc, or even the start/stop commands) those might be sent "on" the beat or on one of the common subdivisions of the beat (8th notes, 16ths, even triplets). All of these are at one of the exact moments one of the 24 clock pulses will also need to be sent. In some cases, depending on the real-world timing of these events, processor queueing, and other vagaries, the note/cc/other MIDI event will be sent first, in or across the time boundary where the clock pulse should be, and the clock pulse must be moved to immediately follow the MIDI event. This is only the case if the SENDING unit is also creating the additional traffic or if the traffic is being merged with a clock signal that is generated independently, AND the merger or the sending unit do not have the ability to look ahead and determine if the clock pulse should be prioritized. Most machines operate on a First-In-First-Out pattern so if the note data gets put into the sending buffer before the clock pulse, the note data will shove the clock pulse the few milliseconds it takes to send the other packet first.
As a result, it's entirely possible to see the clock fluctuating by small tenths of a beat if there is any other midi traffic (especially perfectly timed sequence data such as drum beats) on the same cable. Since the Analog RYTM cannot and does not sequence other gear, this is not possible, so its timing will always look 'cleaner' than a drum machine (such as the Tempest) which can sequence other gear and is thus a bit more chatty.
-
I don't have a tempest, but what you're seeing in terms of slight random timing is actually to do with the way MIDI clock is handled and not (necessarily) the Tempest in particular.
MIDI is an asynchronous protocol - packets are sent whenever the host has data to send and the timing of those packets is literal - as in the nanosecond I woggle the wire to put the bit on it, the bit is there, and when the full packet has been sent, that's the timing of the message.
MIDI clock is sent very simply, a clock pulse packet is sent down the MIDI wire, and 1/24th of the BPM later, another, and another, etc. So if the BPM is 120, 2,880 packets will be sent per minute, all more-or-less evenly spaced in time. Most hosts display a non-smoothed calculated from the (local, perceived) time of the last two packets, divided by 24 and scaled to bpm, and update this value every X milliseconds from whatever the last two packets' timing was.
This works perfectly fine if there is no other MIDI data on the wire.
But as soon as you have even a single other piece of MIDI data to send (say a note event - which is always two packets, the on and the off, or a cc, or even the start/stop commands) those might be sent "on" the beat or on one of the common subdivisions of the beat (8th notes, 16ths, even triplets). All of these are at one of the exact moments one of the 24 clock pulses will also need to be sent. In some cases, depending on the real-world timing of these events, processor queueing, and other vagaries, the note/cc/other MIDI event will be sent first, in or across the time boundary where the clock pulse should be, and the clock pulse must be moved to immediately follow the MIDI event. This is only the case if the SENDING unit is also creating the additional traffic or if the traffic is being merged with a clock signal that is generated independently, AND the merger or the sending unit do not have the ability to look ahead and determine if the clock pulse should be prioritized. Most machines operate on a First-In-First-Out pattern so if the note data gets put into the sending buffer before the clock pulse, the note data will shove the clock pulse the few milliseconds it takes to send the other packet first.
As a result, it's entirely possible to see the clock fluctuating by small tenths of a beat if there is any other midi traffic (especially perfectly timed sequence data such as drum beats) on the same cable. Since the Analog RYTM cannot and does not sequence other gear, this is not possible, so its timing will always look 'cleaner' than a drum machine (such as the Tempest) which can sequence other gear and is thus a bit more chatty.
So, if I've got the Tempest connected directly to another device and am only sending out the clock data without any other sequence data, are you saying that the clock should appear stable on the other device?
-
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.
I don't have a tempest, but what you're seeing in terms of slight random timing is actually to do with the way MIDI clock is handled and not (necessarily) the Tempest in particular.
MIDI is an asynchronous protocol - packets are sent whenever the host has data to send and the timing of those packets is literal - as in the nanosecond I woggle the wire to put the bit on it, the bit is there, and when the full packet has been sent, that's the timing of the message.
MIDI clock is sent very simply, a clock pulse packet is sent down the MIDI wire, and 1/24th of the BPM later, another, and another, etc. So if the BPM is 120, 2,880 packets will be sent per minute, all more-or-less evenly spaced in time. Most hosts display a non-smoothed calculated from the (local, perceived) time of the last two packets, divided by 24 and scaled to bpm, and update this value every X milliseconds from whatever the last two packets' timing was.
This works perfectly fine if there is no other MIDI data on the wire.
But as soon as you have even a single other piece of MIDI data to send (say a note event - which is always two packets, the on and the off, or a cc, or even the start/stop commands) those might be sent "on" the beat or on one of the common subdivisions of the beat (8th notes, 16ths, even triplets). All of these are at one of the exact moments one of the 24 clock pulses will also need to be sent. In some cases, depending on the real-world timing of these events, processor queueing, and other vagaries, the note/cc/other MIDI event will be sent first, in or across the time boundary where the clock pulse should be, and the clock pulse must be moved to immediately follow the MIDI event. This is only the case if the SENDING unit is also creating the additional traffic or if the traffic is being merged with a clock signal that is generated independently, AND the merger or the sending unit do not have the ability to look ahead and determine if the clock pulse should be prioritized. Most machines operate on a First-In-First-Out pattern so if the note data gets put into the sending buffer before the clock pulse, the note data will shove the clock pulse the few milliseconds it takes to send the other packet first.
As a result, it's entirely possible to see the clock fluctuating by small tenths of a beat if there is any other midi traffic (especially perfectly timed sequence data such as drum beats) on the same cable. Since the Analog RYTM cannot and does not sequence other gear, this is not possible, so its timing will always look 'cleaner' than a drum machine (such as the Tempest) which can sequence other gear and is thus a bit more chatty.
So, if I've got the Tempest connected directly to another device and am only sending out the clock data without any other sequence data, are you saying that the clock should appear stable on the other device?
-
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?
-
If the tempest is master, and all connected devices show a deviation, but not when another device is set in as master, then there can be no other explanation than tempest is either sloppy in sending the MIDI clock data, or the calculated BPM of tempest is slightly off... A MIDI clock is a MIDI clock, no matter what is sending it, and the slaves process it equally no matter what the sending device is... So if both master devices send ONLY clock messages, and the receiving devices show different bpm depending on what is the master, then those two master devices are sending the clock data slightly different... That is a simple fact.
-
I can add one thing... When I have Tempest as master, and rev2 as slave... Both devices show the exact same bpm... If they switch roles, then again they match... But if I put a PEAK into the equation, then peak show a very slight deviation, but this happens both when REV2 or Tempest is master... So something points to the fact, that Sequential devices show the same bpm when connected, but not with other brands of devices... There must be something in the algorithm of Sequential devices for calculating their BPM values that differ from the way other brands do this... I suspect it is really just a cosmetic deviance because of the different algorithms because any slave will eventually react promtly to an incoming clock message, not the calculated bpm value... So really... If all is in sync and tight, I would simply ignore that deviant value... You wont hear that value deviance in the end product anyway...
-
Definitely only cosmetic as the room stays in sync. Thanks for your thoughts Razmo!
-
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!
-
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...
-
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!
-
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.
-
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. :)
-
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!
-
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.
-
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.
-
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?
-
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'.
-
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..
-
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) ;)
-
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...
-
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.