The Official Sequential/DSI Forum

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

Razmo

  • ***
  • 1910
  • I am shadow...
    • Kaleidoscopic Artworks
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?

If you need me, follow the shadows...

Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #1 on: November 25, 2018, 02:16:17 PM »
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)!
Noise, Noodles and Doodles: http://bit.ly/mrjonesthebutcher

Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #2 on: November 25, 2018, 04:56:55 PM »
Iíve never had an issue using the Tempest as the master clock. It almost always is for me.
Prophet 6, Prophet X, Moog Sub 37, Tempest Drum Computer, Roland V Piano, Fender American Stratocaster, Roger Linn Adrenalinn iii, Origin Effects Cali76 and SlideRig compressor, ASUS Zenbook Pro Computer, Soundcraft MTK 22 Mixer, Mark Of The Unicorn Digital Performer 10 Software.

Stoss

  • **
  • 141
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #3 on: November 28, 2018, 07:35:28 AM »
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.

Razmo

  • ***
  • 1910
  • I am shadow...
    • Kaleidoscopic Artworks
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #4 on: November 28, 2018, 11:02:26 AM »
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...
If you need me, follow the shadows...

dslsynth

  • ***
  • 1036
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #5 on: November 28, 2018, 02:10:57 PM »
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!
#!/bin/sh
cp -f $0 $HOME/.signature

Razmo

  • ***
  • 1910
  • I am shadow...
    • Kaleidoscopic Artworks
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #6 on: November 28, 2018, 02:55:12 PM »
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. :)
« Last Edit: November 28, 2018, 03:01:08 PM by Razmo »
If you need me, follow the shadows...

dslsynth

  • ***
  • 1036
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #7 on: November 28, 2018, 03:15:20 PM »
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.
#!/bin/sh
cp -f $0 $HOME/.signature

Razmo

  • ***
  • 1910
  • I am shadow...
    • Kaleidoscopic Artworks
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #8 on: November 28, 2018, 04:09:05 PM »
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.
If you need me, follow the shadows...

dslsynth

  • ***
  • 1036
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #9 on: November 28, 2018, 06:29:00 PM »
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.
#!/bin/sh
cp -f $0 $HOME/.signature

Razmo

  • ***
  • 1910
  • I am shadow...
    • Kaleidoscopic Artworks
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #10 on: December 21, 2018, 09:05:55 AM »
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 :)
« Last Edit: December 21, 2018, 09:11:31 AM by Razmo »
If you need me, follow the shadows...

Stoss

  • **
  • 141
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #11 on: December 21, 2018, 10:20:20 PM »
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?

Razmo

  • ***
  • 1910
  • I am shadow...
    • Kaleidoscopic Artworks
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #12 on: December 22, 2018, 01:29:17 AM »
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.
« Last Edit: December 22, 2018, 01:34:37 AM by Razmo »
If you need me, follow the shadows...

Stoss

  • **
  • 141
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #13 on: December 22, 2018, 06:59:00 AM »
^ 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.  :)

Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #14 on: January 23, 2019, 10:29:04 AM »
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.

Stoss

  • **
  • 141
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #15 on: February 17, 2019, 08:36:10 AM »
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?

Pym

Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #16 on: February 17, 2019, 01:59:50 PM »
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?
Dave Smith Instruments

Stoss

  • **
  • 141
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #17 on: February 17, 2019, 05:32:18 PM »
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?

Razmo

  • ***
  • 1910
  • I am shadow...
    • Kaleidoscopic Artworks
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #18 on: February 17, 2019, 09:22:27 PM »
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.
If you need me, follow the shadows...

Razmo

  • ***
  • 1910
  • I am shadow...
    • Kaleidoscopic Artworks
Re: Please, someone who know about the current "quirks" of the Tempest.
« Reply #19 on: February 17, 2019, 09:31:54 PM »
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...
If you need me, follow the shadows...