Olaf

@Noel Borthwick The video for the lingering synth load and VST scan toasts. Waves gets rescanned on pretty much every load, but I think that's just the way their shell works - although, rarely, it loads without the scan, so I couldn't say for sure. Toast Notifications.mp4

Will do! I wasn't thinking about that much more work and new settings for it, just having them go away.

My problem with the toast notifications is that, on project load, the synth loading and vst scan messages don't go away, once the project has finished loading, like it's some critical information that needs my input, when synths loading and the vst scan are absolutely normal, and don't require my input or my taking note - all that should happen anyway. i mean i like the messages being displayed while the project is loading, that way i know it is loading and not just sitting around, but once that's done there's no point for me okaying it every single time - just useless extra clicks. on the other hand, when the project IS waiting for input - some message that needs OK-ing, it would be great if the taskbar window started flashing, so that you know it's waiting for a message from you - and that currently doesn't happen. so i'm waiting for it to load, it is waiting for me to OK something to load, and we're both wasting time, until i click on the window to see what's taking so long.

i don't imagine why you think that's such an unusual thing. everybody does. it still doesn't justify the automatic split point. think about it a little: how often do you actually use that automatic split point, instead of just having to remove it a million times over while tracking?

Or just let them end where they end, without automatically splitting anything, it would effectively be the same thing. It's hard to understand the reasoning behind that automatic splitting.

In my experience this has been present from previous releases. Synths either drop out or start playing out of sync until you stop and restart playing. It happens either when you tweak VST controls or when you resize/move audio clips in/across tracks.

Yes, I agree with you, it's a very complicated thing, and I'm amazed sometimes that DAWs even exist, let alone work. Personally I've been waiting for over 2 and a half years for certain things to get fixed, and I'm alright waiting a while longer, as long as it's clear things are heading in the right direction - which is, there's a common understanding that ultimately it's the DAW's responsibility to integrate and manage drivers and plugins, so that it behaves correctly regardless of the driver configuration, possibly faulty plugin instructions, etc. Like, for instance, it's alright to have a plugin stop responding, for conflicts, internal faults, etc., until things get solved by either developing team, but it's not alright to have that crash the DAW. And it's not clear how drivers or plugins could influence internal operations, like resizing audio clips, adapting them to tempo changes, having them jump in the timeline, having previously recorded clips play in the background while you're recording with monitoring activated, so on. That's the overall idea. Otherwise, we keep hoping for good things.

There's a huge difference between saying "it would help us to know the system configuration, so we can get a lead on what needs to be fixed in Cakewalk" and saying "there's nothing in need to be fixed in Cakewalk, it's your system that's the problem (or plugins, etc)". The latter attitude is very discouraging. It shows people things won't get solved anyway, so why even bother? But if they're still here it means they're trying to help things to get better, and haven't given up yet.

Like the "automatically extend last take" feature. Automatically splitting all previous takes at the stop point was really annoying. I'm glad that's solved.

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. 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.

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? 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. 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.

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. 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. 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. 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. 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. 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. 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.

???? Will you give it a rest with the dock? Nobody cares where the tab is placed. There was no mention of that, and it's got no bearing on anything. The only things relevant to the preoblem: where you open it from, where you close it to. Where the tab of the open window is placed has nothing to do with it. Of course it's gonna be placed on the multidock, where else would it be placed? That's not what the talk was about. ????? And that you got from.... ??? And how would that solve anything of what I've mentioned? There was no mention of any problem with the actual window, so who's asking for an "option" to replace it, let alone an "only" option? It would require absolutely no change to he "skylight" (or any other) interface. It would just require that after you've closed the window, the track view is brought back up, and not the console view, that's got nothing to do with working with Melodyne, since it's a region FX.

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. 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.

Thank you, I'll try it next time. It's true the Melodyne window doesn't get selected even when it opens with the notes showing, you have to click inside it to select it. Otherwise you hit CTRL+A, to select all the notes, and it selects all the clips in the Track View instead, which does not even show on the screen, and you don't even know it happens. Lots of useless extra clicking. Not to mention who knows what you might press, thinking you're in Melodyne, and wake up to stuff disappeared in your tracks, without even being aware. I think you're confusing things. The Melodyne tab is docked in the multi-docker, but you don't open it from the multi-docker, but from the respective audio clip(s), which are in the Track View. When you work with audio clips, which is what Melodyne is intended for, that's where you have to work. Regardless, it's a rule of thumb, something that opens from a certain place should close to that place, to allow the workflow to resume. Being switched to the console after very render, when you're working with dozens of clips, becomes a little annoying.

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. Slip Trimming Cuts clip on Different Lane.mp4 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. Unable to slip extend clip edge.mp4 Unable to slip extend clip edge More Complete.mp4

I have never had that problem and don't know what to ascribe it to, but I do have a couple of problems with it, too: one would be that sometimes opening the clip in Melodyne opens to a blank view, unpopulated with notes. I have to close it and reopen it again, for the notes to appear. The second is that every time I close the Melodyne window, after having finished editing, the view changes to Console View, instead of the place I opened it from, which is the Track View.

I've made time to read the article, thanks, very informative piece, but I still don't think it supports the behavior. Normally, I think what it should do is instantiate the right synth, first, not freeze the track, second, and, as to the drum map, either keep the one loaded and replacing the destination instrument with the new one, with a warning, or remove the existing drum map, maybe with a prompt to create a new one/replace with existing. This last alternative would be my choice.

It's weird. It might depend on other project variables. I had SSD sending to 6 different stereo outs routed to 6 audio tracks. And had a dedicated drum map loaded for the MIDI track. Once switched, the map got replaced with a new one routed to Element, which was loaded instead of TC Drums. Maybe it's connected to the number of outs, I don't know. I have two more synths in the project, other than Element and the drums, the Electric Grand, and a T-FM keyboard. Element must have been the last synth added to the project, but it's the first in alphabetical order - that's the only probable cause that stood out at first glance.

I haven't tried that, that's even more strange, that makes it an entirely different bug altogether 😳. Speaking of selecting, something happened yesterday that hasn't happened before, on the particular project or any other. Selecting different parts of the Arranger track automatically unselected others. Very strange. What I did before that started happening, probably connected in some way, was move all but the first section left by one bar. So whenever that first section was selected, the right half of the timeline got unselected. But also the last section got excluded if I selected more sections starting towards the left. @Noel Borthwick Timeline Selection Problems.mp4 Yeah, exactly, it's not scrolling out intentionally, it's the selection scrolling itself away while lassoing out of the screen area.

Replacing SSD 4 on a multi-out track with either Tony Coleman Drums or EZ Drummer freezes the track, and wrongly replaces it with Waves Element, which there already is an instance of in the Synth Rack. On Undo, the track gets frozen again, and the undo operation fails - the synth keeps Element on it. I haven't tried other synth combinations. EDIT: SSD 4 is linked to a drum map. On replacing, a new drum map gets created without asking, and it routes to Element 2, which might be the first synth in alphabetical order. Replace Multitrack Synth Not Working.mp4

Pan Envelope Only Moves Visible Node In Selection.mp4

See video below. The behavior occurs both when opening a new instance on a mono bus, and on opening a project with an existing instance, on a bus that has meanwhile been switched to mono. When it happens, the plugin doesn't work - lets the dry through, as if it didn't exist. The Weirdest Bug Ever.mp4

Yeap, I've noticed that talking to people on a number of issues. Some get them, some don't. I believe it's in the way CW interacts with the drivers - sound and graphics, maybe the vcredists. I often get the strange phenomenon of deactivating plugins - so decreasing the CPU load - and getting crackles and pops that don't happen with them activated. It happens mostly with Waves plugins, but not only. Weirdly enough, if I deactivate the plugin by deactivating the entire insert FX box, the issue doesn't appear. And it behaves differently when activating/deactivating a plugin from its FX box rectangle, as opposed to its own on/off switch.

I understand the reasoning, but if you need a bus deactivated, while keeping the sends, you can just mute it; if you want to reassign it, you can just replace the send effect, so all these options are already covered. Normally if you delete the bus, it means you don't want those sends anymore, otherwise you'd just choose one of the above. Plus, when you replace the send effect, you're most likely to redo the send amounts, so retaining that saving won't help you much. If not, a good idea would be to change the warning message, so that you know what you're dealing with.