sreams

Not a bug. This image is created in order to show a project preview in the Start Screen.

In a pinch, you could duplicate the track/events and then link the clips to allow for easy editing.

So, you bounced your tracks to a whole new set of tracks? Did you delete or archive your old tracks? If not, could simply be you are pulling too much data from your hard drive.

Makes sense. I wonder if the B2C algorithm could then analyze how the clips relate to each other in time before starting the process. Many times, the clips I'm bouncing all have the exact same start and end times, so being aware of that and then processing them together would make sense. For clips that don't start/end together (let's say you have one that spans 3:01:000-10:01:000 and another than spans 5:01:000-12:01:000), then you could still run the bounces in parallel by drawing a virtual "box" around them and running the bounce from the earliest start time to the latest end time and including each new clip as its start time is reached during the pass. Of course... I know very little about the complexity of coding such a thing.

These are all valid points, but kind of off-topic. I'm referring to a very specific bug that occurs with Elastique algorithms only. The usefulness of AudioSnap is a separate conversation that deserves its own thread.

Too big to attach here... so here you go: http://www.mistercatstudios.com/mtest.zip 1) Open the project. It contains one audio track of an overhead mic from the drum kit. The tempo map has already been adjusted to match the human performance. No timing changes have been made to the audio at all. 2) Check playback from various points along the timeline. The metronome should match the drums perfectly. 3) Select the clip and open the AudioSnap Palette. Change the Online Stretch Method to "Elastique Efficient" or "Elastique Pro". 4) Check playback again. The further along the timeline you go, the further away the drums get from the metronome.

Radius Mix works and sounds great, but is not available for realtime processing. The issue I'm describing affects realtime playback. It means "Groove" and "Percussion" algorithms are usable, but both Elastique algorithms are not.

Yeah... this is a different issue. "Bounce to Clips" is always done one track at a time with the current Cakewalk engine. BTW... looking at your video, you can see much more clearly what is going on with CPU usage in Task Manager by right-clicking on the CPU graph and choosing "Change graph to -> Logical Processors". It will then show all 8 threads and their usage on your Core i7.

So here's what I have that shows this issue: Started with a 7 minute long drum performance that was not played to any click Tapped out the tempo onto a MIDI track while listening to match the drum performance Used "Fit to Improvisation" to perfectly match the tempo map to the human performance In AudioSnap, set the clip Follow Options to "Auto stretch" Checked the box for "Follow Proj Tempo" After that last box is checked (I have made no timing changes to the drum tracks yet), everything looks fine on the timeline. Playback is perfect with the clip set to use "Groove" for online render. As soon as I switch to "Elastique Efficient" or "Elastique Pro", playback no longer matches the visible waveform. It sounds kind of okay for the first few measures, but playback is a little fast and gets more and more ahead of the click as playback progresses. Again... the visible waveform looks fine and matches beats/measures perfectly. Switching back to "Groove" or "Percussion" completely fixes the issue. It makes the Elastique algorithms pretty much unusable. I can upload trimmed-down project to show this behavior if it is helpful. It is 100% reproducible.

I've been doing some drum timing adjustments using Audiosnap. I have 12 tracks of drums. All are set to use Radius Mix for offline rendering. When I'm happy with my adjustments, I select all of the clips, right click on one, and choose "Bounce to Clips". It then takes a very long time to complete the task. Looking at Task Manager, I can see that only one thread of my 12-core/24-thread Ryzen 3900x is being utilized. Overall CPU usage shows as just 6%. It seems that if each bounce could be processed on it's own thread, processing time could be reduced by massive amounts. Any thoughts on this from the bakers?

I've had this occur multiple times. I think it is easily reproduced.

Ah... so you do mean the fader throw length, not the size of the faders themselves. I'd be a fan of allowing for user adjustable fader throw. I just wouldn't change it for myself, and I'd hope that the more screen-space efficient current size would remain as an option. I'm also a fan of adding sidechain routing to the plugin window.

I ran into an issue a couple of times today. I was zoomed in on the timeline to find an audible glitch in a waveform. I then pressed play. Playback started, and of course, the fully zoomed-in timeline is scrolling by very quickly at this point. All expected... but Cakewalk stopped responding to all inputs at this point. I could not stop playback by pressing the spacebar or the stop button on my control surface. I could not change the zoom level. Playback would just continue and eventually Cakewalk would respond to key presses from 15-20 seconds prior. This is on a Ryzen 3900x system.

Not sure if anyone else has brought this up... but I am no longer able to use the Ctrl modifier to open multiple plugin windows simultaneously. If a plugin window is open, holding Ctrl and double clicking on another plugin does nothing.

I'm confused by what you mean when you say the console faders are too small. I've attached a screenshot showing the FL Studio, Cakewalk, and Cubase faders side by side. They all look about the same to me. Do you mean how long the throw is? If that's the case... I don't entirely agree. Fader accuracy when using the mouse is defined entirely by how far you have to move the mouse itself, not by the graphic on the screen. I can move even the tiny Track View faders with just as much accuracy as any 100mm fader (and with even more precision while holding shift). I'd rather not see faders taking up more precious screen space if there is no real-world benefit. That said... I'd be all for the fader throw being adjustable. Could you describe what Sequoia does differently in regards to sidechains?