BUG - Elastique Pro-Time. Reproducible.

Anybody seeing this?

Take a drum loop several bars long and use an elastique setting to fit it to the project tempo - this will be chosen by default in C6 I think.

Loop it and playback.

Chop it up a bit - moves hits around to re-arrange the groove, copy a single snare hit throughout the pattern etc.

You soon run into disk read errors (you can see it on the little processor / disk read meters) and the audio glitches and stops playing back correctly.

Switch the stretching algorithm back to an old V5 version and it suddenly plays back ok again.

This is on a single track - the disk should be able to handle dozens (if not hundreds) of tracks doing in this, so why do you get read errors and playback glitches?

Hmmm - I think I’ve found the bug - you get glitches from disk read overload when you chop a warped sound file up when using elastique pro - time.

I’ve just tightened up a bass take - going through the track and warping notes that are out of time. It’s a 3 min take and plays back ok.

I now need to chop 4 bars out and butt the 2nd section back up to the 1st.

Suddenly you get glitches from disk read overloads.

Move the 2nd section back to its original place, and it plays back OK.

I can post a session up for anyone who cares to check this.

Link to a test session -

Link fixed!

That file seems no longer available :confused:
Anyways, just doing a very basic test here (on Mac), I had no errors at all (maybe I didn’t push it far enough?).

Hi Vic

I’ve fixed the link.

You have to do a fair amount of work on the file before you run into this issue - hence me posting one thats broken already.

(First, let me just get over the shock of finding that the audio kept dropping out… even when Musical Mode was deactivated… before I realized it was because I have a demo version of Izotope Ozone 4, which drops out from time to time… if I’d had no version of Ozone at all, I wouldn’t have had that scare! :open_mouth: :smiley: )

Anyways… nothing untoward happening here. Are you seeing overloads on the Performance meter?

(also, probably worth verifying… does it still happen for you with the Ozone plugin bypassed?)


Sorry - you can get rid of Ozone - it’s left from the full session - I deleted everything else as it isn’t needed.

Move your playback cursor to bar 67 - you can see the disk meter spiking just by having the cursor stationary on that bar!!! That’s definitely screwy and a bug.

Now play bar 67 of the bottom ‘Bass Faulty’ track - you’ll hear the glitches.

Now play bar 71 of the top ‘Bass OK’ track - glitches aren’t there.

It’s exactly the same audio, except it hasn’t been cut and moved. If you delete the 4 blue bars and shift the red section back, it will be exactly the same as the track below and the glitching will happen.

This is simply an example which shows the issue. I realise its just a little bit at the end of a big file. However, If you’re chopping up loops and moving the audio around, everything can be perfectly ok, then bam - you start getting the glitches everywhere.

Something ain’t right.

I opened the project and it’s true that at the end of the file (bar 67) the last note (bass slide) sounds bad and there it’s a big disk activity. However when I get rid of the Loop function, the last note sounds good and the disk activity doesn’t appear.

Edit: I’ve realized that if you leave the cursor in the slide note (stopped), the disk activity goes crazy! until I turn down loop mode.

Strange… I had done that, and it was perfect, but I’ve just reloaded your project again, and it is exactly as you say now. :confused:
So, I confirm (eventually :wink: )

Cheers Vic

As you say - it’s a weird one to get your head around, but when you do, it’s clear that there is something seriously wrong going on here, and my posted session proves there definitely is a reproducible issue.

Can we get this reproduced your end Steiny and added to the ‘to be fixed list’?

Have you tried flattening/bouncing the edited track?

Both will obviously produce a new audio file thats not using realtime timestretching so there won’t be any problems, and the resultant file doesn’t contain any artefacts.

This however is to be expected - the glitching is coming from disk reading overloads, not a fault in the timestretched audio.

When you get to the effected part of the audio, Cubase suddenly goes mental accessing the HD - the HD meters start flashing madly. This happens even when when you aren’t playing back - simply having the playback cursor line parked over the effected region causes the HD meters to spike.

Try it and see.

Actually just noticed maaaquemeseyo’s post above.

He’s right, this only happens when you have the loop mode on the transport engaged - it stops when you turn loop mode off.
Screen shot 2011-02-12 at 10.51.05.png
You can see from this screenshot that the playback cursor is parked on bar 67. Playback is stopped, but loop mode is on. The disk meters in the top left hand corner are spiking even though Cubase isn’t doing anything.

(it is indeed possible that when I first replied, saying I couldn’t see a problem, that Cycle was not switched on). Anyways, the problem is there with Cycle “on”, and is o.k. with Cycle “off”.

This is happening only in a very specific circumstance (which of course is this one! :laughing: )…
(first, am I right in thinking that, in your .cpr, even though Musical Mode is “on” for that clip, it is playing at its original tempo… 130 BPM… anyways? The problem goes away when Musical Mode is switched off.)

It is only happening if the Cycle start point is also a point where the file is no longer being read sequentially (i.e. your edit point). As an experiment try this…

  1. Move the Left Locator, so that it is no longer at that edit point (doesn’t matter if you move it earlier or later). The Disk overload goes away.
  2. With the Left Locator back at its original position, move the Right Locator. The problem doesn’t go away.

Hi Vic

I’m away from the studio at the mo so can’t check this.

The audio is as you say at 130 - same as the session tempo. Musical mode is on because I’m using free warping to tighten up the performance. You should be able to see all the warp markers in the audio.

My original encounter with this problem though was with a drum loop that was both stretched (to fit the project tempo) and chopped.

It seems that the crucial factor is that the Left Locator (in Cycle Play) is also an edit point. Does that also fit your first scenario (the drum loop)?

Am away from my machine for a few days, so can’t check - but want to bump this for attention/visibility (sounds unpleasant)… :frowning:

Hi Vic

Actually I now think the problem is just looping when you’ve audio files using elastique.

I was just knocking up a quick bit of music this morning for a tv commercial. The 5 audio tracks in it needed to be speeded up slightly, so I just turned on musical mode and upped the tempo - no warping within the files, and no chopped audio parts. As soon as I turned on looping, I was getting glitches from disk read errors.

I can’t confirm your latest findings here, I’m afraid.