Jump to content

Bugs Drive Me Nuts!


marcL

Recommended Posts

The last days the "unstoppable playing" bug and a bug with changing the clip start in the properties drive me crazy! Puhh, I had to vent my anger!!! 😠

The first bug just happens when you are often starting and stopping play with the spacebar. Suddenly, the play thread is unstoppable and the only way to get rid of it is to kill CbB with the Task Manager (Maybe CbB should have an included Task Manager for this case?!). Happens to me several times each day! It doesn't matter which project, which computer, which interface I use! There are others that have complained about that, too.

The second chagrin happens changing the "Start" in the clip properties with the arrows. Randomly the contents of this field disappears and when I click on the clip then, the clip also ends in smoke. Thankfully there's Ctrl+Z that gets back the clip in a wonderful way, but the flow of work is always stopped!

I hope the Gods hear my lamentation and there will be soon a new release without this agony! 😄

Link to comment
Share on other sites

Normally you shouldn't have to kill off Cakewalk.

Stopping/Starting the audio engine should be enough... unless of course the GUI has completely locked up.

BTW - I've noticed that when this happens, although the space bar stops working, any control surface connected still works.

Link to comment
Share on other sites

2 hours ago, marled said:

The last days the "unstoppable playing" bug and a bug with changing the clip start in the properties drive me crazy! Puhh, I had to vent my anger!!! 😠

The first bug just happens when you are often starting and stopping play with the spacebar. Suddenly, the play thread is unstoppable and the only way to get rid of it is to kill CbB with the Task Manager (Maybe CbB should have an included Task Manager for this case?!). Happens to me several times each day! It doesn't matter which project, which computer, which interface I use! There are others that have complained about that, too.

The second chagrin happens changing the "Start" in the clip properties with the arrows. Randomly the contents of this field disappears and when I click on the clip then, the clip also ends in smoke. Thankfully there's Ctrl+Z that gets back the clip in a wonderful way, but the flow of work is always stopped!

I hope the Gods hear my lamentation and there will be soon a new release without this agony! 😄

Please submit Cakewalk exact steps how to reproduce an issue. Also include full system specifications and a showcase project of your problem. You could also use screen2gif or similar screen capture program to show developers exact steps how to produce the issue.

Cakewalk fixes bugs actively - just look at the list of fixes on each release. You can participate by submitting problem reports. Ranting on user forum does not help much.

  • Like 1
Link to comment
Share on other sites

4 hours ago, panup said:

Please submit Cakewalk exact steps how to reproduce an issue.

This.

Even if you want to blow off steam in the forum, it's helpful to add this, because members of the dev and beta teams read the forum.

Bugs may seem random, but often they are not as random as they seemed at first if you keep your awareness up while you are watching for them to manifest.

With the spacebar transport control bug, you say that it only happens after you start and stop it many times. How many, and are there certain activities in between the starts and stops? Is it with audio projects, MIDI, mixed? Projects with certain plug-ins? Melodyne?

People outside the development process think that finding bugs is easier than it actually is. We can't just tell a developer "sometimes I can't stop the transport with the spacebar" and expect them to read through the code and "oh, I see, there it is, that's where the code has a problem!"

It takes a team of people to find something like this, and the first step, always, is figuring out how to get it to manifest 100% of the time, and that's where you can help.

  • Like 3
Link to comment
Share on other sites

The unstoppable playback might get fixed if you click the image.png.3db073384201800ecc4ae1ed5558a6ed.png button (Input echo for all tracks) in the Mix module. That, of course, will screw up your active input echoes, but it will also make the audio engine come back to its senses. You might want to click it again to disable all input echoes. 

This at least works for me with my Focusrite Scarlett 2i2 (1st gen). No need to kill & restart CbB. It's been a problem with all driver versions, probably has to do with an ASIO buffer too small for the project. 

      -Pete

Link to comment
Share on other sites

12 hours ago, petemus said:

It's been a problem with all driver versions, probably has to do with an ASIO buffer too small for the project. 

This is sounding familiar.

For anyone with this issue, I suggest increasing  ASIO driver's buffers to see if it helps. I'm having vague memories of my transport getting balky on a project and jacking up my driver buffers fixed it when I was very new to Cakewalk.

If it helps, please let it be known so that everyone can benefit and the developers can work on it.

Increasing the buffers  would be a workaround, which is all well and good, but the program should be the boss of the driver, not the other way around.

On 7/13/2019 at 1:54 PM, msmcleod said:

I've noticed that when this happens, although the space bar stops working, any control surface connected still works.

This suggests to me that while the program is still polling control surfaces, it's given up polling the GUI and the keyboard.

Educated guess is that it's about servicing interrupts, and what priority the program gives to which ones. Surely it would need to pay as much attention as possible to I/O in order to allow the lowest latency, and I imagine that paying attention to the GUI is an "expensive" activity. It has to update status and maybe put the program into a different mode and pop a window every time the cursor goes over a different hot spot, of which there are many.

I can't see the keyboard as such, though, all the program has to do is sit and wait for input, just like with a control surface.

Link to comment
Share on other sites

Thanks for all the comments!

Even if I don't think that these bugs have to do with the system itself (the 2nd bug certainly not!), here are the system specifications:

  • i5-8600K (3.6GHz, 6 cores, Coffee Lake), MSI Z370-A Pro, 16 GB memory, 512 GB SSD
  • Focusrite Scarlett Solo 2nd Gen (I tried with the previous and very actual driver)

I didn't have the time yet, but I will try to find out if the Focusrite driver has something to do with it (unstoppable playing), i.e. I will test with my 2nd USB audio interface (Behringer UMC404HD). But even if the Focusrite driver is involved, CbB should have control over its audio thread, so that you can close it!

Also I have to mention that this happens even in very tiny projects, i.e. there is only one simple instrument track (AAS Strum GS-2) and a second audio track with some loop recorded takes (44.1kHz, 24-bit). I did not use any more plugins (Not that the ones jump in that always insist it maybe a plugin problem)! Most of the time the instrument track is muted, because I have soloed the track with the takes! And maybe 2 very important details:

  • I had always enabled a small loop range but I stopped (tried to stop) the audio transport before repetition by hand (with the spacebar or the stop button).
  • The metronome is always enabled (play)

In addition to the test with another audio interface I will also check if it makes a difference if I replace the instrument track by an audio track, as this would remove the only plugin used.

The second bug (clip start position) may also have a relation to loop recorded takes only. In any case I have had this problem always with such clips.

  • Like 1
Link to comment
Share on other sites

20 hours ago, marled said:

Thanks for all the comments!

Even if I don't think that these bugs have to do with the system itself (the 2nd bug certainly not!), here are the system specifications:

  • i5-8600K (3.6GHz, 6 cores, Coffee Lake), MSI Z370-A Pro, 16 GB memory, 512 GB SSD
  • Focusrite Scarlett Solo 2nd Gen (I tried with the previous and very actual driver)

I didn't have the time yet, but I will try to find out if the Focusrite driver has something to do with it (unstoppable playing), i.e. I will test with my 2nd USB audio interface (Behringer UMC404HD). But even if the Focusrite driver is involved, CbB should have control over its audio thread, so that you can close it!

Also I have to mention that this happens even in very tiny projects, i.e. there is only one simple instrument track (AAS Strum GS-2) and a second audio track with some loop recorded takes (44.1kHz, 24-bit). I did not use any more plugins (Not that the ones jump in that always insist it maybe a plugin problem)! Most of the time the instrument track is muted, because I have soloed the track with the takes! And maybe 2 very important details:

  • I had always enabled a small loop range but I stopped (tried to stop) the audio transport before repetition by hand (with the spacebar or the stop button).
  • The metronome is always enabled (play)

In addition to the test with another audio interface I will also check if it makes a difference if I replace the instrument track by an audio track, as this would remove the only plugin used.

The second bug (clip start position) may also have a relation to loop recorded takes only. In any case I have had this problem always with such clips.

Maybe try the beta Focusrite driver at beta.focusrite.com

Link to comment
Share on other sites

On ‎7‎/‎16‎/‎2019 at 4:35 AM, marled said:

CbB should have control over its audio thread, so that you can close it!

Some would think so.. but I don't. See your device controls latency, buffer and playback sound. If that driver is crashing/failing then there is nothing Cakewalk can do about it except go along for the ride. I used to have a device that I would literally have to kill Sonar with task manager everytime there was a freeze up with that device.

What ever it is, keep us posted after trying the Behringer. If that doesn't solve it, it might be a bug in Sonar and I can try to rerpo complete steps with you.

Link to comment
Share on other sites

In one thing you are absolutely right, Chuck, the Focusrite driver (both versions) was really involved in the unstoppable play thread! 😉 So far with the Behringer UMC driver this bug has not occurred! Nevertheless should CbB IMO react when I press the spacebar or the stop button, 'cos the driver has not crashed (still playing)! This is only a matter of technical implementation.

For me the result means that I will use the Behringer UMC404HD interface now. But out of interest I will try if some configuration change makes a difference with the Focusrite one as soon as I have some time. Additionally I will cancel my plans to buy a Scarlett 18i20 next year, because this is the third time I had trouble with their drivers. It's a great pity 'cos I like the 18i20's design ... 😥 I wonder why Focusrite have such a good reputation?

Concerning the other bug the interface/driver change made no difference, as expected. If I try to fine tune the start position of an audio clip in a take lane, then it happens sometimes that the clip disappears (can be reversed with Ctrl+Z fortunately). I change the clip Start in the properties either with the arrows, Ctrl+Z or Ctrl+Shift+Z, then start play and listen, press stop and then the whole thing again and again (I am cautious and do not change the clip start during playing!).

Link to comment
Share on other sites

Hm I'm using a Focusrite 6i6 daily for development and have never seen this issue. I really doubt its related. My only guess is that something in the app has crashed and is unresponsive to transport commands. Does it happen in all your projects or only some and how often?

Regarding the clip issue please see if its still happening in our new early access release since there are many changes and fixes to take lanes.

Link to comment
Share on other sites

Now that's great info. Thanks.

Obviously your system is more than up to the task of running any level of project you want with Cakewalk, so we can eliminate resources as a possible issue straightaway.

It happens with a very common instrument plug-in that used to ship with Sonar, AAS Strum, so it's probably not that.

That lets you narrow it down to maybe an issue with how the program interacts with the ASIO driver, which it seems to be.  I'm curious, just as an experiment, whether it happens if you use the Focusrite in WASAPI mode?

Sometimes there can be problems with the way Windows is talking to USB devices if you've disconnected a device from one port and then plugged it back in to another port. The way to check for that is to run Device Manager and select View/Hidden Devices from the menu and see if you have duplicates of the Focusrite. If there are any, uninstall all entries pertaining to the Focusrite. Then unplug it, plug it back in and let Windows reinstall it.

As for the clips issue, please do try the EAP release and report back. It is packed with fixes and feature updates to Take Lanes and editing, and even if it doesn't solve your issue, you'll find it a big step forward.

Link to comment
Share on other sites

14 hours ago, Noel Borthwick said:

Hm I'm using a Focusrite 6i6 daily for development and have never seen this issue. I really doubt its related. My only guess is that something in the app has crashed and is unresponsive to transport commands. Does it happen in all your projects or only some and how often?

Thanks Noel, also a lot for the new release (I only read about the contents and that makes me really happy)!

Regarding your questions above: It happens in any project (even very light weight like described above) and there were times when it occurred several times an hour, but sometimes only once a day. But what let me ***** my ears today (fig.) is the comment that Marc(msmcleod) has written (2nd one) in the "Early Access Program" thread about the "motor-boating":

"I can usually make this happen reliably by quickly stopping/starting the transport repeatedly. ... It's worth mentioning I've only ever heard of this happening with the Scarlett interfaces. I certainly don't get this with any of my other interfaces."

Even if I have another result (unstoppable playing), the initiator is exactly the same: Scarlett interface + quickly stopping/starting!!! For me it usually happens when I am aligning comping clips, i.e. I listen to a very short part (1/2 or 1 measure) several times (quick start/stop) and change in between the clip start time to find the best fitting timing.

 

15 hours ago, Noel Borthwick said:

Regarding the clip issue please see if its still happening in our new early access release since there are many changes and fixes to take lanes.

Surely, I will check the clip issue with the early access release after next week. It looks like I don't have time earlier, but maybe I am wrong?! 😄  I will write about the result in this thread.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

@Noel Borthwick : I have checked the clip issue above, both with the EA2 and the final 2019.07 release and I am sorry, but it is still present! An additional observation to this issue: If it happens, then first the clip start time disappears in the properties and then when I click on the clip to refresh the properties the clip disappears, i.e. I noticed that it only jumps to the beginning of the project: "01-01".

The unstoppable play thread is definitly coupled to the Focusrite interface/driver, because with the Behringer UMC404HD it did never happen!

But nevertheless, the new release is really the best Cakewalk we ever had! It makes me really happy that so many take lane/comping issues have been solved! I also like all these copy 'n' paste improvements and these lovely, obvious selection markers! Thank you Bakers!

  • Like 1
Link to comment
Share on other sites

FWIW, I've seen the 'playback won't stop' issue off and on for years with different interfaces (currently MOTU 2408). It's pretty rare (like maybe once every 50-100 sessions) so  not a huge problem, and may be project-specific. If Stop at Project End is enabled, it will eventually stop at that point, but I usually have that option disabled, and SONAR/CbB has to be killed because all  other options to stop playback fail, including toggling the audio engine off or hitting the panic button .  MOTU and my previous interace are PCIe-based, so turning off the interface was not an option, though that might work with a USB/FW interface to kill the audio clock.

Edited by David Baay
Link to comment
Share on other sites

I've had this same issue at random for a long time, you can temporarily fix it by 2 methods or 2 steps typically.  First thing I usually do is turn off/on echo input on any channel. Most of the time it fixes it immediately.  When that isn't working I then use the reset audio button and that usually works as well, so anytime this happens just start clicking on those two buttons and it should work just about every time. Hope this helps!

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...