Huge problem with the Tempo Map and audio following tempo changes

[marcL]

On 3/5/2022 at 8:18 PM, Olaf said:

Another thing that bugs like hell is that when you record a new take it automatically splits all the takes in the parallel lanes, at the point where you stop recording. I have to manually remove the clips before it and resize them all, and if you're recording in a loop, the splits are very small and you have to zoom in, cause you can't grab them, and so on. Do it after every single take. It doesn't do it in all projects, and I have no idea what prompts this behavior. I've changed all the settings in the comping settings, no change. Very frustrating.

Nowadays when I do loop recording I set an additional punch region that is smaller than the loop. Then I try to stop outside of the punch area. Like this I can avoid the annoying random splits!

[David Baay]

On 3/5/2022 at 12:18 PM, Olaf said:

Another thing that bugs like hell is that when you record a new take it automatically splits all the takes in the parallel lanes, at the point where you stop recording. I have to manually remove the clips before it and resize them all, and if you're recording in a loop, the splits are very small and you have to zoom in, cause you can't grab them, and so on. Do it after every single take. It doesn't do it in all projects, and I have no idea what prompts this behavior. I've changed all the settings in the comping settings, no change. Very frustrating.

This only happens in Comp recording mode and is a necessary feature. In order for Comping to work properly, every lane has to have clips with matching boundaries so that the content of only one lane is heard at any given point. Marled's solution of using a punch region to define the boundaries for all takes and stopping the transport outside it is a good one, Otherwise the usual procedure when you don't want any part of the last take it is to just delete the last take lane and then heal the split in one of the remaining takes, either by sweeping through the whole clip, starting from outside it, or by selecting the two clips and Ctrl+clicking one of them with the Comp tool.

[Olaf]

On 3/7/2022 at 7:03 AM, Craig Anderton said:

There are other projects on my YouTube channel, but I think those would interest you the most, and maybe give you some ideas

Let me know if you have any other questions, I'd be happy to help.

Thanks a lot, I'll check them all out.

On 3/7/2022 at 7:03 AM, Craig Anderton said:

Perhaps some of the effects that you add to every track would be more effective if used while mastering?

Weirdly enough, even though I have a ton of plugins in the project (about 90, including the sends and the synths), all of them almost exclusively serve one purpose, that of mirroring recording in a real room, through consoles, to tape. That's it. So I have room/studio reverbs, consoles, summers, transformers, tapes, etc. Plus the amps.

It's true to that you have to pay special attention to keep the levels constant when going into bus saturation, clipping and/or compression, so I try to do that. If not, a lot of the mud will come from exactly the master bus, and I found that out the hard way, several times. The misleading part is that what you think helps you, on a certain day, cause it thins out the honk, for instance, you realize adds a lot of bloatware lower down, that you weren't focusing on, when you listen to it the next day, with fresh ears. But I keep them on the mix bus, because I feel that without them, things don't have the necessary depth, roundness, glue and rich texture, and since they're gonna be there at the end, I think it's better to make all the EQ/compression/saturation moves through them.

On 3/7/2022 at 12:18 PM, pwalpwal said:

it did get a digital remaster in the 90s, could that be having an influence? like, you're piling on the analog emulators, but the remaster was probably trying to cut out the analog-ness at least to some degree? just a thought

That's an interesting thought. I know there are some plugins out there that can do de-saturation, but I don't think they work on complex sources, and if the remaster was done in the 90s, they wouldn't have been available. My version is plenty analog, and it sounds great - except for the cymbals, which sound like they've been recorded separately - it just has that focused sound, with smooth, but more metallic transients - that I believe comes from clipping. I've tried that on the master bus, and that's exactly the effect it had.

And I was thinking about consoles, and how people drive them, and how much gain they can take, whereas plugins seem to have a very narrow sweet spot, usually within a few fractions of a db - certainly smaller than what consoles seem to have. And I was thinking about why that was, and about that sound consoles put out, where, when driven, they seem to get these exact characteristics - punch, smooth, brilliant attack, less dynamics, and a cleaning up of the low mids, instead of swelling them, like plugins do - that clipping generates. And it dawned on me that maybe the reason for which they can get away with so much saturation, and so much drive, and have a wider sweet spot, is exactly that - that they push the signal into clipping. So I figured I'd give it a try.

I've tried an experiment, if anybody's interested. Listening test, to see if you can spot the differences, or it's just my self-suggestion. I've exported the same song snippet in three versions, one with no clipping added, the 2nd with clipping on the master bus, and the 3rd with clipping on each track - except the piano.

Note that I've gone VERY easy on the clipping, so the differences are very subtle. I'm curious if you can hear the differences among them, and what those differences are.

 

On 3/7/2022 at 5:14 PM, David Baay said:

Otherwise the usual procedure when you don't want any part of the last take it is to just delete the last take lane and then heal the split in one of the remaining takes, either by sweeping through the whole clip, starting from outside it, or by selecting the two clips and Ctrl+clicking one of them with the Comp tool.

I think the result would be the same, while recording in a loop, even with punch regions, cause you'd still go over the previous takes - because of the loop. I just wish it didn't split the previous takes automatically. On some projects it doesn't, but I haven't identified the setting. Do you know, by chance, how to set that up?

[Olaf]

@Noel Borthwick New finds, while working on the project. So it's all these things. I hope all these details are telling , so maybe I won't need to add different ones - they're all in the vein of the main phenomena described here.

These are the latest.

Resizing a clip inserts a portion of a different clip in the resize space, and moving a tempo envelope segment always creates new nodes where the initial node was.

The node values are displayed inverted in the tempo envelope.

Clip resizing becomes unresponsive, for some reason. It's happened several times in the past.

[David Baay]

3 hours ago, Olaf said:

Resizing a clip inserts a portion of a different clip in the resize space,

It's a bit hard to follow exactly what is happening, but the tool shown is for moving the split point not the slip-editing tool for moving a single clip boundary. Moving the split point will replace the waveform on the left side with the waveform on the right.

3 hours ago, Olaf said:

moving a tempo envelope segment always creates new nodes where the initial node was.

While the behavior you captured does seem a bit buggy, I would say the root of the problem is that you have two tempo nodes on the same time to begin with rather than having a single node with a 'jump' transition from the previous tempo. Moving the single node at a jump point will behave as expected.

[msmcleod]

7 minutes ago, David Baay said:

While the behavior you captured does seem a bit buggy, I would say the root of the problem is that you have two tempo nodes on the same time to begin with rather than having a single node with a 'jump' transition from the previous tempo. Moving the single node at a jump point will behave as expected.

There's nothing wrong with having the tempo nodes organised like that, and no need to make it into a jump point.

Something else is preventing the slip edit.

[David Baay]

1 minute ago, msmcleod said:

There's nothing wrong with having the tempo nodes organised like that, and no need to make it into a jump point.

Maybe there shouldn't be, but based on the video, it seems there can be...?  Jumps just seem a lot more logical and simpler to deal with - one node per change.  Seems kind of weird to see two different tempos on the same timestamp in the tempo list too.

[Olaf]

2 hours ago, David Baay said:

It's a bit hard to follow exactly what is happening, but the tool shown is for moving the split point not the slip-editing tool for moving a single clip boundary. Moving the split point will replace the waveform on the left side with the waveform on the right.

I know, that's what it's supposed to do, but it doesn't do it. If you notice in the video, it inserts an entirely different wave clip - I don't know how it chooses the particular one - in the slip space.

So, instead of having a boundary between two clips, you now have three.

2 hours ago, David Baay said:

While the behavior you captured does seem a bit buggy, I would say the root of the problem is that you have two tempo nodes on the same time to begin with rather than having a single node with a 'jump' transition from the previous tempo. Moving the single node at a jump point will behave as expected.

It's just normal envelope editing, same as with gain envelopes, pan, or anything else. It's a linear tempo change, according to the instructions: https://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Tempo.07.html#1999891 and https://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Tempo.04.html. You can see there're two nodes on a number of tempo changes, in the tutorial images, too. I don't believe it processes the two nodes as being exactly at the same timestamp, though, I think that's just the graphic representation, that would be the logical assumption. That how it should be, at least - adjacent, distanced by the smallest timeline resolution. In any case, it shouldn't create a third node.

2 hours ago, msmcleod said:

There's nothing wrong with having the tempo nodes organised like that, and no need to make it into a jump point.

Thanks for confirming.

2 hours ago, msmcleod said:

Something else is preventing the slip edit.

I've moved the clip on a different lane, exactly to show that there is no clip underneath it, or to either side - usually invisible clip fragments would prevent the edit, but it's not the case here. The weird thing is that if you leave it alone, and do some other operations, you come back to it, and the slip works again.

[David Baay]

14 hours ago, Olaf said:

It's just normal envelope editing, same as with gain envelopes, pan, or anything else. It's a linear tempo change, according to the instructions: https://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Tempo.07.html#1999891 and https://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Tempo.04.html. You can see there're two nodes on a number of tempo changes, in the tutorial images,

I actually reported as a defect a long time ago that automation editing should not create two nodes on the same timestamp. For consistency and ease of editing, it seems to me that an 'instantaneous' change should always be represented as a jump segment.

[Olaf]

3 hours ago, David Baay said:

I actually reported as a defect a long time ago that automation editing should not create two nodes on the same timestamp. For consistency and ease of editing, it seems to me that an 'instantaneous' change should always be represented as a jump segment.

To be honest I don't understand myself what the difference is between a two node linear change - which is my normal way of working with envelopes, so didn't think twice about it - and one node jump changes. At first I thought jump changes were a defect ?, and the node missing was due to a bug. It looks a little confusing.

[msmcleod]

2 hours ago, Olaf said:

To be honest I don't understand myself what the difference is between a two node linear change - which is my normal way of working with envelopes, so didn't think twice about it - and one node jump changes. At first I thought jump changes were a defect ?, and the node missing was due to a bug. It looks a little confusing.

The tempo track shares the same envelope editor as the automation lanes.  When using jumps in automation, the dotted lines literally mean no automation at all.  This means if you started a project in the middle of a dotted area, no automation would be sent out until it reached a node.

Obviously you can't have an area in the project with no tempo, so for tempos, there's pretty much no difference between a jump and a straight line.  It's really down to how you want to work.

Multiple nodes at the same position should in most cases end up being merged into one node.  If in doubt, refer to the Tempo Inspector to see if the list of tempos makes sense - and of course, there's nothing wrong with deleting nodes / changing them to jumps if you want to.  Obviously, if the rare case when you start seeing strange envelopes being drawn with nodes / lines in the wrong place, this is a bug - the easiest way around this is to simply delete the offending nodes.

FYI - this is how the tempo track works:

1. The tempo stream contains shape events in exactly the same way as an automation lane contains shapes.
2. When you change the tempo envelope, behind the scenes a linear list of tempo changes ( the tempo map ) is regenerated based on snapshots of the tempo envelope at regular intervals. By default this is every 1/16th note, although it can be changed in Cakewalk.ini to be a higher resolution using the TempoMapDecimationResolution setting.
3. The resultant tempo map is exactly the same tempo map used prior to the introduction of the tempo track. 
4. Saving a project saves both the tempo track envelope and the tempo map.

This approach has several advantages:
1.  The vast majority of the code didn't need to be changed, as it's referring to exactly the same tempo map as it did before.  In other words, the tempo track is used for only as an editor for the tempo map, and only the tempo map is used when playing, or whenever edit operations need to calculate the current tempo - just as it did before.
2.  Projects remain both forward and backward compatible with SONAR and earlier versions of CbB : Backwards compatible, because we can generate a tempo envelope from an existing tempo map if a tempo envelope doesn't exist;  forwards compatible because there's always a tempo map stored with the project - earlier versions will simply ignore the tempo envelope stream.
3.  We can use the same envelope editor for the tempo track as we do for automation envelopes.

For the most part the tempo track envelope is king, and the tempo map is only generated from the tempo track envelope.  There are a few exceptions where the opposite happens - i.e. the tempo map is manipulated directly and the tempo track envelope is then regenerated from the map:

• Loading older projects that don't have a tempo track envelope
• Set Measure / Beat at Now
• Tempo detection from audio - either through AudioSnap, or using Melodyne (drag audio track to time ruler) 

In these cases, separate Cakewalk.ini variables are used to determine the resolution the envelope should use.

The ini file settings are documented here:  http://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Tempo.15.html

 

 

[Olaf]

On 3/14/2022 at 11:33 PM, msmcleod said:

The tempo track shares the same envelope editor as the automation lanes.  When using jumps in automation, the dotted lines literally mean no automation at all.  This means if you started a project in the middle of a dotted area, no automation would be sent out until it reached a node.

Obviously you can't have an area in the project with no tempo, so for tempos, there's pretty much no difference between a jump and a straight line.  It's really down to how you want to work.

Multiple nodes at the same position should in most cases end up being merged into one node.  If in doubt, refer to the Tempo Inspector to see if the list of tempos makes sense - and of course, there's nothing wrong with deleting nodes / changing them to jumps if you want to.  Obviously, if the rare case when you start seeing strange envelopes being drawn with nodes / lines in the wrong place, this is a bug - the easiest way around this is to simply delete the offending nodes.

Thanks, man, great explanation!

I hope the bugs get fixed over the next releases.

[Olaf]

Another problem, where slip resizing a clip comp slices another clip on a different lane. I guess it interprets it a comp slice selection, but only on that lane.

A problem where slip resizing a clip to one side actually resizes it into the opposite direction. And it doesn't allow the clip edge to be aligned to the gird line, always leaving a gap to it past which it cannot be resized.

 

[David Baay]

33 minutes ago, Olaf said:

Another problem, where slip resizing a clip comp slices another clip on a different lane.

Mouse cursor is showing the Crossfade/Split Move Tool. Try holding Ctrl to get the Slip-Edit Tool.

EDIT: The second issue may also be related to this. Hard to tell exactly what the goal is.

I would recommend bringing up one issue per thread unless they are clearly related. It's not clear the new issues are related to tempo changes.

Edited May 19, 2022 by David Baay

[Olaf]

On 5/19/2022 at 10:54 PM, David Baay said:

Mouse cursor is showing the Crossfade/Split Move Tool. Try holding Ctrl to get the Slip-Edit Tool.

The cursor is in the smart tool mode, and it's in comp split move in the example, as it should be, and as it is whenever you adjust comping points. it's not the comp slice mode, so it shouldn't cut/split any clips. And, if you look in the example, it only slices the lane above, none of the others. It looks like a bug, it's not the cursor mode that's the problem.

On 5/19/2022 at 10:54 PM, David Baay said:

EDIT: The second issue may also be related to this. Hard to tell exactly what the goal is.

I would recommend bringing up one issue per thread unless they are clearly related. It's not clear the new issues are related to tempo changes.

They're related, since this kind of behavior happens a lot with tempo changes - but not only - and I've noted these issues in that context initially, hence the post, but I've noted they're probably not only owed to tempo changes, and existed independently, 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?

If it were up to me, 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. Gather all on a single list, grouped on chapters/topics, and tick all the boxes, one by one, as the problems get solved. And solve all bugs, starting with the big ones, before implementing any new feature - that is only gonna come with new ones and/or build on the old ones. Basics first. CW really needs some organization.

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.

And if/when I write about all those - I would need to setup sound capture first - do you think they should go into a single topic, reflecting the larger overall problem, or do you think they should make up 30 different topics, just to fill the forum, and make it harder to follow? I don't get this. This is probably the kind of philosophy because of which these problems still exist decades later.

Edited May 23, 2022 by Olaf

[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