Discovered an Exciting New (?) Bug in Session Drummer 3

[John Bradley]

 I use Session Drummer 3 as my default drum VST. Recently I noticed a problem where crash cymbal hits would occasionally glitch during playback and/or export, despite there being no audio dropouts reported by Cakewalk. So I've taken to freezing the drums, which I'd prefer not to do, but whatever.

I have SD3 sending its various pieces to separate tracks in Cakewalk (kick, snare, hat, toms, crash, & ride), so when I freeze the synth it freezes the kick, the snare, the hat, etc. in that order.

The weird bit: I noticed that one one project it was taking forever to freeze the crash and ride tracks. The kick, snare, hat would freeze in a few seconds, as expected, but it'd take literally minutes to freeze the crash and the ride.

After much poking, I discovered that Session Drummer 3 hates continuous tempo changes in the song, but only on the sustained sounds. Why that would be, I have no idea - it shouldn't be stretching the audio of the samples just because the tempo is changing. A crash is a crash.

 

To reproduce:

 Start a new project, instantiate SD3 running separate outputs as above. Paste some midi drum loop that features crashes and rides, and repeat it out for 80 bars or so.

Open the tempo track and verify that there's just a single tempo point (120 bpm at 1:01:000). Freeze the synth. Should take a couple seconds per track, and finish doing all of them in 30 seconds or so, at least on my rig.

Add a second different tempo point (140bpm or whatever) somewhere in the middle of the midi, say at bar 40. Have the tempo JUMP to the new tempo. Freeze the synth. Takes a couple of seconds per track, same as before.

Now, set the line connecting the two tempos to LINEAR. Freeze the synth. The kick, snare, and hat go about as quickly as before, the toms are noticably slower, and the crash and ride are so slow that it looks like the program has frozen. Several minutes to freeze each of them.

---

Bug in SD3? Seems like one, but who knows. Certainly it's never going to be fixed if it *is* a bug, so I'm looking for a workaround (short of "stop using Session Drummer").

Is there a way to specify the granularity of continuous tempo changes? If I could draw a linear tempo change but have it 'look' like a series of discrete tempos every 16th note as far as SD3 is concerned, that might do the trick.

Though I don't know why SD3 even cares about the tempo in the first place. Yes, it has a pattern playback that syncs to host tempo, but I never use that and clear out all the patterns by default. I'm just sending it notes from a piano roll.

 

[John Bradley]

I should note that continuous tempo changes were probably the cause of the initial glitching of the crash cymbals, so if I could get semi-continuous tempo changes somehow that'd probably alleviate the need to freeze the synth in the first place.

[David Baay]

I'm always advising against using continuous tempo changes because it's not musically necessary to have tempo changes in between notes and can cause problems with many instrument and FX plugins. You can avoid this by enabling  snap at a resolution that matches the smallest note interval  when drawing tempo changes.

[msmcleod]

2 hours ago, John Bradley said:

 

Is there a way to specify the granularity of continuous tempo changes? If I could draw a linear tempo change but have it 'look' like a series of discrete tempos every 16th note as far as SD3 is concerned, that might do the trick.

 

The TempoMapDecimationResolution  setting within Cakewalk.ini changes the granularity of tempo changes, but the default actually is every 16th note:

https://www.cakewalk.com/Documentation?product=Cakewalk&language=4&help=Tempo.15.html

Ignore the title of the topic in the docs... actually only the last two ini variables affect importing old projects. The TempoMapDecimationResolution affects all projects.

[John Bradley]

Follow-up: It isn't a Session Drummer 3 thing per se, as I did the same experiment with the free version of Steven Slate Drums 5.5. 

Same results. Freezing any of the outputs that have sustained sounds (overhead, room, etc.) takes forever compared to the kick or the snare. It would seem that freezing these tracks is going through the (Cakewalk) Audio Stretch algorithms, for no readily apparent reason. And there's no obvious way to tell it to not do that. 

Of some note: If I select the output tracks and do a Bounce to Track(s), that renders all the tracks simultaneously and without any slowdown whatsoever. Which is ideally how I'd expect freezing the synth to work as well. Suppose I could just mute the synth and drag the rendered clips up to the output tracks as a workaround, though that's not nearly as convenient as freezing/unfreezing.

---

Also, I found that if I set Freehand Smoothing to Jumps, and drew a somewhat-straight line connecting the two tempos, it would draw them as a series of jumps. This Freezes much faster than having a single continuous linear tempo change between the two points. (I explicitly set the TempoMapDecimationResolution to '1', which is the coarsest granularity available.)

 

That's keen, but I'd like to be able draw a straight line in the Tempo Track and have it replace that with a series of Jumps snapped to 1/4 notes or whatever when I release the drag.

The manual ( http://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Tempo.07.html#2000135 ) seems to be saying that I can hold SHIFT, then click and drag a line with the Line Tool and that's what should happen. Only it doesn't for me. Holding either SHIFT and then clicking+dragging in the Tempo Track with any of the Draw tools does nothing at all, either during the drag or upon release. And clicking first and then holding SHIFT during the drag doesn't do anything different from a normal click+drag. 

Shift-click+drag works as expected elsewhere in Cakewalk - contrained moves in the piano roll, precision fader moves, etc. So I don't think it a case of some other program 'eating' the shift-click event. Heck, it even works within the Tempo Track itself: shift click with the smart tool does a constrained move of the nodes. It's just the Drawing tools that don't work as expected.

I have Snap turned on in the Control Bar, and have both the Snap Note and Draw Note Duration set to 1/4 for good measure. Neither Snap To nor Snap By have any effect. The nodes drawn in the tempo track with any of the Draw tools just go wherever they want - they're not snapped to the grid.

[msmcleod]

@John Bradley - there's gotta be something else at play here.  Below is me freezing SD3 with both tempo changes  and without tempo changes - both on a single SD3 instance, and with 4 instances ( Bass Drum, Snare, HiHats, Cymbals).   The freeze time for tempo changes / no tempo changes is identical:

[John Bradley]

Thanks for looking into it. Agreed, it's something else. 

I ran the same test on an old laptop I've got and it worked as expected - all tracks froze at the same speed.

And now, having run the test many times on my main machine, trying various things (disabling all FX, deleting any sends to reverb & parallel compressors, etc.) I can no longer get the 'problem' to occur there, either.  Possibly it was just corruption in the project file or the track template I use for the drums. Possibly the machine just needed a reboot.  Possibly it was just one of those things. Given the untold millions of lines of code involved in Win10 it's a minor miracle that anything works at all.

I'll poke around with it some more to see if I can provoke it into reliably occurring again, but yeah...

Still, thanks again. Appreciate it.

[lapasoa]

For continous tempo changes it's better you got a real drummer.

[David Baay]

20 hours ago, John Bradley said:

The manual ( http://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Tempo.07.html#2000135 ) seems to be saying that I can hold SHIFT, then click and drag a line with the Line Tool and that's what should happen. Only it doesn't for me.

Hmmm..., yeah, not working here either; holding Shift causes nothing to be drawn as you noted.

I normally get tempo changes by using Set Measure/Beat At Now with MIDI recorded in real time without a click, so hadn't noticed this wasn't working in the new tempo track.

It didn't used to be necessary to hold a modifier when drawing in the old tempo view. It automatically honored snap if enabled. Can't see offhand  why this change would have been necessary, and would suggest the Bakers restore the old behavior if possible.