Noel Borthwick

Pretty sure this should be good now. there were a few cases of edit issues with clip envelopes that we fixed. Please check out our and let us know if you still see issues.

I think you misunderstood. An early access build is no different from a normal release other than the fact that it isn't pushed to the entire world via BandLab assistant. Subsequent updates will work as normal as if you had a prior release.

With this release we focused on allowing lanes to be used as an arrangement tool in addition to comping. Ideally I think the feature could be called something like "track lanes" as opposed to take lanes now, since its not restricted to the recording workflow. You are free to use lanes as a scratchpad for different variations of track ideas whether they come from actual recorded takes or from other sources (clips in project, imported files etc). With the enhanced drag and drop and copy paste functionality all operations are now fully integrated with lanes so should work seamlessly. When dragging in other data you can choose to disable the comping features and arrange the clips in any manner before you decide to start the comping process. You can also choose to layer and have audio clips in lanes sound simultaneously if that's what you want in this workflow. In fact for those who used the old pre-X series layers, you should now be able to do all of that and more by using the tools appropriately. There are also big improvements to automation lanes and clip envelopes when doing copy paste between tracks or lanes that should make editing with automation lanes a smoother experience. Additionally thanks to a report from one of our users, we fixed a longstanding issue with recording in take lanes that would end up with incorrectly cropped clips in lower lanes. Overall we hope you will find arrangement and comping in tracks to be a much more enjoyable and intuitive experience in this update. Let us know if you see any issues.

Thanks Mark that really looks like there is some bad state management in the driver itself. When you stop and start the transport cbb goes through and starts and stops the driver. I've seen cases in the past where some drivers don't properly handle fast transitions and are likely failing one of the state transitions. I'll see if I can repro it with your recipe with the 6i6

Very soon assuming no regressions are reported.

@Keni there is no need to roll back to install the early access since it updates the 05 release directly. The only mention of rollback was to inform people if they wanted to go back to 05 afterwards for some reason. Going to the final release from early access should be seamless. The only small downside is it will auto download the full installer. This is very stable at this point so it should be very unlikely.

I have not encountered this personally. Do you have any more specifics to reproduce the problem @parboo12?

Hm I'm using a Focusrite 6i6 daily for development and have never seen this issue. I really doubt its related. My only guess is that something in the app has crashed and is unresponsive to transport commands. Does it happen in all your projects or only some and how often? Regarding the clip issue please see if its still happening in our new early access release since there are many changes and fixes to take lanes.

Very unlikely to be a CbB issue. When it crashes does it list the drumagog vst in the crash dialog? If its crashing when Drumagog is hosting a vst the crash is possibly due to it corrupting memory. Cbb is not aware of what the plugin is doing at that point.

Have you turned on Scan in sandbox in the VST preferences?

This is described in the abot the early access program topic: Cakewalk will present an "Update Available" notification when the final release version becomes available, if Notifications are enabled

If it's taking that long there is certainly something environmental. You can troubleshoot it by watching the start up toast notifications. Which one stays on the screen the longest? If you record a screencap of the launch process it may be helpful for us to see what's taking time.

Thanks for the report! We'll fix it for the next release.

MIDI doesn't have any notion of automation envelopes. When you open a pure MIDI file as opposed to importing it, we import MIDI CC events as is and also allow you to save the project back as a MIDI file. However any edits you made to the project that are not native to MIDI will be lost or converted. In the case of automation there is no such thing as envelopes in MIDI so Cakewalk converts the envelope to MIDI CC's (decimates into points to be more accurate) to represent the envelope as closely as it can. This is a one way conversion process and not a design flaw. When you open the MIDI file it will import back as MIDI CC's again. If you want to work with non destructive data save your project as a CWP file not a MIDI file, as scook recommended.

You can switch the edit filter back and forth from clips or automation by shift clicking the clip or the envelope.

I didnt even know that code still exists. I don't see why it would need to take a snapshot on each open of the view since we generally know when plugin parameters are changed - at least for most plugins.

Thanks for the input folks. Sorry I've been slammed with some other stuff but will investigate this soon.

@Antonio López Zambrano which plugin are you specifically seeing this issue with? If there is a demo or free version available can you share a simple project with me so I can try and reproduce the issue?

Yes this was removed since it seemed over complex to have different plugin layouts for each menu. For some people it can be confusing to not know why plugins show up one way in the browser and another way in the track menu. Generally the browser is a far quicker way to locate plugins once you get used to the search tool and the sort orders that you can specify from the dropdown on the plugin browser toolbar.

Yeah there appears to be a drawing issue with the preview waveforms. They get cached on each playback but what is drawn should be always the most recent waveform. We'll look into it for a future release. PS: I was referring to a case where the preview waveform is actually stale. Not the fact that envelopes are drawn behind the waveform which is a separate issue.

Hi @Rostislav this isn't your fault. It's hard to say what let the project to get saved in that state. The edit filter is the dropdown in the track strip that by default says Clips. By changing it you can select what data you wish to edit in the track. See the help for this here. You can easily switch your track to clips if it happens again.

I'm sorry you feel this way. There has been a huge amount of bug fixes just in the last year and thousands since the old article you quote. Just looking at our internal issue log we have over 500 issues resolved since we started. I don't see how that could be considered miniscule in relation to any other competitive DAW. Not sure if you have seen our public changelogs since we started last year: See prior release notes. Check out all new features released to date. While we do have feature work in our pipeline, we are focusing on workflow improvements and stability, not feature bloat. This is what the majority of our users want from us as opposed to shiny new toys.

Weird corner case. The real issue is that somehow track 6 had its edit filter state set to show an envelope. However the actual envelope data stored was not correct. As a result the code was not setting the edit filter state properly. Although the track view showed it as "clips" internally it was still "envelope". There is a rule for copy (not copy special) to reject note data when copying with the edit filter set to envelopes. Likely because we don't want to copy and paste data for the wrong type when the edit filter is asking for envelopes. As a result you saw this behavior that copy was ignored. I have fixed it for the next release so that when the project is loaded we ignore a spurious edit filter setting of envelopes and set it back to "clips". This fixes your project and when it loads up the edit filter will now show clips. It would be interesting to know how it got into that state in the first place. Perhaps you might remember if at some point you had set the edit filter to envelopes and maybe something went wrong after... You can make your project work again by setting the edit filter manually to something else and then back to clips. Then save the project.

@Rostislav thanks for the report. I was able to reproduce it. We'll investigate your project and see why it happens. On first looks I can see that the selection somehow thinks that nothing is selected even though the UI is showing it. We'll investigate further.

Thanks for the update . As I said we haven't made any intentional changes to the console 1 support. If anything syncing of selected track states should be more robust in the May release. Let us know if you have any further issues.