Elektron-Users

Hi Dreg - I appreciate your post - however, it's not about the MPC-3000 specifically - it's just that it does happen to have a very reliable internal clock for a modern sequencer - and - if you know much of how Kraftwerk's music was created which I'm sure you and many/all people on this list would do - the clock precision built into the 3K is indeed very similar to the vintage hardware - pulse driven step/gate sequencers and early tape sync driven compositions. Certainly a lot closer than most current sequencing hardware and most/all software sequencers currently available. I'm not debating live feel either - have a look on my jukebox page - most of the CDs listed are just that. I also know there are many ways to make good electronic music - that is not my point either and a crap song is still crap no matter how tight it is if it's not your thing. I like shifting and moving things round too - always have - but it is far more satisfying to move notes around when you know the base timing grid that you are working with is well fixed rather than a floating pontoon which many boxes and software apps are. And I guess the 'moving right along' closing comment is disappointing really because I feel it reinforces the idea that getting clock timing right is an obsessive wank that is not worth worrying about and we should all just make tunes with what we have. I'm sure Kraftwerk wouldn't think so. I know it's sometimes seems a nerdy and futile debate to have - but if you had the choice between two drum machines - one that had a tight internal clock and a rubber band - which would you choose? I'm just trying to apply some friendly pressure to see if we can make it happen.

Best regards - David
www.innerclocksystems.com

Is this tight MPC clock something that Akai has lost in newer models like the 1000 & 2500?

Hi Kuniklo - uncertain - need someone to do the test who has the newer models. regards - David

innerclock wrote:
Hi all - sorry - for the life of me I can't seem to stick a jpg on this post! - If your interested just zoom in on the second USB Scope shot and in the [Cursors] box third down next to the blue triangle - 126.2ms

Best and goodnight (it's 2am!) and thanks for the generous participation today. So long as we keep up some dialogue about this stuff and get a clear idea of what is and what isn't good timing then things can only improve across the board. David www.innerclocksystem.com

As I mentioned in my post I had to zoom out so that multiple pulses could be shown on the screen at the same time. I did this so that the test data would make more sense to someone that wasn't there for the test.

But as I also said, at the finer resolution the result was a constant 125ms

Hi Nathan - does the Software Scope let you view results in samples rather than (ms) - I find it hard to believe any device locks down tight at an even 125 ms for all 16th divisions at 120 BPM. I tried the same test again today with almost exactly the same set of numbers/errors in exactly the same 'push-pull' step - pattern/relationship to each other. I got to thinking about what you said was inaccurate SF8/DAW reporting so I tested the Fantom X-6 as well and it came up almost identical to my original test also. If Sound Forge/Windows was so bad at representing and marking real-time 44.1 kHz audio - even graphically - surely my second set of tests would produce another set of numbers that were nothing like the first. Not only were they close to being identical for both machines and down to the number of samples we're talking here - not milliseconds! - but the numbers again show clearly that one machine (SPS-1) moves around much more than the other (Fantom X-6) and that has to be worth taking into real consideration here don't you agree? If I record the SPS-1 and the Fantom to the [L] and [R] of a stereo audio file in SF8 - I still see more period drift in the [L] than I do on the [R]. Sound Forge is used a sample accurate editor all over the world. Surely if I can record a James Brown 2 bar drum loop and when I play it back in Sound Forge it sounds identical in both sound quality and rhythmic feel to the original CD - doesn't that indicate precision file capture? If it couldn't do that it would be useless as an audio recorder surely. Another way of looking at this - lets say I am working on a project in Ableton Live that is 110 BPM. I have a roughly half bar vocal phrase sample that I want to use but because it's not edited to a rhythmic duration - when I drop it into Live it's hard work lining it up to the tempo grid. An easy fix for this - work out what a full bar is at 110 BPM in samples at 44.1 kHz. Open up the vocal sample in SF8 and add 5 seconds silence to the end so it's much longer than you need. Place a marker at the precise sample number that equates to a full bars duration at 110 BPM. Discard the remainder. You now have a perfect 1 bar sample to drop into Ableton Live. Now, here is the point - if SoundForge was so bad at capture, edit points and markers - my sample accurate 110 BPM 1 Bar Audio file would not line up correctly when dropped into Live. But the contrary is in fact the case - not only does the SF8 Edited 1 Bar file line up perfectly with the Live Grid BUT - Live also analyzes the sample file and reports it's tempo to two decimal places - and the result shown using this method - 110.00 BPM on the money. You gotta concede defeat now brother. Come on?

Best regards - David

It is a hardware scope that has a software front end. It does not work in samples, only time & Hz.

The MD is more than likely running off a 20MHz Xtal. Such Xtals have a 1ppm error and the divide factor to get to 24ppq for a midi clock is 833,333.33 divide per quarter note. So with one error per million oscillations that means you would get at most a 20us error spread over 20 seconds of output.

I believe that it is possible to get repeatable results with your testing method. The algorithms for deciding what to display for instance is a likely source of overall error all be it a repeatable error.

I am not saying soundforge, albeton, etc, are bad at recording. I am however saying that it is NOT possible to test to the level of accuracy that you indicate with these type of software as a test base. Think about it, you screen is only 1000 pixels wide... so to seen even a reasonable representation of the incoming audio you would need to have the time frame of your DAW set to at least (1/441000)/2.2 = 10us... TEN MICRO SECONDS! can Soundforge do that? display 10us sections of recording across the full screen? (the 2.2 is for Nyquist)

Another trick that is common in DAW software is that when a lag is sensed a sample and hold + interpolation algorithm is entered into. The DAW simple can't keep up and just guesses what the samples would of been. Of course this is limited to a small number of consecutive samples so as not to be perceivable.

As for the example you give.. james brown recording, vocal putch, etc. The recordings aren't accurate and the playback pitch is not perfect. Developers design such things so that the output variation is below perceivable levels, there is pitch shift, there is variation... you just can't sense it.

Windows, Mac OS X and Linix are not realtime systems. There is no way to get accurate results with anything running on any of these OS. When you are concerned with accurate results the DSO is going to win everytime.

I think David has definitely a point.

Because of this thread I've done some timing tests using my MPC4000 and MD-UW and - beside what Nathan is saying about the impossibility of using a DAW/stereo editor as an accurate measurement tool - the results I got are DEFINITELY repeatable.

If our software tools were that inaccurate (well, at least regarding audio editing. I agree with David that MIDI thorugh software mostly sucks) we probably wouldn't get repeatable results.

Regarding SF8, I can assure you it's one of the most accurate tools you could ever use for the task.

A big part of my income comes from audio editing, and I've used Sound Forge/Vegas for any kind of material and any sort of editing job. From simple beat quantization, phase-aligment down to the single sample, to x-fade looping: I've always been able to get 100% accurate results, both visually and sonically.

And finally, regarding those timing tests, I sampled and accurately trimmed my MPC4000 internal click sound. Then I loaded the sample both into my MD-UW and MPC.

I had them playing a 2 bars sequence of constant quarter notes @ 120bpm, using their own internal timing.

The MPC4000 seems to have a very constant variation range of 3 samples (7 samples only for the first beat, then it stabilize itself to 3 samples).

The MD-UW has a definitely less stable timing (the jitter was more than 50 samples in the worst cases) and as David already said it DOES look like it follows a "push-pull" pattern in its timing variations.

I can post the file containing both recordings later today: each click is clearly marked so you can easily measure the distance between clicks using any audio editor at your disposal.

This is getting ridiculous Nathan - I agree that at super fine nano second values a CRO does the job but we are talking very wide (2ms plus) variations which are more than reliably reported in any decent audio application. The pitch and timing jitter you are talking about in audio is very very small - imperceptible as you mention. The clock drift and quarter note event variation I am concerned with and recording in my tests is not only audible - it is quite clearly visual as well even with screen resolution taken into consideration. The 20Mhz Xtal CPU crystal reference is a red herring in this thread - Elektron could put a military grade reference Xtal in the SPS-1 - it makes not one difference to the tempo clock/event stability which is 100% under the influence of the OS Code the CPU is running. Average code/interrupt routines are what mess with a sequencers timing - not the precision of the Xtal Crystal clocking the instruction set. The whole nano second issue is irrelevant in all of these discussions - again the tempo variation I am concerned with and have found in the SPS-1 is way broader than that. You don't need a microscope to know when a picture isn't hanging straight on a wall.

regards - David

innerclock wrote:

And yes jitter is associated negatively - for good reason - 3ms drift or tempo clock jitter between steps on a sequencer made in the last 5 years is criminal in my opinion.

I tested the MD's clock with a decidedly less rigorous method a couple of years ago, recording the clock messages through USB MIDI interface and processing the results with a shell script. These were my findings:


In a sample of 1001 ticks, we see

797 ticks with 21ms between them
191 ticks with 22ms between them
13 ticks with 20 ms between them

That means a deviation of +/- 1ms about 20% of the time. People barked about the method, objected that the USB MIDI interface would have added more jitter and asserted that the best way to test was via an audio interface {rightly, I think}, but they missed the point spectacularly - the MIDI interface adds, rather than takes away, jitter. These are pretty good numbers any way you look at it, and are miles away from your findings.

The picture is straight, you are standing on a slant!

I don't believe the timing issue you describe exists. I believe an inaccurate testing method has led you believe that there is a timing issue when there is not.

There are a LOT of variables with the DAW test method, a lot of unknowns. An oscilloscope is considerably more accurate and reliable, it is the industry standard for these type of measurements. If the DAW results are giving one set of results and an oscilloscope another then the DAW method is flawed.