Jump to content

BUGS and BIGS ISSUES EXPLAINED IN THIS VIDEO


Recommended Posts

1 hour ago, Starship Krupa said:

I've requested that Archiving be allowed for Lanes as well, which would take care of that problem.

You could bounce your comp to a new track, archive the comped track (which would archive the lanes, of course) and use the Track Manager to hide it.

  • Great Idea 1
Link to comment
Share on other sites

1 hour ago, Larry Jones said:

You could bounce your comp to a new track, archive the comped track (which would archive the lanes, of course) and use the Track Manager to hide it. 

'preciate it. My favorite workaround right now is to duplicate the tracks en masse, archive them, and delete the currently unused clips from the "surviving" tracks. I guess that's sort of like your idea. ?

But that doesn't take a load off during tracking.

Or Cakewalk could just refrain from streaming through muted clips, but that might cause problems when people suddenly unmute them on the fly. The matter for me is that I and the people I collaborate with sometimes like to keep several alternate takes around well into the comping and mixing process, and certainly during the tracking process.

It's not always a linear tracking-comping-mixing thing, and if you're not discarding "bad" takes as you go, they build up really quickly. Having an option to not stream through muted clips while tracking would take a big load off, I think. I calculated it out at one point and it doesn't take very long for a standard multitrack rock band recording project to accumulate over 100 audio clips if they are doing multiple takes. If the drum kit has 4 mics on it and you do 5 takes, that's 20 right there, before you even get to anything else.

I mean, what do people do to prepare for the eventuality the vocalist coming back 2 weeks later and deciding they want to go with the 2nd take instead of the 4th take? Do you studio owners just leave all of the takes sitting there? Does it not cause a performance hit on your systems as it does on mine?

I usually consider all takes "fair game" until the project is mastered, and even then, they'll stay part of the project. Storage media are cheap. Regrets that I didn't keep that crazy wailing guitar solo that the band decided not to use are expensive.

Link to comment
Share on other sites

22 minutes ago, Starship Krupa said:

Or Cakewalk could just refrain from streaming through muted clips, but that might cause problems when people suddenly unmute them on the fly.

Yeah. You can automate the "mute" function, which means some people surely do mute/unmute as part of their mixing process.

24 minutes ago, Starship Krupa said:

Do you studio owners just leave all of the takes sitting there?

I feel ya. As a former studio owner I learned to be up front with clients about just what was possible and what was not. I tried to accommodate their every wish, but I told them they can't have everything (this was in the 24-track tape recorder days), and I made sure to warn them that one more guitar solo was going to erase something, take yer pick of things you can do without.

When I had the chance to be in charge of a project, I tried to have a clear idea of where it was going, and kept only the keepers. I wasn't always right, but often enough. With modern digital recording, it feels as if you really can have everything, but as you've discovered, you can't.

Now I work only on my own projects, at home, and part of the challenge is managing all the choices. I'm a very understanding client, though, so it's not too bad to work with me.

  • Like 2
Link to comment
Share on other sites

On 4/16/2019 at 3:42 AM, msmcleod said:

My guess is it's a timing issue, where Cakewalk is restoring the settings before the plugin has fully initialised itself. The plugin then initialises itself to its default settings overwriting the settings Cakewalk has just applied.

That is an interesting theory. Like a "race" condition in programming?

One of the things that I've run into time and again in my software QA career, both as a pro and as member of various beta programs, is that developers invariably test and repro on their own incredibly high-spec systems, whereas we mere mortals are still using Core 2 Quads, or maybe a spinny drive, or we're tracking projects with 10 drum mics or whatever.

Yes, Noel is a recordist, he goes into the field and does projects, but not with clunker hardware that he's saving up to replace or upgrade a bit at a time. And is he recording metal like Scott? Does he have a friend like I do who likes to hit the vape stick, put on the cans, and literally, loop 20 takes on drums until he finds his groove?

That resulted in 80 clips, all of which he kept sitting in the lanes until comping time rolled around, in case we needed something from one of them. Which was his right.

On QA teams, they always put the new person in charge of "low-end testing" where they would have to maintain one computer at the lowest advertised spec and go through the agonizing process of testing the program on it. And then be present for the product manager's arguments with the programmers about whether or not we should raise the lowest advertised spec. Programmers: yes. Manager: no.

But that's one cause I have observed for bugs like this happening in the field more than in the office. Diversity of hardware.

  • Like 1
Link to comment
Share on other sites

7 minutes ago, Starship Krupa said:

That is an interesting theory. Like a "race" condition in programming?

One of the things that I've run into time and again in my software QA career, both as a pro and as member of various beta programs, is that developers invariably test and repro on their own incredibly high-spec systems, whereas we mere mortals are still using Core 2 Quads, or maybe a spinny drive, or we're tracking projects with 10 drum mics or whatever.

Yes, Noel is a recordist, he goes into the field and does projects, but not with clunker hardware that he's saving up to replace or upgrade a bit at a time. And is he recording metal like Scott? Does he have a friend like I do who likes to hit the vape stick, put on the cans, and literally, loop 20 takes on drums until he finds his groove?

That resulted in 80 clips, all of which he kept sitting in the lanes until comping time rolled around, in case we needed something from one of them. Which was his right.

On QA teams, they always put the new person in charge of "low-end testing" where they would have to maintain one computer at the lowest advertised spec and go through the agonizing process of testing the program on it. And then be present for the product manager's arguments with the programmers about whether or not we should raise the lowest advertised spec. Programmers: yes. Manager: no.

But that's one cause I have observed for bugs like this happening in the field more than in the office. Diversity of hardware.

I must reiterate, that this was literally a guess... so I could be (and probably am) way off the mark. Normally when troubleshooting I have access to source code, so i take a far more considered approach.

I think Jon Sasor's idea of it being down to a mixing VST2/VST3 versions of the same plugin in a project is a far more likely candidate, and it's easy to get into this situation by mistake.

  • Like 1
Link to comment
Share on other sites

2 hours ago, Starship Krupa said:

That is an interesting theory. Like a "race" condition in programming?

Given the vagaries of the VST specification, it's not at all impossible that CbB calls various VST APIs in a different order to (some) other hosts.  And some plug-ins expect one order, and others another, and a third kind don't mind...

  • Like 1
Link to comment
Share on other sites

5 hours ago, Starship Krupa said:

One of the things that I've run into time and again in my software QA career, both as a pro and as member of various beta programs, is that developers invariably test and repro on their own incredibly high-spec systems, whereas we mere mortals are still using Core 2 Quads, or maybe a spinny drive, or we're tracking projects with 10 drum mics or whatever.

That hits the nail on the head. This was also my own experience working myself in development. So my advice to any software development team would be that the developers should have average user systems at the most. A lot of modern programs could be built with less than a hundredth of resources including exactly the same functionality. If you compare pc system specifications some years back with today's, you may ask yourself why modern computers/programs do not run fundamentally faster.

Link to comment
Share on other sites

5 hours ago, msmcleod said:

I think Jon Sasor's idea of it being down to a mixing VST2/VST3 versions of the same plugin in a project is a far more likely candidate, and it's easy to get into this situation by mistake.

This is exactly the reason why I do not like the preference setting "VST3 Migration - Replace if Possible on Project Load", i.e. I always disable this. In general I feel that all these sophisticated automatic features in software do cause more trouble than benefit for the users.

  • Great Idea 1
Link to comment
Share on other sites

6 hours ago, marled said:

This is exactly the reason why I do not like the preference setting "VST3 Migration - Replace if Possible on Project Load", i.e. I always disable this. In general I feel that all these sophisticated automatic features in software do cause more trouble than benefit for the users.

Hmm, I might start doing this. A better solution might be to just go into the Plug-In Manager and exclude the VST2's that have corresponding VST3's.

More tedious, but perhaps more bulletproof. I have to do it anyway for some plug-ins that don't follow the spec and show up twice in the Browser.

Link to comment
Share on other sites

2 hours ago, Starship Krupa said:

Hmm, I might start doing this. A better solution might be to just go into the Plug-In Manager and exclude the VST2's that have corresponding VST3's.

More tedious, but perhaps more bulletproof. I have to do it anyway for some plug-ins that don't follow the spec and show up twice in the Browser.

Isn't in Setting vst  has the option to hide vst2 if there's like vst3?  However even if you set this, Fabfilter still show both vst2, vst3

Link to comment
Share on other sites

I personally haven't ran into the issues mentioned in this video, since Sonar to X to Plat to now CbB.  So they look like system dependent.   Way back, I did have issue which a few  plug-ins not retaining setting when using 32-bit through bit-bridge in 64-bit app.

Link to comment
Share on other sites

Scott has always been a class act providing excellent Cakewalk video content for a very long time. His video is NOT a rant and simply reports flagged and demonstrable faults in the software that don't look like being fixed anytime soon. The reported bugs weren't fixed when it was a paid for product and now that it's free (you join the dots....) His description of the Sonar forums being tantamount to 'old guys smelling each other's farts' just might be a text book example of the truth's prevalence over slander . The workaround for obsolescence is clearly customer churn.

Edited by ExittheLemming
  • Like 1
Link to comment
Share on other sites

1 hour ago, Feral State Sound said:

He just answered most of our comments in a new video:

 

Since he checks the forum:

My 200 projects number is a Cakewalk By Bandlab number.  If you want to get into the "life I've worked with Cakewalk" figure that is in the thousands of projects.  Started using Sonar in the late 1990s.  

As for the fabfilter losing presets, a quick google search suggests some other DAWs have seen somewhat similar reports or problems with the plugins:  (they make great plugins)

https://forum.cockos.com/showthread.php?t=182827

https://www.fabfilter.com/forum/3338/pro-q-3-bug-in-ableton-live-plugin-is-reset-when-copying-pasting-an-instance?replies=3

https://www.fabfilter.com/forum/2352/pro-q2-v202-loses-autogain-settings-from-previous-saves?replies=1

https://www.logicprohelp.com/forum/viewtopic.php?t=114904

https://www.native-instruments.com/forum/threads/fabfilter-proq-doesnt-save-settings-when-saving-maschine-project.183594/

He really thinks Fabfilter is bigger or more of a market leader than Cakewalk has been over the years?  

Software works for me and I'm thankful for it.  

I haven't belittled his problems as I'd be frustrated also.  Though Cakewalk isn't the only variable here and there are plenty of users that have never seen these problems.  

As for the comments about the space bar stoppage issue being a show stopper.  If it happens rarely then no, not a show stopper just a frustration.  Had plenty of times when something would go wrong in an analog studio messing up a take here or there.  Yes it was annoying, but albums were stil made.   Real musicains suck it up and do it again.   Funny coming from someone who specializes in the metal genre.  

He claims he has never had an issue with Waves plugins, yet he mentions Waves being one that had the reset settings issue.  

Hope it works out for him.

  • Like 1
Link to comment
Share on other sites

The idea that it works for me but doesn't work for you is an age old battle here. I don't believe either side is lying about their experiences. We have the video Scott posted as proof. Neither do I think all of it was duplicated by the Cake team., so they are being honest too. If you haven't duplicated it, then how can you fix it?  The only thing you can do is attempt to find a solution by thinking the process through.

In my own experiences I have only had the space bar delay issue  maybe once in roughly 20 times and it never happens with regularity. I only just bought a Fabfilter plugin  so we'll see. It was more than just Fabfilter though. 

Scott I guess if your just tired of dealing with the issues you're getting  any future fix is moot. I understand your frustration, especially if the tracks didn't save. That's a biggie for me. You could export the stems to another daw and hopefully save most of it, although it will require mixing again. If you want it fixed and it is fixed, then wouldn't that be the result you wanted?  

You can drink anything you want to drink but I'm not going to sit here and pretend that I don't think it could be clouding some of your software mixing decisions. It's like if I went to my lunch break and  drink a beer and come back with beer breath to work. You know people will assume that I drank more than I really did. I'm not going to pretend that it doesn't influence my judgment some just because it offended you someone mentioned it. Might be the wrong conclusion to draw, but if your going to do it on a technical mixing video and drink then you can live with what I think about it. I am entitled to my opinions. I will say that most likely you haven't had enough to make a difference, but I can't assume anything. Maybe you did something dumb ass because you were half toasted. If you have a serious point to make then you want to be taken seriously right?

 

  • Like 1
Link to comment
Share on other sites

I don't have time to watch the entire video rebuttal. It's an hour long. I could read fifty posts in that time, many of which would have solutions that would further my own understanding of the software, some of which would apply directly to issues I've had. Maybe it's just me but I prefer a well-written post outlining a problem, or a response to someone else's request for help. Meanwhile, the perfect place for Scott's helpful tutorials is on his YouTube channel.

If it's OK with Bandlab it's OK with me, but I don't think these long videos are the best way for forum members to report bugs or assist each other. 

[EDIT} I just saw that the rebuttal video was not posted here by Scott himself. So Scott if you read this, please don't see it as a critical of you personally. Just my thoughts on how to run the forum.

Edited by Larry Jones
  • Like 1
Link to comment
Share on other sites

I'm going to add a quick point before I lock this, (as this thread has run its course). Any DAW system has a lot of moving parts. There's definitely cases where things can be system-specific. We put a lot of effort into trying to replicate issues as closely as possible. We also do our best to work with users directly to resolve problems when necessary. As I mentioned in my previous post, the best way to resolve problems with Cakewalk is to contact us. If there's a system-specific issue, we can help troubleshoot those problems. If we find an issue with Cakewalk, we'll make sure it's in the system and we'll fix it as resources allow. Any major issues like data loss or stability always get high priority. 

This forum also offers a great opportunity for users to help each other, and we definitely keep an eye on things here as well, but its always best to contact support directly when it comes to troubleshooting issues. They're always happy to help.

  • Like 1
  • Great Idea 2
  • Meh 1
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...