Huge problem with the Tempo Map and audio following tempo changes

[David Baay]

2 hours ago, Olaf said:

but you don't need to flood the forum with a separate topic for each of these videos, particularly since they refer to the overall same kind of problems.

Which one is the better choice, making 20 new topics, one for each video, or group all similar problems together, since they're related anyway? Which one is better for referencing?

From a development standpoint, they each have to be docuented and investigated individually; if they are found to have a common cause and solution, great, but that's for the Bakers to determine. From a forum standpoint, multi-issue posts are not as sensible as you might think; they tend to just become a confusing mess of random  responses. Videos can be helpful but they only show the actual result, not the expected result which is required to have a full understanding of the issue, (and to confirm whether there is even an issue or whether the expectation was faulty) and requires a verbal description.

2 hours ago, Olaf said:

I'd make a separate forum chapter for bugs only, no duplicates allowed, any various additional observations added as comments, likes on each topic from those who have the same problem.

The problem with this is that you're relying on users to correctly determine whether their issue is actually a  bug and whether it's the same bug as someone else reported. I can't tell you how many times someone has posted "I have the same issue", and it's not the same at all. Sometimes the same symptom, but a different cause (at least as often a  config or training issue as an actual defect), and sometimes not related at all.

2 hours ago, Olaf said:

And there's tons of other problems - for instance notes being written in the wrong place on the grid, in the piano roll, at certain zoom factors, and, more importantly, all kinds of problems with the audio driver implementation, that are directly affecting audio performance - for instance varying the playback speed depending on the latency settings; worse performance at higher buffer values; different performance after activating and redeactivating a plugin vs. with it just deactivated, that resumes after playback stop; changing performance depending on the place you deactivate a plugin from - the macro frame vs the internal on/off - if I were to write them all down, I'd make 30 different topics off of those alone. This is trying to keep it light.

I guarantee almost none of that will be reproducible by other users or the Bakers without a detailed description of the steps and much if it will turn out to he hardware/plugin/project-dependent. Personally, I have never encountered any of that or recall it being reported by anyone else in so many words with the possible exception of "worse performance at higher buffer settings" which can happen when your audio and disk buffers are not well-matched among other things.

Bottom line: if you seriously want to see anything 'fixed", it needs a separate post with reproducible steps and a copy of the project in case it's not readily reproducible in a new project started from the Basic template. 

I believe your expectation of what should happen in the last two cases is mistaken, but I can't make sense of what you're trying to accomplish or why you're talking about 'slip-resizing" a clip and expecting other clips not to be affected when you're using the split move tool instead of the single-clip crop tool. I was mistaken BTW;  It's Shift that changes this tool. not Ctrl.

[Olaf]

7 hours ago, David Baay said:

they tend to just become a confusing mess of random  responses.

every post tends to become a "confusing mess" of random responses, single issue posts, too, that doesn't change anything. you just choose the comments that actually pertain to the problem, it's not that hard, and it doesn't need to be formalized to the teeth to navigate.

7 hours ago, David Baay said:

Videos can be helpful but they only show the actual result, not the expected result which is required to have a full understanding of the issue, (and to confirm whether there is even an issue or whether the expectation was faulty) and requires a verbal description

there is a verbal description for every problem in case watching the video does not make obvious what the "expected result" is. like - verbal description - when you click and drag on something, the expected result is for that something to be clicked and dragged. when you resize a clip left, the expected result is for the clip to be resized to the left. so on, so forth. maybe excessive pedantry is not really needed.

7 hours ago, David Baay said:

I can't tell you how many times someone has posted "I have the same issue", and it's not the same at all. Sometimes the same symptom, but a different cause (at least as often a  config or training issue as an actual defect), and sometimes not related at all.

on the other hand, other times people may think it's a different issue, while it could actually be the same, it goes both ways, so what does that change? you don't invite the users to diagnose anything, you invite them to report problems, it's for the developers to discover the actual cause, if musicians were also software engineers, we'd fix it oursleves. users report symptoms, not diagnose. and that's no reason to report the same symptoms in 20 different threads. it's conflating two separate aspects having nothing to do with each other.

7 hours ago, David Baay said:

I guarantee almost none of that will be reproducible by other users or the Bakers without a detailed description of the steps

very likely, and then the developers kindly ask you for the project, and you kindly provide it. it's how you normally do it, and there's no reason for that to change. or you believe people should preemptively upload the project with any bug report, cause i don't understand what the moral is. by the way, the project file for this case has already been sent.

7 hours ago, David Baay said:

much if it will turn out to he hardware/plugin/project-dependent.

absolutely. which means - and follow me closely, here - that it's CW's fault. ok? it's something that you seem to miss. regardless of what the plugin does/doesn't do, what the hardware is, etc. and it's a fundamental philosophy problem that I've noted very early on: there seems to exist a faulty preconception that some plugin behavior or another, some hardware configuration or another, excuse or justify the program crashing, reacting badly, mistaking instructions, etc. they don't. to simplify things, none, ever. so, really, the discussion about what the plugin does is pointless. whatever it does. it shouldn't crash the DAW, it shouldn't resize a clip left, when you drag right, shouldn't prevent a clip from being resized, etc.

obviously I understand it's normal and unavoidable for that to happen sometimes, no need to be absurd, you can't just predict and preclude everything, and a DAW is a very complex thing - no objection to it happening, when it does. what I do object to, however, is the attitude that, when it happens it's a fatalistic, normal thing that you should just live with and accept, and it magically makes the problems go away, as long as you can blame the plugin/hardware. it doesn't. and the integration between all these things falls on the DAW, not on the individual plugins, hardware settings, etc. - therefore it's the DAW's fault, when it happens, whatever happens. and they're to be corrected, with assistance from us, sure - hence the posts - not accepted as normal.

in this particular case I was describing, it's absolutely the hardware - namely the hardware driver integration - meaning CW. it's all CW. everything, no matter what, it's CW.  as long as we understand that, we're ok. that's the problem we have understanding. regardless of what it is, where it starts from, it's CW. that's the attitude we need to have, for these problems to be solved. otherwise they will never  go away - there's always gonna be something. besides, it actually is CW. i have worked in CW on three different interfaces, and each one has reacted differently to buffer changes in CW. that's not normal, regardless of what the driver is. and it means driver integration. and only in CW were there such differences, not in 2 or 3 other DAWs I've tried.

as for the plugins, again, i can tell you which they are, it does that mostly when waves plugins are involved, but not only - speaking of going off topic. again, doesn't matter. It matters in terms of the technical problem to look at, sure, but not in terms of accepting it as normal.

i can show you how deleting a waves plugin from the project instantly makes the playback start to crackle. or turning it off - so less cpu load means worse performance. again, not normal, i don't care what the plugin is, does, doesn't do, what color it, brand, etc. or how switching it off it from the insert fx box goes smoothly, but doing it from its own little rectangle give rise to crackles. same plugin, both bypasses from the CW gui - without going into the plugin. so who's fault is that? you guessed it: it's CW. that's not to say I'm blaming the CW team, finding fault with them, etc., but this attitude of "it's plugin X, so no CW fault here, hence no fix, just fatalism" is really counterproductive and is a persistent problem.

7 hours ago, David Baay said:

I can't make sense of what you're trying to accomplish or why you're talking about 'slip-resizing" a clip and expecting other clips not to be affected when you're using the split move tool instead of the single-clip crop tool

I don't understand what you're saying, with slip this, slip that. bottom line, the cursor is the one for resizing clips, and adjusting the comping points between them. i've already explained that, and it's clear in the video. it's not in comp/clip slicing mode, and that's not the cursor for slicing. so it shouldn't slice. maybe you're mistaking the little icon there. moreover - and, again, it should be obvious - if it had been in slice/split clip mode, it would have split the clips in all the lanes, including the current, not just the one above. so even it had been the comp split tool, it still would have been abnormal behavior, even for that.

7 hours ago, David Baay said:

Bottom line: if you seriously want to see anything 'fixed", it needs a separate post with reproducible steps and a copy of the project in case it's not readily reproducible in a new project started from the Basic template.

i want to see things fixed, not "fixed". it doesn't need to be a separate post, we've already covered that, and all the reasons why.

a copy of the project has already been sent to the CW team, if you've followed the post, and it's for the developers to ask for, if they need it - or, again, you think a project should just be uploaded with every post, cause it's not apparent what your objection and/or request is. and it's usually asked for by the developers, not by other forum members, from what i know.

so i hope that covers everything, but, damn, it's been so long to write, and i thought most of it was already clear. i don't mind, as long as we're well meaning, and not just trying to make personal points.

Edited May 24, 2022 by Olaf

[David Baay]

7 minutes ago, Olaf said:

the cursor is the one for resizing clips

No it's not. This is the cursor for that:

As for the rest of it... have it your way. Just trying to help you have a better chance of getting your issues addressed whether due to defects or misuse.

[Byron Dickens]

2 hours ago, Olaf said:

in this particular case I was describing, it's absolutely the hardware - namely the hardware driver integration - meaning CW. it's all CW. everything, no matter what, it's CW.  as long as we understand that, we're ok. that's the problem we have understanding. regardless of what it is, where it starts from, it's CW. that's the attitude we need to have, for these problems to be solved. otherwise they will never  go away - there's always gonna be something. besides, it actually is CW. i have worked in CW on three different interfaces, and each one has reacted differently to buffer changes in CW. that's not normal, regardless of what the driver is. and it means driver integration. and only in CW were there such differences, not in 2 or 3 other DAWs I've tried.

Pure Bovine Excrement.

I can't count the number of times I have seen an update to a plugin or a driver that has among other things listed "fixed a bug causing Cakewalk (or other DAW) to crash."  The latest Focusrite driver comes to mind.

[Olaf]

On 5/24/2022 at 3:07 AM, David Baay said:

No it's not. This is the cursor for that:

As for the rest of it... have it your way. Just trying to help you have a better chance of getting your issues addressed whether due to defects or misuse.

Aha. Do mean this cursor right here ? Cause it's the exact same cursor, you realize that, don't you? Taken form the very clip posted above. Maybe you haven't watched the right clip. Why the urge to comment negatively, then?

On 5/24/2022 at 3:07 AM, David Baay said:

Just trying to help you have a better chance of getting your issues addressed whether due to defects or misuse

Thanks, but it's not how many separate posts you make or don't make that's gonna get the problem addressed, I'm sure the developers have a lot of fixes on the list, their schedules, their priorities, and they will address them according to that. Although something tells me they're working on it right now, which, if true, would be great news.

"Your issues" - see, we've got the attitude problem again. It's not "my" issues, it's not "my" program, I'm just a user who encountered them. It's CW issues, that, once solved, will help all users, will help the program, the team, etc. As such, I think you'd be glad to have them solved. Personally, I'm always glad to see releases with improvements and fixes, even if it's about functions that I know I'll never use. Let alone stuff like comping, etc., which is essential.

On 5/24/2022 at 4:49 AM, bdickens said:

I can't count the number of times I have seen an update to a plugin or a driver that has among other things listed "fixed a bug causing Cakewalk (or other DAW) to crash."  The latest Focusrite driver comes to mind.

Aha, did you see that on every single driver out there? Did you also see why changing the buffer size for a driver, slows down or speeds up the playback, cause that shouldn't happen, again, regardless of the driver.

Do you have anything against issues being solved, out of principle, or you don't like that I've shut down your initial ill willed comment, and are now determined to troll every one of my comments, like all disagreers, etc.? Cause that's infantile/narcissistic behavior.

 

Edited May 25, 2022 by Olaf

[David Baay]

Man, you are really begging for a snarky response, if not an all out flame war, but I will refrain.

No, that's the Split Move tool (a.k.a .Crop Abutted Clips) The one I pasted is the regular Crop tool.  Here they are together; note the differences:

     

The Split Move tool can be used to crop a single clip edge as you showed, but it's designed to move all clip edges on the same timestamp across all lanes as you also showed. The behavior you got is expected. If you only want to move a single edge, you should use the tool for that purpose. When CW is defaulting to the Split Move tool, holding Shift will get you the normal Crop tool.

[Olaf]

31 minutes ago, David Baay said:

you are really begging for a snarky response

why are you going for the snarky response, cause you still don't get it, after all these (repeated) detailed explanations - which were not needed at all, since it's all clear in the clip, anyway? people who don't get it usually have that attitude.

31 minutes ago, David Baay said:

it's designed to move all clip edges on the same timestamp across all lanes as you also showed. The behavior you got is expected

that's the same tool - the crop tool, when it's at the edge of a clip, it only has one rectangle. when it's in between clips, it has two. when it crops split points, the rectangles are full. when it's just plain resizing, they're empty. but it's the CROP tool, as you've said yourself, it's for resizing clip lengths - which consequently also moves comping split points - NOT slicing.

so, no, that's what i was trying to do - cropping - but that's NOT the behavior that i got - which was slicing. i've already explained it three times. do you need it explained again? it's all in the video. go watch it before commenting. i'm so sick of people picking on everything to find imaginary faults - just trying to be right on something - just because they didn't get their desired attention on their comments missing the point, the first time, that you wouldn't believe. you're not right. ok? it's a bug - that needs addressing.

anyway it is, the developers will make that assessment for themselves, they don't need you to speak for them, nor do i, or otherwise one of us would hire you to. we have a saying in romanian, the unpaid attorney deserves to be slapped (it rhymes in romanian). i guess in america you'd call it white knighting. it's not needed. so give it a rest.

edit: this is split comping tool , by the way, if you've ever performed that operation.

Edited May 25, 2022 by Olaf

[Byron Dickens]

2 hours ago, Olaf said:

Do you have anything against issues being solved, out of principle, or you don't like that I've shut down your initial ill willed comment, and are now determined to troll every one of my comments, like all disagreers, etc.? Cause that's infantile/narcissistic behavior.

What the F*** are you talking about and what the F*** is your problem?

[David Baay]

Over and out.  Good luck.

[Wookiee]

Thread locked due to behavioural issues. 

I suggest some time be spent with the reference guide.