I noticed last night that after slaving the OT to the DAW and recording a couple of loops from external hardware (my DAW has better converters and it lets me tweak the mix of the loops before I export them as stems and load them back into the OT, so I can use all of my effects slots for creative stuff instead of mixing), the OT’s tempo had changed from 110 bpm to 110.2 bpm, and the “original tempo” values for the loops were 110.14 bpm. I know the sync I get from a DAW isn’t nearly as stable as the OT’s internal clock so I am not surprised to see the loops themselves a couple MS off (it wasn’t nearly enough to be noticeable) but the OT’s actual tempo being a little different is strange. I’ve only been using this sampling workflow for a few days but it only happened that one time.
Anyone else experience anything like this? If the OT was slaved to an external device that was nominally at the same tempo but had a lot of jitter, would its internal tempo setting actually be changed to match the actual tempo of the external clock source rather than the nominal tempo? That seems like strange behavior compared to any other hardware sequencer I’ve used. I’ll be getting the security deposit from my old apartment back in a week or two, maybe I should invest in one of those TM-1 interfaces.
Most people suggest OT as master if syncing to anything else (including DAW). Basically, like all hardware it will act like a tap tempo, it will average the last so many beat ticks and formulate an bpm from this.
The OT probably picked up some jitter in this case as you mentioned, which put the overall tempo averaged (when the clock was stopped) at 110.2. Normally with slaving devices, you will see that master tempo fluctuate +/- and the medium of that fluctuation is the original tempo, I believe it was just speeding up to catch up with the tempo when the clock was turned off (coming back from 109.8, passing 110.2 to average it out).
Right, but when dumping tracks to a DAW, you need to set the DAW as the master to achieve any kind of decent sync between passes, regardless of what you’re using.
The main thing I’m interested in is why the master tempo of my actual project was changed, that’s something I’ve never experienced with other hardware. I guess my first post doesn’t really make it as clear as I thought looking at it now - the actual tempo setting in the OT project itself was changed and I had to manually change it back. Which is completely strange behavior.
As far as dealing with jitter, I guess I could save myself some money and just go back to slaving the MPC2000 to the DAW via SMPTE and then using it as the master for all of the other hardware, which is way tighter than MIDI clock from any general purpose computer I’ve ever used but also kind of a hassle.
the tempo setting is not at the project level… its a global setting - and it doesnt change per project… so its always set manually, unless you are slaving to external clock, in which case it changes according to the master clock
the “original tempo” setting for recorded loops is a variable setting which is calculated by the audio input IIRC, but its not a fixed value (meaning you can set it to whatever you want without affecting the actual audio) and basically it just gives you control over how the timestretching will affect that particular loop
and yes, slaving to external clock (of any sort, but especially a computer) tends to introduce such micro-changes in BPM settings, in all hardware, at all times - unless you are using something with a very high level of sync capability for the master clock source, and even then you are still depending on the slave to get an absolutely tight lock on it, which may or may not be the case
Ive mentioned before that I still dont understand why manufacturers dont give people a setting for “BPM drift tolerance” in some menu somewhere, so you can make a machine ignore any clock changes above or below a certain threshold amount (like 0.5bpm or something) which would greatly increase sync stability… but yeh, it hasnt happened on any device yet as far as Im aware, but Id really like to know if there are things out there that have solutions for this kind of thing because I havent heard about any yet
and this is exactly the reason why things like “Ableton Link” exist…
but in general - i tend not to use MIDI clock sync… I just set everything to the same tempo and let them use their own internal clock… in some very rare cases there are usability issues from this (an arp thing or fx thing etc.) but yeh its pretty rare… and in that case i either find a workaround or just go ahead and deal with the wonky clock sync for as long as necessary until i dont have to anymore. the only real big issue with this is having a large continuous set with tracks that have different tempos… but you can still workaround this if you just put a bit of thought into it
The TM1 won’t fix this. If your OT’s tempo is slaved to a DAW then it will fluctuate as the DAW midi won’t be stable. as the post above suggests, turn off clock sync (but not transport sync) on the OT and set the tempo manually. That will be the cheapest / easiest solve.
Otherwise a midi sync box would be another option, but I wouldn’t know which / what to recommend there.
also to mention - if going for the cheep and cheerful option of switching off OT clock sync, it is possible to have the OT externally synced to external tempo up until the time of recording… then just set the sync to be internal while it is playing.
but here’s the cool thing, the OT will continue being in sync with current tempo as it will not change her bpm until an actual movement is made on the bpm; until then the OT tempo will remain unchanged even though the “sync” was just changed from external to internal.
Machinedrum mkII master and Octatrack MkI slave worked like a dream from day one, never a missed beat nor experienced jitter, although i wasn’t sampling with the OT, just sequencing one-shots and looping/p-locking audio clips. Also playing the Machinedrum via the mixer or an input machine.
Actually i may have noticed issues in a slight latency if the input machine was being used and the OT was slaved to the Machinedrum’s tempo … but that was back in 2012 and tbh don’t quite remember.
didn’t ever try linking the OT via midi to computer, possibly the computer-based midi clock may somehow introduce issues for the OT’s responsiveness or function if the OT is slaved, depending on the computer, daw, and interface.
if recording a loop from Machinedrum to Ableton, i set the Machinedrum tempo to the same as Ableton, sync to the tempo manually, then record 6 bars and edit 4 as a loop then export that.
Invariably the loop recording in Ableton clip info says the loop is 129.99bpm if the tempo recording was at 130bpm … doesn’t seem to make a difference, although i do notice an orange square at the start of each clip, maybe that is some kind of instantaneous tempo workaround or something.
So it does actually change to reflect the external clock source instead of being overridden. Strange. Literally every other piece of hardware I’ve used in my life that can accept external sync works differently from this, so it took me by surprise, I just assumed that when you switched back to the internal clock the tempo would still be at the same value it was at before I had switched to external clock, but I can see how this behavior would be useful if you needed to seamlessly switch between internal and external clock in a live setting for some reason.
Anyway, it definitely makes more sense to just use the internal clock but have the OT respond to external transport messages when I’m dumping short loops. I’m used to using SMPTE for sync from the DAW dumping tracks.
Anyhow, I was live-sampling someone’s modular setup last night in a new collaboration that we’re just getting started, and while I was setting up a new OT project for us I did a kind of a quick, informal A/B between the outs of his synth going directly to the mixer and the same signal being sent from an aux sent to the OT, recorded, and simultaneously played back from a flex machine and back out to the mixer. When the levels were matched it was basically indistinguishable (not a formal test or anything, but the similarity was pretty eye opening, especially considering that we were listening on a really nice set of monitors) so to be honest I’m probably not going to bother sampling to DAW anymore, anyhow. It’s just extra work and the converters on the OT seem perfectly fine as long as the gainstaging’s right.
But it’s still useful to know that the OT tempo behaves this way when it isn’t the master (which it always is when I use it, other than this one scenario).
after a year or two back on Ableton i certainly am looking forward to returning to the Octatrack or maybe trying out the Mpc Live.
the one advantage of the daw route is the quick visual access to what the soundfile looks like, but that is available easily in the OT sample edit window.
doing A B tests is a highly recommendable activity in a variety of areas…
as regards OT tempo after it is decoupled from tempo slave to then be internally synced, when the OT tempo is slightly adjusted even .1 of a bpm, it will be adjusting that increment to the tempo that it was before it was externally synced.
but until that manual adjustment happens, the tempo will remain the same as the external sync signal it was recently unslaved from.
This is what surprised m, never encountered that before, every other hardware sequencer I’ve used just completely overrides the internal tempo setting when it’s being clocked to something else, and then reverts to it when you set it to internal clock.
Regarding the TM-1 not helping alleviate jitter when using the DAW as a master clock source, isn’t that kind of the point of it? That since it’s using a nonstandard, higher bandwidth, higher resolution protocol to transfer the MIDI data it alleviates some of the jitter that’s typical with general purpose operating systems? I know the whole source of jitter has to do with the way multitasking OSes prioritize interrupt requests and that modern OSes all give certain types of time-critical data like digital audio streams higher priority (which is part of why you don’t get audio jitter at the OS level), so wouldn’t the whole purpose of something like the TM-1 be to work around the OS limitations on the accuracy of MIDI data streamed to hardware by essentially fooling it into thinking it was a different kind of data?
If it really is just increasing the bandwidth of the MIDI data so that you don’t have as many microtiming issues when you’re sending a lot of MIDI data on a single port that seems kind of silly, considering that Elektron’s sequencers really can’t generate that many notes at once anyway (although I guess the do have the potential to send a LOT of controller data). Are we sure it doesn’t tighten up the tming? I never bothered to test the amount of jitter my DAW has, but I know computers in general tend to be up in the 4-5ms range even if they’re wel optimized, and the OT has been tested at more like (of the top of my head) .4ms, almost exactly the same as the MPC2000 and definitely on the respectably low end of the spectrum for hardware (although not at that science fiction level of stability the MPC3000 somehow gets where its MIDI clock signal is pretty close to sample accurate with its audio output, at least if tests are to be believed).
Most of the time this isn’t really an issue for me but there are still times when being able to slave to DAW without all the jitter would be nice (remote collaborations in particular).
Or maybe I should jsut build one of these. I built a Midisizer MidiREX a couple years ago and it works great so I have no doubt this thing is solid too, especially since the clock itself is probably based on Mutable’s MidiPal code.
Eh, whatever, I ended up just picking up an old JL Cooper PPS-1 for a few bucks instead, that way I can use SMPTE instead of Midi to pass clock out of the DAW if I need to, plus I’ll finally be able to sync stuff to my old portastudio.
I mean, I could already do that with the MPC but it was a lot less convenient.
fascinating workaround, going the smpte route, didn’t know that would help…
rme and ua cards have their own form of proprietary non-jitter technology in the programming, and if anything would help as regards alleviating jitter that would… the TM1 however is more designed to allow for 10x the speed of audio sample transfer over midi technology by allowing turbo mode which requires a midi realtime information feedback scenario using proprietary coding specially in conjunction with the tm1.
but yeah, i’m pretty over using hardware and software together for anything except simple single audio file capture to daw for sound reinforcement preparation purposes. even then, i would be inclined to just access file recordings directly from the OT’s media card.
Oof, should have read the manual, that JL Cooper outputs MIDI time code not MIDI clock, looks like I’ll be using the MPC to convert SMPTE to clock or building a MIDIgal after all.
EDIT: the upside is it can stripe tape with MIDI song position pointer, so that should be fun with the portastudio.